Webpack 4 Beta released
medium.com
medium.com
Remember that the Webpack team has shown to be actively hostile to people who just want to keep their 2-year-old codebases work without doing needless upgrade work. They removed the webpack 1 docs [1], so if you have a few-years-old codebase that you want to get up and running, and somehow you get a webpack error, the message from Webpack is "screw you, upgrade to webpack 3 first and only then we'll allow you to read the docs".
I have no reason to not expect the same to happen with Webpack 4, and the inevitable Webpack 5, 7 months from now. Webpack 2/3 docs will be subtly removed, retired and forgotten. We're all forced to keep doing work to make something work that already worked perfectly fine.
Now, I'm well aware that an angry rant on the internet about the voluntary work from open source contributors is not particularly constructive. I've singled out the Webpack team here, but the reality is that a big part of the web dev ecosystem, across languages, does not care much about backward compatibility. I'd love for that attitude to change.
In semver, every major version is a tragedy.
Most breaking changes are to accommodate the number one ask of our users: faster, smaller builds.
We asked what the time frame they wanted for releases. We got out of a couple thousand responses 6mo being the sweet spot. Appreciate the candid feedback though.
In regards to the v1 docs: we wanted to have a fresh start. I don't imagine our docs pages now changing for awhile. Each major breaking change we ship a migration guide so that people can upgrade.
This time I'm the one complaining, and I must admit that I'm curious about the exact wording of that question about release time frames. If you asked "how often do you want to make config changes just so you can update Webpack to the latest version", I bet many people would answer "never" instead of "6 months" :-)
But hey, we established that we have different ideas about what the compat sweet spot is and you and yours are the one doing all the selfless work and I'm the guy complaining on the internet, so take everything I say with a bag of salt.
All that said, any chance you could make a teeny tiny little link from the Webpack 1 "THESE DOCS ARE GONE" pages to http://devdocs.io/webpack~1/ or some place like that? There are people who inherit old codebases and it would be very nice for them to not _have_ to update Webpack just to find answers to their problems.
I'm highly supportive to anything they can do to make it easier to configure and maintain, even if the cost is breaking the old APIs and making folks migrate to newer ones.
Hopefully as someone works on a library and learns a problem space more thoroughly, they have better knowledge of what an ideal API would look like. I know migration can be painful, but I'm very supportive of long-run improvements to a project.
Those who inherit a old codebase normally don't have the luxury to start fresh, or sometimes even upgrade. The work and effort you put into webpack is selfless; which is great; and you should be thanked by users! Removing the v1 docs was selfish, and unfortunate.
TFA:
> For the full list of changes, features, and internal API modifications, please refer to our change log!!!
Link: https://github.com/webpack/webpack/releases/tag/v4.0.0-beta....
Although with that said, I doubt webpack can do anything about what you're saying except to try to be conscientious. Obviously breaking too often is bad, but naturally that doesn't mean never ever breaking is necessarily preferable.
I agree with the nuance you add, but also note that the last major version was released July 2017. This is not "never ever breaking", this is breaking all the time :-) There's plenty middle ground.
A lot of the breaking changes could be solved by versioned config formats, for example. Maybe not all, but then maybe the remaining things that are now breaking would be worth keeping alive, albeit as a piece of legacy code that nobody wants to work on improving anymore. I don't know enough about webpack internals to go deep here, but I'm convinced that if there's a strong desire to stay backward compatible it's possible. The webpack team has no such desire, which is their prerogative but I'm still sad about it.
So I'm not sure it's fair to decide the devs don't care about breaking changes. It seems more reasonable to assume that some wrong choices were made early on (including about how to handle docs and major releases), and they've been learning and getting better since. After all, if like most things it started out as someone's weekend hack, with no thought of growing into the powerhouse it is now, some early stumbles are fair enough, right?
webpack 2 introduced ES6 syntax in their plugins which grunt mangles when passed to its config https://github.com/gruntjs/grunt/issues/1595. Admittedly that's a grunt issue but seeing how many teams use this tool and have already configured their applications to build via Gruntfiles we can't move things overnight. I had issues with loaders (now rules) running at the appropriate time for istanbul as well and had to go through two or three now-defunct packages and piece together how to make it work with our rather unique setup. Honestly in this adventure I think our issue is grunt and the underlying bespoke hacks people have designed over the years, but in Enterprise this just keeps me from being out of a job.
You generally should not be ignoring your tech stack for 2+ years in the first place either - nobody likes spending time staying on top of updates, but that's the world of software.
As for your complaint about backwards compatibility, I'd agree, but there's only so far you can go backwards before it comes pretty ridiculous to support ecosystems so far behind the curve.
In search for something that makes me work like the good old times, but with modern javascript solutions, I stumbled upon mod_pagespeed[1]: it minifies your javascript and html, optimizes images, and more or less does what webpack does (minus the typescript -> js compilation).
The good old times are back for me: deploying is now an scp away.
For important projects I copy the static assets to the server, let jenkins run integration tests on staging and if everything works as expected just copy it over to production. One less thing to worry about for me.
I do remember. I've been doing web stuff for a little over 20 years. It was not a good time.
1. If a file upload failed your site was broken until you managed to upload it again.
2. Deploying something that required a database migration had to be done out of hours, or the site had to be taken offline to do it.
3. Recovering from a disaster was hard, and pretty much always resulted in significant data loss.
4. Moving a site from one server to another was awful, because it meant SSH'ing (or telnet'ing...) on to the box and compiling things from source. If you got anything in the environment wrong the site didn't work and you had to start again.
5. If you worked on anything that ran on multiple servers you pretty much had to script it all anyway. Essentially there were thousands of different (much worse) build-and-deploy processes people had stuck together with various different tools. Going to a new company meant learning a completely new set of processes. Today's processes are just an industry-standard best-in-class approach to doing the same thing.
I'll take Webpack to compile a site and terraform/compose/puppet to deploy the infrastructure over old way of doing things every time.
I don't think an scp ever went wrong for me. But maybe your lan network is different.
> 2. Deploying something that required a database migration had to be done out of hours, or the site had to be taken offline to do it.
Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend.
> 3. Recovering from a disaster was hard, and pretty much always resulted in significant data loss.
I don't know your specifics, but recovering from a disaster in this case is getting up an other server (or serverS) and copy the files over.
> 4. Moving a site from one server to another was awful, because it meant SSH'ing (or telnet'ing...) on to the box and compiling things from source.
That's the nice thing about mod_pagespeed: you don't compile anything.
> 5. If you worked on anything that ran on multiple servers you pretty much had to script it all anyway.
What's wrong with scripting everything? I like automation.
When I started doing web things rcp (or scp, or rsync, etc) access was quite unusual. You had FTP and that was it. It failed a lot.
Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend.
Fair enough. I don't really see the front end asset pipeline as being separate to the backend. It's all just stuff you build and deploy.
That's the nice thing about mod_pagespeed: you don't compile anything.
Well, you do, but you're happy just accepting the mod_pagespeed defaults are doing a great job (which they are). I want a bit more control over things, and I want to do things that mod_pagespeed can't do, which is why I use Webpack instead. A trivial example: mod_pagespeed doesn't do subresource integrity hashes. Webpack has webpack-subresource-integrity as a plugin that can automatically write hashes to your html. That's useful to me. It's good that there are different options for different things, and better that the industry is coalescing around small number of different tools so there aren't too many different ways of doing things.
What's wrong with scripting everything? I like automation.
Nothing at all. Automate all the things! My point is that back in the olden days of making web things we didn't automate things, so it was much, much harder. Today's tools (eg things like Webpack) make automating your build process pretty trivial. It's far better now.
And sure, staging then copying everything would be faster and safer than deploying straight on top of the old version, but that's still a not-insignificant amount of time when the app is in a transient, partially-upgraded state. And that would only get worse as your app grew.
I suppose to way around that would be to deploy twice and use a load balancer that you could temporarily disable, upgrade one deployment, point the load balancer only to there, upgrade the other one, then re-enable load balancing between them.
Man, that's a lot of work, though.
I'll agree that maybe it's a relatively minor complaint, because there are likely plenty of solutions I just never needed to find, but I really do like avoiding anything that can and should be avoided. I'd rather have a "Please wait while we upgrade" page than risking something going south due to some kind of race condition.
FTP did fail a lot indeed. That is why scene (FTP / FXP) used .rar, .sfv and Usenet .rar, .par(2). Download clients had resuming support but did not attempt verification. That's why checking checksum is important (Sfv is just CRC32 and Par is Reed Solomon, other examples are MD5 and SHA1).
Later on scene used so-called auto traders, which utilized FXP and automatically verifying checksums plus anticipating on errors (such as dupes). The I know was called Preee (Windows only, worked in Wine). Later protocols like BitTorrent implemented checksum verification within the protocol.
The main point of webpack isn't minification and so on, it's wrangling dependencies. It lets you define a JS module, which can declare dependencies on other modules or assets, and so on recursively, and webpack parses everything out and bundles the necessary pieces together such that they can all see each other.
If your JS isn't in modules, but just files that can be uploaded and minimized, why were you using webpack in the first place?
Uploading some files is fine for simple websites with no availability guarantees or security requirements. Mod_pagespeed is fine for most websites too, I should install it for my wordpress instance sometime. It's not effective for single page apps though.
- parcel bundler (Real fast, cached compilation is under 1 second) : This bundles all my TypeScript as 1 JS that works in the browser and Stylus into 1 CSS along with dependencies such as jQuery and I no longer have to place script tag for those external dependencies but they're bundled among their dependencies from npm installed copies.
- ts-node-dev : Reloads the node server automatically in about a second as I update my server side TypeScript and it doesn't even require compilation process to spit out .js files.
- monit : To monitor those 2 processes to make sure they're alive and auto restarted in case the process quits for some reason.
The point is, setting them up is very easy. I don't even have a config file for the former 2 and easy readable one for monit.
I don't like client side transpilation and bundling as it requires every machine even under different OS to be set up properly exactly the same.
Now I no longer do any manual build or wait on each incremental changes but the "good old days" are back with the added benefit of using TypeScript and npm ecosystem in the browser with no effort. I'm impressed.
Yep.
That in sense is webpack's job: It allows you to boil down a huge list of interconnected complex dependencies into a neat, portable, highly deployable package.
Build tool - with this way of organizing things - can be `cat`, simple 20 line php script to bundle icons together with `montage` that comes with imagemagick and direct invocation of `sassc`. Build times are 100ms. Simplicity is priceless. There's never any migration, no new features, no deprecations, no maintenance issues, no instability, because everything is so stupidly basic. You can jump 10 years forward, and app will still be buildable from git with only tools available in your OS distro.
It's written in ES5 though.
Live reload with ExtJS app would be a nightmare even with webpack. On-demand code loading optimizations are not necessary. Tree shaking would not help much at this point, because I've removed unused components manually. Proper namespacing (if you mean ES6 imports) would not help much. The app is self-contained and uses only a few external dependencies.
Not really.
Just copy/pasting the menu from their website:
- Asset Management
- Output Management
- Hot Module Replacement
- Tree Shaking
- Development
- Production
- Code Splitting
- Lazy Loading
- Caching
- Authoring Libraries
- Shimming
- TypeScript
- Progressive Web Application
- Migrating Versions
- Environment Variables
- Build Performance
- Development - Vagrant
- Dependency Management
- Public Path
- Integrations
The V4 will add features like WebAssembly support.
My thought is that I would have to do specific work that I can't imagine Webpack could "guess" would work for me in every circumstance...
var myComponent = import('./myComponent')
import myComponent from './myComponent'
Reference: https://webpack.js.org/guides/lazy-loading
If so, what does this improve? Time to first paint? Time to first interaction? Time to DOM ready? I looked at their page, and it doesn't seem to answer questions like this simply. It just says when a user requires the code it loads it.... huh?
How much code are people putting into their apps that this would ever be needed? (serious question)
When I do site analyzing, 99/100 the images/css are the biggest contributors to site size, have JS libraries gone nuts?
> If so, what does this improve? Time to first paint? Time to first interaction? Time to DOM ready?
Could be any or all of those, yes, depending on architecture. Webpack bundles CSS, images, etc into combined JS files ("chunks"), tries to get the important hot path stuff into the first chunk, and then load other chunks as needed. With dynamic loading you can further make sure that additional chunks load out of the hot path, after first paint/first interaction/DOM ready/whatever else.
So this static async bundle creation helps ensure that you are only shipping what you need on initial download.
To be redundant (for absolute clarity) you know how to use Webpack, you do use it, it offers value to you, but not for building websites? Can I assume it only has value (for you) with building complex webapps? (can I also assume this is for Node.js?)
https://electronjs.org/docs/tutorial/about
This says it's made with Node.js...
import('./myComponent').then(myComponent => /* ... */)
const myComponent = await import('./myComponent')
const dynamicComponent = await import(/* webpackChunkName: "components" */ `./components/${componentType}/index`)Actually I did!
What I do now is this: there is a websocket connection always open with the connected browsers, and when there are some assets that reallyreallyreally should be refreshed, I send a command though the websocket and the browser (after a few client side checks, like making sure the user is not in the middle of filling out a form) executes ´window.location.reload(true);´
For example, with version 4 there are opinionated defaults and for some cases all you need to do is `webpack`, you don't even have to have webpack configuration file if you stick to the defaults.
Now the other problem, however there are no defaults in web - one uses react with less, other angular with sass, etc..
For anyone else who was confused by the minimal explanation of the "sideEffects: false" feature, apparently this targets cases where (1) module A exports some code, (2) module B imports from A and exports end points, some of which depend on A, and (3) module C imports code from B that doesn't reference code from A.
In this situation by default webpack assumes that the code from A might have side effects inside B, but if A declares "sideEffects: false" in its package.json, the tree-shaker will assume it's safe to omit module A from the final bundle.
Incidentally the end user can also declare in their config that module B should use sideEffects:false, even if the module doesn't declare it. Details here: https://github.com/webpack/webpack/issues/6065
However with this release I'm excited to start deleting a bunch of ridiculous build code to make Webpack work. Really a build tool is a tool, it should never be in the way of developing features. I haven't enjoyed using webpack until now. No sensible defaults, poor documentation, and no standard conventions. This release changes all of those complaints. A boost for productivity is a win in my book.
Probably the reason you perceive this obsession with build tools is that incrementally each one had the goal to tackle a set of problems and it did, but then new pain points appeared and other tools were developed to help with that.
That being said, we seem to have reached a rather stable period without major raptures in the landscape for a couple of years. Maybe the growing pains are subsiding.
All of it is ultimately to turn JS into a good language. Considering the state where JS started, it's been a heroic amount of effort.
- Lack of native module support. - Lack of standard libraries. - Need to run in the most hostile environments AKA web browsers and in windows/linux/macOs as nodejs.
Web pack, minifiers, transpilers etc are working( although, not pretty) solutions to the afore mentioned problems.
Could you please take the spirit of this site more to heart, as described at https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newswelcome.html? That means posting civilly and substantively, or not at all.
Aaand that their communication has improved a thousand-fold.
For sure I do care about my build toolchain. The nice thing about being a React developer today, is that thanks to create-react-app, more specifically react-scripts [1], I'm thankful I get to choose to not worry about it. Just like I didn't have to worry about 2.0 -> 3.0 last time.
Cheers to the CRA maintainers. Thanks for giving me some time back!
[1] https://github.com/facebook/create-react-app/blob/next/packa...
If you get a lot off runtime errors you have an easier time migrating to CRA, if you eject a new CRA app and gently/iteratively adjust the webpack config on your existing project to match CRAs.
https://medium.com/webpack/webpack-http-2-7083ec3f3ce6
To quote the article:
There is still a protocol overhead for each request compared to a single concatenated file. The compression of the single large file is better than many small files. Servers are slower serving many small files than a single large file.
Sending the whole file again is the easiest route for developers, but the most expensive for mobile only cord cutters.
The point is there is a tradeoff between speed & efficiency. If every line of code were its own file, you'd have a high amount of efficiency when only 1 line changes, but loading that would be a nightmare on mobile.
Also, it's not for websites with some interactivity, it's for big giant web apps... apparently.
It sounds like webpack-dev-server will also disappear soon, too? (Replaced with a more tightly integrated solution, or?)
I'm all for rapid progress, but the pace of web development is absolutely breakneck.
Using webpack+babel will be faster than gulp/grunt+babel since webpack can track which file(s) changed & rebuild only those files. Even ignoring that, it still faster because you don't have to kill it & cold restart it when switching branches or adding new files, like with a gulp build which typically globs for files only at startup.
Also, does it really make things faster? What about HTTP2/SPDY, do we really care about making everything one file anymore? This seems like a paradigm that is no longer valid (like using tables instead of grid for website layout).
What is the benefit gained from "code splitting"? Would it make a blog run faster? What if the largest amount of JS on your site is 5k? Why would there be a need to code split this?
Also, yes, HTTP2 throws in additional considerations, though the surprise for me is that I've found even with direct filesystem access like in an Electron app, with no "connection overhead" like HTTP1.1, webpack bundles can be quite effective for performance gains. Especially with modern ES Modules, it can still be extremely effective to load a sequence of larger tree-shaken JS file all at once than a large number of tiny files.
Code splitting is great on bigger webapps such as GMail or Facebook. For instance, when you want to see your contacts on gmail, it can load the required JS file of that module on demand. Same thing on FB: the chat widget can be loaded separately, and only if needed.
A while back I went through the process of evaluating a lot of build tools, and I simply couldn't see any benefits of replacing my bash scripts with these tools, and you cleared it up nicely.
Maybe there are some legitimate cases in which you would prefer Webpack, but I really don't understand why have EVERYBODY migrated to Webpack, with all its bloat and breaking changes and build errors and boilerplate.
Just bundling. No lang->lang transpiling or asset munging.
Are children developing webpack?
Using emoji everywhere is very much in vogue and many people like it. It doesn't make you childish.
We (for some value of we that includes me and simooo) are just old, or old-fashioned youths.
Polluting the titles with emojis feels unnecessary and childish to me. I them a mental burden that makes it difficult to read the important information. I can not imagine a new car announcement page filled with emojis and I don't know why it should be different for software.
rocket - webpack 4 beta... Guess that means launch
present - A promise fulfilled... Present, I guess thats ok
confused person - How to install.. hmmm
rocket - performance.. I guess rockets are fast
fire - Better defaults.. err...
Strong arm - Better defaults.. err...
cake - side effects.. what?
Goat? I think it's a goat - Module Type’s Introduced. what the fuck.
Add shrugging guy on a skateboard ascii art here.
I don't want to live in whatever grey world you folks are imagining where everything is done professionally with no personality.
I remember some tools that I appreciate, that quote all contributors, in a non hierarchical way. Even if you contributed something minor, you are listed with "main" contributors.
https://rollupjs.org - JS module loader with tree shaking and async loader that works out of the box.
Asynchronous loading and code
Take a try if webpack takes toll on your productivity
We (the Rollup team) would never criticise webpack in a forum like this in order to promote our own alternative (except maybe on Twitter, because trolling Sean is just too tempting) — it's an outstanding project, and we all talk to each other and learn from each other. Rising tide lifts all boats, etc
Historically Rollup has indeed been more widely adopted among library authors (React, Vue, D3, Three.js, Leaflet, Moment, etc), though there's no reason it can't be used for apps — lots of us are doing just that.
and yet
> Rollup has a powerful plugin interface that lets you transform and load files of any kind — see here for a (possibly non-exhaustive) list
So yes, it is primarily aimed at libraries, and "out of the box" flies out of the window when you move to apps.
grunt -> gulp -> browerify -> webpack -> parcel?