Personally found Webpack to be really heavy handed for what most developers need it for. Gulp on the other hand seemed easier to just build exactly what you need. Webpack felt like an overly complicated poorly documented black box that seemed to work by sifting through github issues and comments. You spend 2 days getting it into some semblance of a working state, and never touch it for fear of introducing a new issue. Gulp just...worked, and with very little fuss. Sadly React seemed tightly tied to webpack so if you want React you're tied to that toolchain.
In general I think tooling needs to improve, and neither Webpack nor Gulp are painless. Neither is maven, I suppose...
Hey thanks for the candid opinion!!! Sean from the webpack team here!!! Maybe it's been awhile since you have taken a look at our documentation! (webpack.js.org)!
I think something that individuals who try to make comparisons to their backend tooling that "just works" is that none of these tool have ecosystem constraints like the Web. I wanted to really talk about something that is important to understand about tooling, and why webpack might have some of the features it does.
In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download. From there, you should be "dynamically" delivering JavaScript asynchronously in bundles/chunks. In addition, there are multiple module types that exist in the JavaScript ecosystem that libraries are published in. Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all, and there is no consistency or way to know this about those modules without looking at their source code. Therefore, webpack out of the box supports the ability to load all of them. Not only that, but we employ a set of plugins that help optimize code using complex topological sorting, (aka things you'd probably never want to implement or hand optimize yourself) to ensure that your delivered code is the smallest possible.
Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc. Think if there was 5 ways to write C++ Modules/Java Modules, etc. and you had to apply the same constraints as the Web. (You'd probably see a lot more webpack's or a lot more convention tools that wrap things like webpack).
Anyways, as a maintainer of the project, we can't say this enough: "We are owned by our community". This means that if there are things we aren't doing right, that we owe you to make things easier to use, more conventional, when needed, and progressive in a way that lets you layer features and need on top of an awesome, and fast core product <3.
So if you have great ideas, please let me know. :-D
As Webpack user, I can affirm that the documentation and the error handling is way better than it used to be. Webpack, by it's nature, is not an easy to use tool.
I don't think all developers should have to deal with Webpack directly, for most developers a generic Webpack config generated by something like create-react-app should be good enough.
Of course this doesn't mean that Webpack itself should not try to improve, however users should be mindful of what a hard problem the tool is trying to solve.
> Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc.
Huh? Seriouosly? Embedded devices can be any size people want? Some software I develop uses C, Go, etc. and it would be nice to not have to worry about built artifact sizes. Admittedly I find it kind of fitting and funny that someone who maintains a popular JS library thinks that the web is the only (?) platform with build size (and possibly other) constraints, haha.
Anyway, I do appreciate your work in helping maintain an open source project, so keep that up.
> In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download
Man I wish it was easier to convince people of this. I'm fighting with some teams at work who are shipping 2mb+ compressed with several seconds just for parse time...and all of the webpack tooling and features are needed just to keep it there (when it should be used to bring it down within that 200kbish threshold). And they feel its normal.
> Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all
Not being current on JavaScript for the past couple years (which is about all it takes to be totally out of date - but I digress), I guess these are out of style, in favor of ES2015 import statements? The webpack docs [0] really don't say anything about that, just that they're supported.
As a consumer of webpack and $random_library should I care? Should I prefer a library with import over AMD or does webpack make that irrelevant?
I can't tell from these docs, but previous experience tells me this is the kind of thing that has the potential to trip me up later when it's a huge pain to switch everything.
AMD modules can effectively only be consumed by a browser, or a browser-focused bundling tool, since AMD was designed for the "cascading waterfall" loading approach. Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules.
CommonJS modules are intended for synchronous loading under Node, and tools like Webpack and Browserify can wrap them up to be used in a browser.
ES6 modules are designed to be statically analyzable, which is a key factor in "tree shaking" to drop unused code out of a generated bundle. However, the ES6 spec only defined the syntax for modules, not how they should be loaded. Major browsers have finally implemented native support for ES6 modules, but there's still a lot of complexity around how they're going to be implemented in Node [0].
There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing. However, that loses out on any possible benefits from tree shaking. See this Twitter thread with discussion from Dan Abramov [1].
For more info on the history and differences between various JS module formats, see the "Javascript Module Formats" section of my React/Redux links list [2].
> There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing.
There's also a growing trend among some major libraries to publish NPM packages only as ESM and use an shim like @std/esm to load them in Node:
>Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules
Quite possibly because one of the biggest backers of the AMD format, Dojo* is now transitioning to ES6 modules.
*I really gotta hand it to those folks. They pioneer quite a bit of tech. Sometimes it sticks, sometimes it falls by the wayside, and sometimes it returns as someone else's "idea".
The overwhelming majority of space taken by games is HD or 4K assets, not code in any language or plaintext script. I can't even think of a single game that is 600GB off the top of my head, the latest huge AAA: Doom, Halo and Witcher are all under 100GB I believe and still considered too heavy on users in Australia, users with bad connections, etc. (and again - vast majority of that is assets, not any code). The biggest game I actually have on my HDD now is around 60GBs and the exes and dlls take under 50 MBs, it's FFXII with both English and Japanese in it and there is a guide on Steam on removing one of the languages content to bring it down to 30GB. And the latest "don't worry about it, CPU/RAM/HDD is cheap" framework for "native" applications lately was not Qt, GTK+, LCL, etc. but actually a 'JavaScript' technology - Electron - notorious thanks to shenanigans of Slack and Atom.
Between the multiple exclamation points, emotes, PR fluff and the content itself I was actually unsure if this is a parody account or not but it seems to be a genuine Microsoft person.
So, just to get my own biases out of the way first: I'm a big webpack fan, with no qualifications. I think it's a fantastic tool, and I've had the complete opposite experience of the OP.
This response comes off as kind of snide, as does the post it responds to; I don't care to tone police, so that's fine, but I do want to try to understand the perspectives here.
I'm imagining you're coming from a place of: you have a (fantastic) tool with unique challenges, and it's incredibly frustrating to have that tool judged a) based on requirements it wasn't designed around and b) (likely?) based on older versions of your tool that has since been improved. Those are fair things to take issue with.
A couple things, though:
"Hey thanks for the candid opinion!!!" - This seems pretty obviously disingenuous.
"Maybe it's been awhile since you have taken a look at our documentation!" - Comes from the position that OP is simply out of touch, and that their issues aren't valid. They may or may not be, but this is "Maybe you're wrong!" and not "Maybe there's been a misunderstanding!"
"So if you have great ideas, please let me know. :-D" - In context with the above, this is more like "Let me know when you actually have a great idea" than it is like "Please open an issue or pull request so we can actually fix it". The OP does clearly have an issue with Webpack - "You spend 2 days getting it into some semblance of a working state, and never touch it for fear of introducing a new issue" - and that issue can be addressed, if developed into something more actionable, or may already be solved by the improved documentation of 2.0 & 3.0. As it stands, though, it seems more likely to me that nothing comes out of it, which is a shame.
Not trying to put words in your mouth, I just expect you're more frustrated and want to make a better tool than you are trying to necessarily defend your tool, and I'm not sure you're communicating the former over the latter. Would love clarification if I've misinterpreted something, or correction if I seem totally off the mark. And again, lest I come off more aggressive/dismissive than I intend - thank you for all your work developing and maintaining Webpack. I imagine it's a relatively thankless task for the breadth of what it offers.
Hey Sean, I just want to say thanks for all the work; I'm not sure the complaints from others but webpack has helped us quite a bit by making development life closer to what it should be!
I'm not sure, my opinion of Webpack is completely different.
We used a ~20 line configuration file found on Gist to replace our ~400 line gulp build. It resulted in better optimisation, less hassle and "Just Worked™".
We wanted to add a few more things to our configuration, literally just took running `npm install some_package`, followed by requiring it in the webpack configuration.
Having to find it on gist because the official documentation is so lacking that nobody can figure out how to configure the thing except by following examples is the main problem that leads people to fear webpack configuration and to cargo cult magical config files that they are afraid to touch.
Mature tools can be understood in principle and configured without needing to see "how someone else did it."
The recent rewrite of the doc seems pretty clear and straightforward to me. Did you take a look at it?
I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again.
> I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again.
And that's a valid audience for the tool.
Good documentation would support this audience too, with plenty of examples and recipes. Even a repository of documented common use-cases (which must exist for Webpack's automated testing, right?)
I looked at the documentation the last time there was one of these complaints about webpack threads, the usage and benefits of loaders, plugins and modules seemed hard to understand as opposed to gulp where you just have a pipe.
I don't care if I can just plop a simple webpack without thinking in and it will handle everything I need, because I will always need more - and besides which I have my own gulp files I can just plop in without thinking too because I wrote them and I know exactly what will happen.
It's much much better, but still not very clear in many places. Just the other day I was struggling to figure out what some magical terms were referring to.
Thats surprising to me. Even the originally 1.X documentation wasn't that bad for the common cases. The 2.X documentation is pretty darn good.
The only issues I hit back then was complex cases back in the 1.X days. But if all you wanted was an app with prod/development mode that compiled javascript, css, let you import assets, minify in production and hash file names for long term caching, it's pretty simple considering everyone wants these to work slightly differently.
> Mature tools can be understood in principle and configured without needing to see "how someone else did it."
I don't know a more "understood in principle" tool than Webpack. There are no magical invocations just `webpack` and you are done. Plugins are usually just a require and adding to your plugins array.
I also think the maturity of a tool is in being easily understood just by reviewing someone else's config. To me, that speaks volumes for how simple and easy it is to get up and running in webpack.
I’ve been able to do everything I want to with create-react-app which uses webpack internally, giving you a zero configuration experience.
With async import I am able to do code splitting. With react-intl-cra I can pull formatted messages out of my code. I had to add a grunt file to compile LESS into src, but it was easy to integrate with my package.json scripts.
Using this should make WebPack work with LESS files. I'm no expert, but my understanding is that this says "for all files matching *.less, run them through the CSS and LESS loaders, then use the Extract Text Plugin" (which pulls things into their own file; you'll need to configure it in the plugins).
Thanks! One thing - I'm not using WebPack directly and indeed, I have no access to the WebPack configuration because Create-React-App hides all of that from me.
I can eject the app from Create-React-App and get a normal WebPack project, but I won't do that unless it's absolutely necessary because the huge community of Create-React-App devs are taking care of my config for me.
create-react-app now uses some kind of extensible build scripts in form of react-scripts: webpack files which you can clone and modify and use without ejecting.
That has less to do with webpack and more to do with create-react-app which doesn't allow you to modify the webpack config. The gp didn't really need to use gulp, you can compile less with package.json scripts.
As mentioned, create-react-app doesnt let you configrue anything (ok, almost anything), and doesn't support LESS/Sass by design.
Though you usually don't even need that much. Just using the node-sass or less compilers directly usually work fine. Or use something like Glamor or Styled Components to punt on the problem altogether.
Any ambitious project is sooner or later going to have to delve into their tooling, and not depend on examples they found of things that work. I admit it's nice you found something that worked exactly as you wanted, and my experience is I can often find what I want exactly when I start but sooner or later you need to add to it. And then things start to get less pleasant.
I definitely went through the pain of trying to set up Webpack 1.x on a large project. The documentation was probably the worst part (it was adequate as a reference, but really assumed you already knew some of the fairly complex topics).
I also recently went through the process of refactoring our build to use Webpack 3.8. The documentation is a LOT better. Their introductory docs especially. I feel like I finally understand parts of WP 1.x after reading the 2.x/3.x docs.
Gulp and Webpack really are two separate things. Gulp is basically like Ant had a baby with NPM scripts. Webpack is closer to Maven, but Maven really tries to do a LOT more.
For any project, start with NPM scripts for your task running, then include gulp if/when you actually need them. Same goes with Webpack: don't include it in every project just because you think you might need it eventually.
I felt the exact same way as you, but recently went through their tutorial/docs and was able to get a pretty good (and simple) setup without much fuss at all - a dev build, webpack dev server, and prod build. I’m only a short bit into actually proving it out for myself, but so far I was surprised since my first experience being quite negative too.
It's really not difficult, it just looks more complicated than it is. If you want a good start, try the Webpack book by SurviveJS. You can read most of it in an hour or two and not only create a config but actually understand how webpack works: https://survivejs.com/webpack/introduction/
There are also slimmer/newer/zero config alternatives like:
Webpack is a dependency-wrangler. If you're using it as a task-runner like Gulp, you may not need it at all.
Personally I use then together - Gulp runs the tasks, one of which is bundling, which gets done by webpack. Of the two gulp was way harder to get working, for me at least.
Sure. I do, and I'm sure most people in big corps do too.
All modern high level languages have very good cross-platform system libraries and build tools for those languages usually use that language to run. Occasionally you'll run into someone that's still using Makefiles and have to break out msys but other than that it's generally fine.
You've found Ruby easier to manage on Windows? Can you serve it from Windows? (other than Webrick)
I'm not trying to be inflammatory at all. I just never had any luck with any Ruby/Rails type stuff when I was forced to use Windows. I ended up resorting to JRuby.
There's really no need for one-liners - npm can run shell script files just fine.
What complex things are you doing that Windows compat creates problems? (presuming you've got some form of bash on Windows) I tend to tuck any complexity into JS devDependency libraries when using npm scripts which takes care of most cross-platform issues.
If you're using npm to run shell or node scripts, then you're running your tasks with shell or node scripts. Just because you typed "npm test" instead of "./test.sh" doesn't mean npm is doing anything to help manage your tasks.
npm (more specifically package.json) is helpful in this context for a variety of reasons:
- it's a single, central document listing your important pipelines and their purposes - anyone unfamiliar with your setup can look at the scripts property and get a very good idea very quickly
- it's auto-detected and even auto-parsed by some tools (a Ctrl-Shift-B in vscode, for example, will allow me to select a build pipeline - there's no more well-supported central format for arbitrary loose shell scripts)
- it's a consistent entry point. If you edit your npm script to point to a separate shell script, or to run webpack/whatever instead - anything external (IDEs, CI configs) pointing to npm need not change
The above are not unique to npm, but it's a well-supported, well-understood, and very simple setup that does the above.
Scripts + NPM are better together, for example because scripts executed under NPM have the local packages binaries in the path. This makes it very easy to have a fully locally installed build environment with no system dependencies. And if you do use webpack, it also helps in providing a uniform interface (Is "test" a Webpack target or a script? Who cares, just use "npm test", it'll work either way, also if we change it in the future).
And it's not an either-or case in the real world. Our company has a big Webpack config that does a lot, and still we have 15+ scripts as well (static analysis, inserting copyright headers, sourcemap uploads, 3rd party vendoring, release scripts...). Some things are better in WP (building), while some things are just simpler with a shell script.
To clarify, I was specifically responding to the gp comment's point on needing to use one-liners in npm scripts.
The most complex "shell scripts" I've actually written for this specific purpose are simple ordered command lists, with occasional exit code checks, where appropriate. So I'm not so much talking about "writing and debugging" - this is more "replacing semicolons with newlines in a very long one-liner"
I do actually put one-liners into npm scripts instead quite often - it's a trade-off, depending on the pipeline.
The document seems to have gotten a little better, lot better than Webpack 1, however the plugin ecosystem is the most frustrating part imo. Webpack gives plugin creator some form of freedom and because of that, and the lack of types in JS, you're at the mercy of proper docs on the plugins you're relying on. Either that or go through the source code to find out what the heck is even accepted as options.
We heard this feedback infact and we wrote the entire plugin system for webpack 4! (https://github.com/webpack/tapable). Take a look at the only PR open which is us working to provide the best Type system possible for our new API (which was infact designed to support it).
Even better is that you can find all the "hooks" on an instance by doing `compiler.hooks` so now you get a far better authoring experience :-D
https://neutrino.js.org/ is my go-to, I have no gripes with Webpack as a technology, but I don't think it's what people should use on a daily basis abstraction-wise.
My webpack configs are a magnitude smaller than the equivalent gulp ones.
React really isn't tied to webpack - babel maybe. If you're just using webpack for the basic functionally of babel automation and es6 import resolution it's trivial to setup but probably not the best tool for the job.
People use Webpack because it gives you easy access to NPM, understands module dependency graph and through various plugins, can optimize your code with features like lazy loading, tree shaking, etc. These are things you don't get with Gulp.
That is fantastic, on first glance it seems exactly what is needed.
I just think it's unfortunate that the tool needed someone to develop another tool to make it truly usable. Good software should be simple to use and configure, not dense and opaque.
I don't think it's unfortunate, I think it's a good abstraction. Webpack being a lower-level tool wrapped by Neutrino. Similarly to git's plumbing and porcelain separation.
React is definitely in no way tied to Webpack. Slightly tied to babel presuming you're using JSX, as everyone is, but otherwise it's extremely easy to use any other tool.
I've built pipelines with rollup and browserify, both which have problems and I'm not entirely happy with but I found an improvement over webpack.
I evaluated webpack recently and found that it worked fine for straightforward projects but the more customized I wanted it the more issues I ran into.[0] I think it’s a matter of configuration as json vs configuration as code. Webpack had all of the component pieces I needed, but they were glued together in ways that I couldn’t compose them. I ended up using rollup, which was a bit better but I still yearn for the composability of Broccoli.
[0] My project allowed users to have a single JS file that would be able to `import` npm modules and the have the bundler compile all of the dependencies into a single tree-shaken vendor.js, while modifying the main file’s imports to be human-readable es5. Webpack’s es6 import code was tightly coupled to the format of its output.
I haven't used Webpack prior to 2.x and Gulp was my preferred option previously as Grunt really was a clusterfuck, but Webpack setups come with batteries included and small extensions to it you need to add are often easy. That's my limited experience anyhow. The only tool I rooted for (but is still behind the curve) is Brunch.
Good that plain JavaScript 5/6 with no framework is still in the top 2 in all related charts. Looking back how many frameworks came and went dodo, I am using only small libraries and stay with plain vanilla JS 5/6.
Writing modern JS is a peace of cake, it's better to understand 100% of the codebase than to use way too much magic APIs. (well I understand the whole computer, all layers, from hardware to operating system, to software - so there is no magic for me, that helps a lot)
Looks like vue.js is doing great marketing (even if just word-of-mouth). Almost half the participants say: "I've HEARD of it, and WOULD like to learn it".
Meanwhile, react.js has over half the participants saying: "I've USED it before, and WOULD use it again".
Recently chose Vue.js over React, and it's been great! React was a pain to learn imo and Vuejs really made everything smooth and easy. Just my 2 cents.
How is React a pain to learn? It's the most simple framework I've ever learned. I can count all the methods/concepts on my fingers: components, state, props, setState, render and 5 or 6 lifecycle methods you occasionally use (componentDidMount and so on). The rest is vanilla JS.
I coded with Angular 1 for 2 years and had to open the doc each time I wanted to use ngRepeat…
The v-* directives put me off from learning VueJS. Sticking control flow in dom tags is almost never a good idea - you already have Javascript, inventing your own syntax just means the developer now has to learn two ways to do the same thing, for not a lot of gain.
We use a library call virtual-jade. Like react compiles jsx to JS, it compiles pug/jade to JS as h(node, attrs, children) calls. With with react, preact and snabdom.
It's been amazing writing templates that are just functions in a clean language like jade/pug. Jsx still has a lot of boiler plate.
Yeah, that was my own personal opinion prefacing the facts. Vue supports both, but the template system is generally used more in the Vue ecosystem than JSX is. Vue neatly fits between JSX and angular.js' clunky template language. Since the developer can quickly understand that Vue and React are both doing the same thing underneath, he can pick his preferred way to do it (template vs render func). I see in passing that more experienced devs I've worked with prefer the react way at a higher rate than those of less experience do. But mostly, you're right that v-directives are vastly more popular.
I came to vue liking JSX pretty well, but it does seem that culturally (or maybe just among newer developers like me) the single-file component with directives in the markup is more popular. Especially in tutorials. I haven’t really felt any pain with the default vue tenplating style that made me think switching to JSX again would be useful to me.
React is easy when you just do data -> rendering. But what about animations, modals and other forms of interactivity that doesn't fit squarely into this?
And while React is simple, you quickly have to add a router, some state management etc., so instead of a small simple library most React-projects I have seen end up being a custom framework.
None of these things come with Vue out of the box. The only difference is, React has often many solutions and massive community support to chip away at something until the very best stand-out solution emerges: redux, react-router, next, etc. React encourages this by staying out. Usually it then trickles down into other eco systems (vuex, vue-router, nuxt, element, ...). If something is very stable or close to perfect it's going to be made official, like modals:
In Vue you're pretty much in the rain. The community isn't encouraged to explore due to half-baked-in solutions, and baked in stuff in general is browser-complacent and thereby very limited. So you get css class animation groups (=react-animation-group), state is a one trick pony tied to the lib, theming isn't considered. There are so many open gaps and holes in the eco system at large, i'm scratching my head over how this would possibly be a plus or easier to the developer. It is often not.
If needing more libs for projects is your issue with React you should try Mithril. Routing is included. There's nothing really magical about state management; plain old JS objects work for 90% of state management, and Mithril streams fill in the rest.
Re. animations, etc., those aren't too hard with lifecycle methods, which, if I understand correctly, Mithril copied from React.
I've been using Vue.js on large scale projects for a while, but for a greenfield project I'm choosing React instead. React has better support for SSR which is still really important for public facing websites, JSX feels much more natural to me than the v-* directives, not to mention React's incredibly large ecosystem. That being said, I really like the way Vue handles CSS in single file components, and the simplicity of Vuex compared to Redux. I'm still struggling to find a styling solution for React that I'm completely happy with. As with everything, it's about choosing the right tool for the job.
Mind elaborating on this? I'm about to start a project that will use SSR, and I'm really interested where Vue (which would otherwise be my preference) might limit me.
https://nuxtjs.org/ is a front end framework with first class support for SSR for VueJS that is almost about to release their 1.0. SSR compatibility was one of the major pillars of VueJS's 2.0 release.
I’ve heard this so many times, and don’t get me wrong I really like Vue, but I’m so surprised people find it easy to learn compared to the others. It wasn’t an uphill battle but I found getting started with vue to be about the same, if not little more overhead, than react, ember, or angular 1, all of which I’ve played with a little.
Maybe for VueJS's smaller size. As for React or Vue, VueJS is simpler, easier to learn, compatible with web components, comes with default router and Vuex redux style store from the core team. So this avoid lots of learning time by new user as to which router to choose, should I learn redux or mobx etc. Typical React/Redux app is full of biolerplate, where VueX is hiding them. VueX also specify a default way of dealing with async, where's in Redux you have many options that could be confusing to new user. There is also bulitin html animation/transition support. Also web dev tools for Chrome and Firefox are from core team.
There are some other benefits like styled components / scoped css available by default and officially supported libraries for routing and global state management.
The one major thing I like about Vue is that I can use it to build widgets in an otherwise serverside app without having a JavaScript build step. All I do is link Vue directly and server-side include files containing the template and code for each component.
It is possible, but not a good option, to also use React without a build step by either skipping JSX (ugly and cumbersome to use) or by using the Babel runtime (large, not really meant for production).
I love Vue for its flexibility. You can write functional components with explicit dependencies, scoped CSS, and no state. OR you can just drop a CDN file on your webpage and have a bunch of global components.
To me, it's one of the easiest frameworks to teach and maintain.
While I believe React is technically a more correct way to write applications, it can be very heavy-handed. Vue is a great compromise for mixed front-end / full-stack teams.
I agree. In a perfect world React is probably a better choice. But the world is not perfect. I don't have time to investigate a gazillion third-party libraries and educate myself on best practices. Vue is a nice complete package with great documentation and excellent first-party libraries (vuex and vue-router). It's basically a one-stop shop into modern day Javascript. Ideal for smaller teams or teams without JS experts.
I love vue.js because it has made front-end development bearable for someone who has hated web front-end since 1995.
A bit of apples and oranges comparison but writing Vue felt just like first time I wrote Python many years ago: FUN
I write a lot of embedded Javascript (based on Spidermonkey) so I was happy to find that vue seems to make the same decisions I often make in my own code.
I am sure React is great for full time webdev of heavy SPAs but learning curve feels longer, plus the whole framework feels heavier.
I'm using vue, I found while the learning curve is higher than react it was a better choice than react if only because they don't introduce breaking changes into vue so what you write today will not suddenly be painfully out of sync in 12 months. With react while I found it easier to learn its very much a moving target, I found it easier to learn last year. Vue's not breaking changes do make for a larger surface area to learn in terms of the framework, but I have found vuex easier to use than redux.
Prettier could really use some example inputs and outputs for the supported languages. Sure, all of the settings appear to be documented in the API, but there's no concrete examples. I'd like know if its defaults look reasonable to me. I've seen some weird JavaScript conventions which makes me leery (e.g., jQuery). And I don't even know what that JavaScript/HTML hybrid is in the "Playground".
Briefly: there's _tons_ of style things eslint can't even warn about which prettier will just automatically fix. Most dramatically, eslint doesn't know how to wrap long lines.
Also, though, eslint offers a bunch of non-style code correctness checks, which is something prettier doesn't even try to do. So the general advice is to use eslint with all the style rules off, and use prettier to handle style.
Interesting to see that Webpack has continued to gain ground on Gulp as the leading top-level build tool that people use, because from my experience it seems slightly over-engineered for 99% of use cases.
Webpack uses the "configure a black box + add a bunch of plugins" approach to the front-end build pipeline, whereas I recently used Gulp to create a beautiful build workflow using Rollup, Babel ES6, JSX, Sass, and a basic livereload webserver in less than 80 lines of very readable, plain javascript code that would take roughly 5 minutes to explain to a new developer on my team faced with build pipeline modifications.
I also don't think many people understand that using Webpack encourages non-ES6 import semantics that will break your source code if you ever decide to switch from Webpack. Encouraging things like "import app.css" seems like it might confuse junior developers who don't understand what's going on under the hood, or have to eventually work in non-Webpack systems.
Sorry for the rant here, haha, I'm a huge fan of these surveys and love taking the opportunity to talk crap on build tools / frameworks :).
The whole front-end build process ecosystem seems hopelessly complicated and frustrating to me, but I'm a hoary, old, nearly thirty, backend developer. I've yet to have anyone satisfactorily explain why grunt or gulp or webpack is better than makefiles and shell scripts, other than "But its JavaScript!" Every month or so, dependencies break, and everything changes; it seems like a lot if work for very little result.
I hear you. Let me share you my findings, knowing that with 10 years only of experience, I found great comfort in this stack. It is not perfect, but it is indeed better than the previous one for me.
Portable - run on mac, windows, linux, others.
Embedded - ship with the project.
JS friendly / Integrated - for instance you can read and write from JSON/JS/APIs easily. Tons of plugins adapted to web and mobile related concerns. Try to minify CSS with make?
Adapted to modern hardware constraints - for instance, sharing global deps is not the default best practice anymore since HD space is not at premium anymore. Multicore/multithread is the default option, not behind a flag. I/O is the modern constraint, not RAM.
Limited knowledge to get started - imagine it is the first app you are making in JS, you just learned the diff between the browser and the server ;). Gulp takes you from where you are, make requires knowledge of Linux, bash, env variables, probably apt-get/yum, make itself. A place you have never been before.
Modern doc - it's my opinion, but man is an awful doc interface. No quickstart, it has a TOC, not a menu and no search bar sig.
Innovative 'cause no legacy - we wouldn't have investigated hot reloading, smart watch mode, "better" pkg mgmt.
Also, Webpack is a sequence of one-liner incantations that do things that would be annoying to by hand, like starting a websocket server to talk to your application to hot-swap the code.
The declarative config is an improvement over Gulp and Makefiles for that reason. Same reason I prefer pom.xml over build.gradle.
Bash and C absolutely suck to work with if you're not a systems developer. There's so many caveats, gotchas, extra ways to do things, hidden things you have to learn, and lack of clear explanations that touching any ordinary shell file makes me want to scream.
If someone wrote a "makefiles for web dummies" tutorial that told me exactly how to do things everything in bash I know how to do with javascript, I'd love to read it.
Make is it's own thing, and not really tied to C in any way.
I've written more makefiles for Java projects when I despised Eclipse than for any other reason. I'm sure that's completely wrong and fucking awful, but it worked really, really well.
While I can somewhat sympathize with wanting to use make, it's the dependency management with Java that would be just horrible. Maven-based dependency management saves you a world of misery most of the time. And when you have conflicts to deal with it's 1000 times worse doing it by hand.
I'm sure there are and will always be many more commercial apps compiled with Make than there are with the sum of all those done in JS spaghetti. So keep your Make skills up to date. I've been using it for almost 30 years! Now I'm really feeling old, seeing that I've used Make for longer than you've been alive - you hoary, old developer ;)
> Interesting to see that Webpack ... because from my experience it seems slightly over-engineered for 99% of use cases.
Overengineered? I feel like un-engineered is the right word for it. I use it, but I dread touching anything in my config, cause every time I do, something breaks.
I've tried gulp and grunt, and both of those are pretty bad as well. Different problems, but problems nonetheless. I'd love to see Parcel deliver on their promises, but as of right now it's alpha level for even basic use cases.
Curious what you dislike about Gulp? I keep hearing people poo-poo it and say that it's "totally uncool now", but I can't understand anyone's frustrations with it, especially compared to other build tools.
If you're familiar with the jdk ecosystem, I can make an analogy: webpack is to SBT as gulp is to gradle as brunch is to maven. Their styles essentially boil down to different philosophies (code-is-config, build-is-code, and declarative-config respectively).
Gulp takes the philosophy that build is code. You hand code all of your pipelines. That's works perfectly fine for simple applications where all you're doing is writing code in a single language (like say just javascript for a node backend), but I've found that it is an unadulterated nightmare trying to get things to work across types of files, as is required by front end development. Your HTML, Javascript, and CSS interact with each other in several different ways, and things no longer fit into a neat pipelines abstraction...it resembles a graph more than anything. Throw in transpilers or compilers, parallel processing pipelines (like for sourcemaps), and it quickly becomes buggy chaos.
I maintain that the best abstraction for a build system is that found in Make. Make is actually brilliant in some respects...it is a language for declaratively building a data flow between processing pipelines, but allowing you to use a Bash-ish imperative style to build those pipelines. The problems of Make are many: not everything uses files as inputs or outputs, not everything has a 1:1 input-output ratio, dynamically selecting inputs or naming outputs is horrendously buggy, etc.. But the concept and philosophy behind it are brilliant. If there is any build system of the future, it will be borrowing heavily from Make.
I don't think I understand how HTML, CSS, and Javascript interaction makes Gulp development complicated. My CSS files are totally separate from my HTML/javascript, and are just included directly in my index.html. I use JSX with React to do inline HTML markup inside my .js files, which Babel handles just fine through its transform-react-jsx plugin, included easily in a one-line command in my Gulpfile which is just a very simple "babel" function call configurable via a regular .babelrc file.
Basically, I have yet to hit any limitations with the "build-is-code" philosophy, despite years of people telling me it's an awful and horrible thing to do. I can't forsee my <75 line Gulpfile growing too much, as the plugin ecosystem is robust and I already have all the features I could possibly want.
For reference, here is my simple Gulp setup. Each line is easily readable and explainable to anyone who knows basic Javascript (and a single Node.js primitive called "pipe").
As I asked another commentor: If you can point me to a clear tutorial on Make that lets me do all the things this Gulpfile does with extreme ease, I'll abandon Gulp and use Make exclusively for all front-end projects.
Probably you're finding it simple because your Gulp build script does nothing more than defer to Rollup - a module bundler like Webpack - to handle JavaScript bundling. You're literally just using Gulp to watch the file system and kick off either cssimport or Rollup on changes, which you barely even need Gulp to do.
Plus there's no incremental building - all CSS or JS is rebuilt on every save, your server doesn't build the project when it starts and it can't do things like hot module replacement or CSS injection - the latter of which BrowerSync can do.
I'm guessing you're using this on your smaller personal projects, where doing a complete rebuild on every save is fast enough not to be an issue, and reloading the page on every change won't be a pain when experimenting with new features or debugging complicated UI issues.
Last year I was excited about Elm, this year about Reason. I follow a bunch of Reason folks on Twitter and see lots interesting projects. I also keep seeing React core devs keep dropping hints that React will be rewritten in Reason which makes sense since originally it was written in SML.
Since hearing about it we have a port of a large project in progress and whilst the typing is nice, the improvement in build time alone looks like making it a worthwhile exercise.
Big things to come I suspect, particularly with it feeling like such a natural progression of so much of FB's recent JS work.
> I find the data from the "I've used this but wouldn't again" almost as interesting as anything else here.
I'd love to see an explicit "percentage of those who've used it who would use it again" number for each library, easily glanceable. I think that's what most of us are probably doing in our heads when looking at this data.
I wonder how much correlated the pay/framework data is? A lot of orgs I know using Vue.js moved to it from jquery -- so I suppose a lot of people using Vue.js might use in the same way, for just a bit of dynamic functionality. React seems to be more popular as a full front end solution, as opposed to just adding a few dynamic effects.
“The Progressive Framework” marketing of Vue is both appealing and accurate. As a shop that has both applications that reside primarily server side and have jQuery spaghetti where needed as well as full front end SPA applications Vue fits the bill for both arenas.
IIRC the survey was open in July/August. But it took the authors 3+ months to produce this result, which IMO has very limited commentary. It would have been much nicer for such a time-sensitive survey to come out sooner.
While that's in line with what the Angular team has communicated to differentiate 1.x and 2+, I disagree. Since "Angular" is unnamespaced and "AngularJS" is not disambiguated enough from "that JS library called Angular", I think the numbers are important to outsiders.
My org has been dealing with Angular and AngularJs for the past two years and developers and non-developers alike get confused or unclear all the time when we try to communicate about the two. The only thing that's been successful has been to describe them as "Angular 1.x" and "Angular 2+".
On top of that, when doing searches for documentation and issues, it's still absolutely necessary to add "2" to searches for the right version of the framework.
It's pretty rough on newcomers as well as devs trying to find docs and blog posts, but in contrast to naming it something else, it was pretty effective at establishing a user base.
It would have been a lot easier on the world if 1.x was the last version of anything called Angular and Google named the new thing FooBarJS.
But Google knows how software teams work. Names and versions are easier to evaluate than trying things out or running comparative analysis.
Teams hire "Angular" developers which usually means "1 or 2" even though it very much shouldn't.
Teams will set aside time to "upgrade to Angular 2" more freely than they would set aside time to "switch to a different framework, FooBar.js", even though with Angular 2, those are the same.
Even if teams would set aside time to "Upgrade to new framework", they're much more likely to do a alternatives analysis if it's not just a version number changing.
That said, I think this hurts developers and teams, and I think it's loosely nefarious, but it was probably necessary for Angular 2 to get the adoption it has today.
It's going to be one of the case studies about why it is awful to go about creating a new version of a language/framework/library that has massive breaking changes but keeps the same name.
By wanting to learn Angular you're definitely riding against the ecosystem, as shown in the post, see: http://stateofjs.com/2017/front-end/results and note that most do not want to use it/or have used it and would not use it again. (Myself I am in the would not use it again camp). What makes you interested in Angular as opposed to other front end frameworks?
Honestly, I am more interested on learning React. I was only teasing about learning Angular for it was a complete framework unlike React. But, now that I've realized that we can integrate other components with React to outperform Angular, I'll definitely learn React.
Angular 4/5 is simply the continuation of Angular 2, so it's more like 2/4/5. The Angular router had been up to a major version 3 so they skipped Angular 3 as a whole in the interest of keeping all of the parts of Angular in version sync.
Starting with the latest version of Angular is generally the best idea, though you may be tied to earlier versions depending on what other modules you want to use. For example, the npm version of ng-bootstrap is still tied to Angular 4 (though one can easily build one that does from the github repo). I would recommend starting with ng-cli as most (older) books will start you off with some other build system (e.g., system-js, an older webpack plugin).
If you don't know a ton of other frameworks, tools and the like AND need to get something built this quarter, learn the latest version of Angular 1.x
Otherwise, learn Angular 2, Typescript and all the other stuff that people use for building etc. all at once, focusing heavily on Typescript and core Angular concepts first.
Nothing prevents you from using CoffeeScript with the "ecosystem". CoffeeScript is just alternative syntax. Version 2 outputs ES6 code with compatible classes, etc. It also supports JSX out of the box (with the help of babel), there are webpack/browserify/etc plugins.
I'm becoming fonder and fonder of RiotJS (http://riotjs.com), although I've tried to get into Elm (and failed, largely because I'm not fond of "compilers" when I'm iterating quickly). I'm cool with working with a niche thing that I can sit down and read the entire codebase for in a single morning, though, and that doesn't seem to be a survival trait in front-end development :)
Ha, I use Elm because it allows me to iterate quickly, especially as I don't need to run the app to find out if there are bugs, since the compiler catches so much.
I feel like some underestimate the .NET framework. Microsoft has done a great job of really opening up and building a better eco system for developers to work with. Years ago there was a common stereotype that .NET was old and not cool. I believe it still has a place and is a strong server side framework.
dotnet development targeting linux is painfully slow. on my macbook, with a relatively small asp core project, there is a 10-20s overhead to run any quantity of unit tests. i believe it will get better, but right now it's a bad choice.
I have a project with 36 different entities, 100s of endpoints, and way too many abstractions (coming close to the enterprise-Java levels) and for me, it takes 8 seconds for a cold start on a 7 year old mac mini with an ssd (around the same when running tests). I find it not perfect but acceptable.
The menu is broken for me using Firefox mobile. I can't scroll down, it just keeps snapping back to the beginning of the list. (That's my state of JavaScript :)
I really like all this information and the way it's presented.
I used to do web 'things', but have been out of the loop for quite some time now. I'm intrigued by the idea of doing everything with one language / ecosystem.
So, I'm asking you - as an ye olde php (and laravel) guy, where would one even start? I guess node.js and expressjs is where I look first and then branch out? Also, what's with the build systems? Isn't it js?
Node.js and express.js are server side. Use them for your API. It's pretty simple to grok if the docs are read. The docs for both are pretty good.
On the client side, I personally use vue.js + webpack. It works for me. With the nicely focussed supporting libraries (vuex, vue-router, vue-resource), I find it easy to write performant, maintainable code.
I've also written a few react apps. It's basically a slightly different approach to the same problem. It's a more mature community and has better testing solutions.
Either are good bets. For a build system I prefer webpack despite the apparent complexity. It's really just a way to transform node.js module into modules you can use in the browser. Gulp is an option but if going that route I'd just use npm scripts
I recently had to build a small web app. I mostly code for fun, and I've been writing Python for years. I was able to learn how to use VueJS with single file components in about a week, with Flask as a backend, plus Bulma as a CSS framework. Nothing fancy but it works flawlessly. Also, the Vue team offers a Webpack template so I didn't have to spend a minute learning about that.
Overall very pleasant experience.
Edit: woops, forgot to say what I actually wanted to say! You don't need to write everything in one language. I actually abhorred that idea, and glad I found a stack that 1. doesn't need much maintenance 2. doesn't force me to spend countless hours learning about why XYZ is better than ABC and how QRT were wrong about this and that and learning 100 different new concepts and terms. I put together the stack myself, and it worked without me having to bend my programming knowledge to the particular task. There's value in this.
It is opinionated (as in, it picks a single option; webpack instead of gulp, react instead of angular or vue), but I think it does a good job of introducing things in isolation. I ran through the tutorial a couple times after I was more familiar with things.
>ye olde php (and laravel) guy, where would one even start
Both PHP and JavaScript started as ill-conceived and/or rushed-up projects that due to (different) circumstances became hugely popular, and thus, the warts and faults started to be addressed and corrected little by little.
In this "correction" process, PHP 7 is much more farther away (more advanced, more mature) than the current state of Javascript, so i'd advise to stick to PHP 7; for the front-end, if you want to explore what you could do with heavy front-ends (i.e. Single page apps), try something like ClojureScript rather than straight JS.
It looks like they're purposefully grouping together front-end and back-end state management. Why do that when they often (if not always) serve different purposes?
I know this is just trolling, but it thought it was ironic to get this clichéd criticism about complex dynamic data visualizations, which for once are precisely the kind of thing that JS is required for…
As far as I can see there is only one dynamic visualization and the rest could have been handled with static images, but they don't work with javascript turned off. Even the dynamic one could be a static image and progressively enhanced with javascript. So I stand by the overused comment.
I can't read the text on this site. Does anyone know a way to permanently disable "font-weight: <=300" for all websites in firefox without resorting to anything as heavy as Stylish, or will I need to write my own extension? There's a minimum font size preference, but not a minimum weight.
I'm not sure you could do exactly that even with Stylish as there's no way in CSS to match elements based on their style - you could define a global font-weight just by adding this to "chrome/userContent.css" in your profile directory, but that would override every font-weight on every element:
Ubuntu 16.04 + Firefox 57, Ubuntu 16.04 + Chromium 62.0.3202.89, macOS Sierra + Firefox 57. Inaccessible to me on all - the font is too thin for me to read. I can't scale the font size up high enough either as the layout breaks. I used the `font-weight` hack initially, but after I clicked a couple of internal links that reset the override, I gave up.
I'm not sure it's Javascript's fault. The ecosystem that is using it would have found a language to live somewhere.
The idiom of ephemeral, throw away, spaghetti of dependencies was born out of the way the web platform moved forward, the short lived nature of websites and web apps, and the spread of developers with different backgrounds that were working on it all.
If we were using Javascript to develop native windows apps then I am sure the ecosystem would be very different. However, that would be dumb, right? cough
It doesn't have to. I've said this in a few other threads lately: I'm using intercooler.js which is basically HTML++ for a lot of my work now, and I barely ever write javascript unless I need a front-end plugin of some sort.
You get 90% of the functionality at 10% of the complexity, and your back end looks essentially the same as it always has, in whatever language you want.
As much as I would like to have something different for the browser (such as Scheme, as originally envisioned, or Lua, which would have been a better fit), the world has moved on.
Only hope is to compile to javascript or webassembly (or "transpile", as js folks like to call it).
It is a good book and there's definitely lots of bad to go with the good. I describe JavaScript as a pyscho gf or bf depending on the audience. Everything's fine until it goes wrong then it goes real wrong real fast.
I'm guessing this correction would make it more confusing for more people than it would help.
Perhaps "AngularJS" and "Angular 2" would make an appropriate compromise between being correct and being clear to people not as familiar with the Angulars' release histories.
In general I think tooling needs to improve, and neither Webpack nor Gulp are painless. Neither is maven, I suppose...