Publish timing comparison with Webpack

[natew]

Just ran through and got latest webpack running our stack.

Stack size is ~8mb uncompressed when built out by either.

Using our hot loader that just prevents going up the tree much I ran webpack and then pundle through the same tests, timing each and running for each stack 5 times.

Results were webpack at just over 8s average hmr, and pundle at just over 1.5s.

Here's pundle:
https://v.usetapes.com/UAeLcZFG7g

It's so impressive I think a simple side-by-side video would go viral if you wanted to get some attention here.

Another idea would be just putting timing comparison numbers on the readme.

[TheLarkInn]

Rather than publish just the timings, publish why the disparity between them. This is where I'm most interested 😁

[shellscape]

@natew I'd be curious to see the results using latest versions of each

[steelbrain]

I haven't dug through the source of Webpack to know too much but I've posted my initial thoughts here https://steelbrain.me/2018/07/09/how-hmr-in-pundle-works.html#compiling-and-applying-changes

[shellscape]

@steelbrain thanks for putting that up. as a former maintainer of webpack-dev-server and current maintainer (and author) of webpack-server, I can say with confidence that there are a few inaccuracies and benefits left out of that write-up. If (and only if 😃 ) you're interested in those, I'd be happy to share them.

[steelbrain]

@shellscape Please do share, lmk if i can explain anything on my part.

Also i should've mentioned in the post that i don't have a lot of experience in webpack and the content is based on very quick digging so apologies for inaccuracies

[shellscape]

hey absolutely no worries, and don't feel compelled to update anything. I wanted to offer to share purely for information purposes for you and pundle.

Both Webpack and Parcel use WebSockets

Without getting too nutty on the details:

webpack-dev-server uses faux sockets and by way of SockJS, which uses polling to keep a "socket" open with the server. You're right in your assessment that it's difficult to maintain and causes issues.

webpack-serve uses native WebSocket, which doesn't require polling - but does succumb to the other issues you listed about a separate server instances, and the issues around HTTPS (which I've had to do battle with. everything is smooth like butter until HTTPS comes into play)

Webpack uses a poll mechanism to determine if files have changed on the server side

So, true for the old and busted original dev server, false for the new dev server 😄

The "extra moving parts" is more or less accurate, though most of that is automated/defaulted out of the way of the users, unless they need to get nuts and set things up differently than the default.

As HMR is part of the development workflow, you don’t have to worry about supporting fetch streaming in older browsers as long as your own is up to date.

That's basically the attitude I took with an ill-fated "next" version of webpack-dev-server. What we found out is that there are a metric poopton of users in China and India on "modern" regional browsers that barely support any "modern" features. And apparently the vast majority of Vue.js users fall into that category. That was the reason that webpack-serve was born - a "sorry if your browser sucks" dev server that didn't need to cater to the old and busted browsers. It's not something you're likely to run into because pundle doesn't have a history of supporting, but it's good to know.

Pundle also only regenerates a full bundle (ie joining all the transformed files together) only when it receives the next non-HMR request

This is somewhat true for webpack-dev-server, but not for webpack-serve. I chose to abstract this part (the client) out of webpack-serve into webpack-hot-client. In hot-client, when a non-HMR-registered (and that's another detriment I'll mention) script or portion of the bundle is changed, webpack will rebuild and will notify the client that something has changed in the bundle which isn't HMR. At that point, based on options, the user can refresh the page manually or have it done automatically.

Which brings me to HMR-registration. Webpack requires that users use module.hot.accept() in a top-level entry, or in every separate module that a user wants HMR for. This has proved time-over-time a tough concept for users to grasp, and I see a lot of issues come through with folks not seeing that need, or not understanding it.

Going to back to WebSockets for a quick minute - they do offer one huge (in my opinion anyhow haha) advantage over middleware: anyone can listen in on what's taking place between the server and client, outside of the request pipeline. That results in a large amount of freedom for users and folks are able to build things like https://github.com/G-Rath/webpack-serve-overlay and https://www.npmjs.com/package/webpack-serve-waitpage, which need no direct support by the server app. I'm not familiar with fetch streaming (yet! definitely going to read up on it) so something similar might be possible using middleware and the right entries, but that's a big one I wanted to share.

--

I'll be following pundle and I'm keen to see what other good bits you come up with.

[steelbrain]

The progress wait one looks neat! Pundle also tries to recreate the HMR client API, It supports module.hot.* APIs a mostly webpack-compatible way. Unsure about how webpack handles it but Pundle when in watcher mode waits for things to "calm down", aka when all changed files are processed and no new files are being changed, it then sends that list to dev server that generates those files and sends to all HMR clients regardless of what they are subscribed to.

In case they are not, they have to deal with one or two unnecessarily generated files, In case they are, it reduces the latency and back and forth communication and gets right to the point.

For the fetch streaming, this is the relevant client part and relevant server part. For the http server and http client, it feels like just another HTTP request but you can stream one way data indefinitely, and it's fast just like WebSockets as there's no polling involved

Webpack is an awesome piece of software, would be great to have it evolve further and use the latest tech available