Interestingly, things seem to be settling down in the JS community. In the past, every time a library lacked a particular feature, the community suddenly abandoned it. At the same time, every new version release had all sorts of horrible breaking changes, that made upgrading a very scary task.
Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer.
I'm still skeptical. Webpack is one of the saner ones. Many JS libraries are still doing break-everything major version releases- Babel and Angular come to mind.
That's what a major version is supposed to signify though, isn't it? Most JS/NPM-based projects use semantic versioning, so a major version update means breaking/backwards-incompatible.
Are you complaining that things get updated? You don't have to use the absolute latest versions of everything, you can still use older versions if you want.
Caring about upgrade paths is super important to the longevity of a project. See: Python 3 vs Ruby 2 adoption.
Taking the mentality that "I can break everything and just bump the major number" will lead to a project that either 1) is no longer is used by many people or 2) is a maintenance hell because people are staying on old versions and asking for bug fixes and improvements.
yeah, we're very much building on top now. There's still a few competing options for everything (and that's a good thing! You need SOME competition to ensure nothing stagnates), but we're mostly done redoing everything from scratch.
There's still a little churn in the framework and state management world, but the existing options are more than good enough for years to come and nothing drastically different is popping up into the spotlight anymore.
>> Interestingly, things seem to be settling down in the JS community.
As a front-end dev, to me it seems to be zipping along at the same, old faster-than-it-should pace it has for the past few years. Depends on perspective I guess.
> Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer.
That's exactly why the blog post suggests using yarn instead of npm, isn't it?
Have you used yarn? Do you know what it is? It's a fully backwards compatible client built on the npm packaging system, using npm's repository, and built in collaboration with the npm team.
It's not quite ready for production yet. There are still some bugs with dev dependencies and private repos that need to be addressed before we can use it.
I currently use gulp and, over the yars, have found many ways to do my own parsing and smart caching and stuff over, like checking and bumping version numbers, conditional compiling, caching assets etc.
I'd hate to loose all that, but I do see the advantages of Webpack. How much control do I have with Webpack though? Can I still write my own hooks?
The vast majority of anything you'll ever need, even in absurdly complex scenarios, are built in.
If you need to do something really wild and weird, the plugin and loader architecture will let you do pretty much anything and hook into nearly everything.
We're dealing with a legacy environment here and we have a suite of plugins and loaders to handle non-standard module types, deal with files pulled from CDN at build time, deal with legacy Rails-style script imports, plugins to do all sort of bundle validation, splitting, transforming...really anything goes.
The thing is Webpack does all generally needed web building stuff out of the box and there are plugins and addition loaders. You can define needed behavior in a kind of way having no need dealing with Gulp mess. I used Gulp before, then switched to the Webpack and have already switched a few projects to the Webpack v2. Webpack is a gulp of fresh air, much convenient than Gulp or similar stuff using which you will have to write your own framework.
That's my concern as well, I use browserify and a simple bash script to do some clever stuff I couldn't reliably do with Grunt, I'd hate to lose the flexibility.
Why not use them together? Bundle your assets with gulp and bundle your code with webpack. You've already had to solve the problem of linking from code -> assets, which is what webpack solves by bundling both.
We have experienced issues getting sourcemaps support to work in Webpack 2 and had to use Webpack 1 instead. Lack of sourcemaps is a deal killer for us and for any major application IMHO.
Has anyone experienced the same and has this been resolved?
Rollup's gains come mainly from the way it combines modules into a single scope, rather than wrapping them in functions and shipping a module loader with the bundle. It's not uncommon to see parse/evaluate time plummet when switching to Rollup because of this, which is often more important than the number of bytes.
However Rollup currently lacks a lot of features that make Webpack a good choice for large and complex apps.
FWIW, Rollup's tree shaking results in a little smaller bundle than Webpack 2's and faster execution speed of the optimized code from testing of using it with ng-bootstrap (an Angular 2 library on top of Bootstrap), but not significant enough for us to justify moving our demo to Rollup.
Webpack still uses module wrappers, so tree shaking is mediocre in it (and I don't know if its still the case, but in some situations Webpack used to make the bundle LARGER when tree shaking was enabled).
The way we're looking at it, you use rollup to pre-bundle libraries where you want all of the dependencies inline and use tree shaking to make those as small as possible. You then consume rollup's output from Webpack, thus making dev time builds much, much faster and the resulting output super small.
Semi-related: I also found it useful to name the config file webpack.config.babel.js instead of webpack.config.js so I can use ES6 in my Webpack config.
Also see interpret [1] which is used by Webpack internally (afaik). For instance, when you name you configuration webpack.config.ts it will be transpiled by TypeScript before being loaded.
No longer really needed. Node 6.X and 7 support pretty much all of ES6 minus imports. Using require instead of import is a very small price to pay to get fast startup time. You can use everything else ES6.
Webpack 2 is so awesome that I'm really confused why haven't they released it as a non-beta yet. It's way past MVP and has more than enough quality for a non-beta. It looks like the maintainers want it to get perfect and release it "when it's done", and that is so wrong.
Can you please add some documentation for sourcemap and debugging to the doc?
WP 1's sourcemap doc is confusing as hell and WP 2's doc just copied that over. I imagine debugging un-transpiled code with sourcemap is one of the most common use-cases.
And I'm not alone if you look at the disqus of WP's doc[0] and a blog by @bebraw[1], one of the guys running webpack.js.org.
I even opened an issue[2], I hope it can make into your MVP.
By all means we take PR's as well. Our MVP list is pretty set in stone and we don't want to extend our timeline. However simply by adding the issue to the new docs repo, I'll make sure the information will get prioritized for adding.
Well, I think it's commendable and shows how much they care about their work. Caution and deliberation seem to be lost virtues in most of the JS universe. Take as much time as you need, Webpack team!
Releasing in beta is not wrong, there are many really needed by default plugins and loaders that are supposed to work well with v2, so some time is needed for the transition period.
1 point of minor interest is that they start by using Yarn, not NPM. Little things like that (esp from a major project like Webpack) can develop into definite trends.
> Maybe the author is trying to make Yarn a trend?
The JavaScript community makes me a cranky old man, because yarn is even a very good idea and solves actual problems. Still that was the point in the article where I thought "fucking JS hipsters". No time to play with tooling, when there is actual work to do.
Especially with other people in your team, whose time costs actual money, I think standardization of dev environments and tools trumps almost every new feature (as long as you were using tools in the first place).
I have seen the talk (I believe it was from Instagram), which showed how Webpack could work with shared code and so on, but still: Browserify and Gulp were already working (and I believe can now do the same thing) and even Gulp has only very marginal benefits over Grunt in my opinion. I would love to go a few steps further back, but "installable via npm" is just a crushing argument against Makefiles.
Gulp and Grunt were essentially wrong. Using a task runner as an asset pipeline makes no sense. A lot of things, like doing incremental compilation of Sass takes 100+ lines of Gulp crap to do, while it's the default in webpack.
Browserify was nice for simple cases, but getting it to do what's needed in a large, real world application was really difficult. Lately it has a lot of those features, but when Webpack became popular, it just didn't.
I started using Webpack after doing a length cost/benefit analysis and settling on.....gulp + browserify, because WebPack looked too complicated and people in the team had experience with browserify. After a week of trying to get it to do what we needed, I tried WebPack again and did it in an afternoon. That's when we switched.
They were not wrong, but they do a general automation (and sometimes it's needed), just a task runners and a wrong thing was to use them for web building automation collection scattered over the internet stuff together into the complex framework. So every team or project had own framework, which means no standard, and that's a bad thing. Webpack allows to defined a needed behavior in a kind of declarative way since it has a structure.
You get dependency management (resolution, pruning) for free from Closure and declarative build targets from Bazel. (Including dependencies on other targets, e.g. non-module-bundle.js)
To be fair, I don't think the (publicly) available rule set grants parity with webpack, but the syntax is a lot less gross and the concepts have been there from the start.
Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer.