Docz: Replace webpack-dev-server

[PlayMa256]

Hello!
So i'm the co-author of webpack-plugin-serve which was created with the idea to be more simple dev-server as possible, including speed (including increase in HMR speed), install size, stability and few other fancy features like error overlays, progress overlays, etc, and it is also built on top of Koa, the same server that webpack-serve was using, which is extremely fast in comparison to express.

Before releasing this we did some have testing on huge codebases and monorepos and the increase in performance was significantly, which i think will be such a really good improvement for docz.

But this comes with a caveat. Webpack had several improvements when changed to node 10 due to some improvements on v8 compared to node 8 or 9. We also choose node 10 on the improvements that node had brought to the way that websockets are handled (increase in performance), and, of course, for being LTS now.

I understand that moving the support from node 8 to node 10 can be extremely hard for a huge userbase as docz has, but i would like to propose and recieve feedback from the community on how this would be accepted and how the transition could be done.

Also, what do you guys think about following the lts lifecycle and keeping docz evergreen? (latest lts)

Thank you all!

[pedronauck]

I really want to get some feedback about this 🙏
@Jared-Dev @nicholasess @mpivaa @jaburcodes @kentcdodds @renatorib @sibelius @transitive-bullshit

[sibelius]

You can play with it here https://github.com/entria/entria-fullstack/pull/25

WPS is closer to what webpack-serve was, but it is better

you can extend it adding more koa middlewares if you need

[transitive-bullshit]

WPS definitely includes a lot of great ideas and work 💯With that being said, I think we'd want to see some concrete before & after performance comparisons to seriously consider switching.

As a maintainer of a separate Node.js CLI library (create-react-library), I can say first-hand that bumping the minimum Node.js version to v10 will lead to a lot of complaints and new issues being created by devs who aren't even aware of which Node.js version they're currently using.

The other disadvantage of switching away from webpack-dev-server is that it's a very mature library maintained by the core Webpack team itself, which developers making use of Docz are likely already familiar with.

Before releasing this we did some have testing on huge codebases and monorepos and the increase in performance was significantly, which i think will be such a really good improvement for docz.

@PlayMa256 would you mind sharing the results of this testing formally, including a description of how the tests were done?

Just to be clear, I'm not saying we should or shouldn't make this switch. I just want to make sure everyone's aware of the tradeoffs and that we quantify the perf side of things so the potential perf advantages are more concrete.

Thanks!

[PlayMa256]

Of couse, i'll find a "concrete" and reliable way to measure these tests since they are most visible on the interface interaction (everything else in terms of perf is webpack related, so it is useless).

Also if you have any advices (tools, etc.) on how to benchmark it, i would appreciate @transitive-bullshit

[pedronauck]

Good points @transitive-bullshit, I have this concern about the issues that will be created, is something that I'm sure that will gonna happen. I saw the issues and in the almost cases that people write your node version on it, the version is 8 ou 9, it's very uncommon to see people using Node 10, since it's very new.

This can be a huge problem and how I told to @PlayMa256, another point about force Node 10 is that CI tools take some time until put updated versions of Node on your system and this can make build impossible for people using this kinda of tools.

[kentcdodds]

If it's decided to go this direction, what if docz used both for a while? So users using node 10 could benefit from all the improvements, but people stuck on Node 8 (or even 6) could still get updates from docz.

I think it'd be great to keep supporting at least Node 8 for another 6 months or year.

[pedronauck]

That's the ideal, but I need to think about how to implement this type of feature since they implies in a lot of changes in the actual structure.

We need to remove the webpack-serve logic from docz because it runs the devserver by itself and let this behavior for the new plugin. So, to keep both, we need to have some server (webpack-dev-server maybe) compiling and running Webpack with all features/config that we need (HMR support, better logs, etc) and for people that have node 10+ just the plugin with some kinda a runner for Webpack (a simple server maybe).

[Jared-Dev]

I think this could be a good option if it didn't require work on our part. While I like the idea of supporting node v8... I'd personally be okay with incrementing the major version and documenting the cutoff.

If this is something we would need to spend time on...I'd rather we spent time on generating a fully static site first. If this particular change makes that a bit easier that could change my views!

[kentcdodds]

I'd rather we spent time on generating a fully static site first

As a user I would also really love that :)

[shellscape]

@transitive-bullshit The other disadvantage of switching away from webpack-dev-server is that it's a very mature library maintained by the core Webpack team itself

[Former maintainer of webpack-dev-server] webpack-dev-server is neither mature, nor is it stable. I don't mean to rag on or disparage the project, but there's no just nice way to say it. It's got a litany of open issues that date back years which cause users daily headaches and it is _barely_ maintained. This is all because the project structure is fairly brittle and it's hard to keep working correctly, given some questionable architectural decisions made in it, and the webpack community's widely varied use cases. The project is, for lack of a better euphemism, held together with bandaids and dental floss. It just happens to be the historical first option, and the one most widely published about.

While I like the idea of supporting node v8

We just this week identified and tested a very small workaround for Node 8 support: https://github.com/shellscape/webpack-plugin-serve/issues/34. Consumers are free to use that and it should work as expected (though will remain unsupported)

@PlayMa256 would you mind sharing the results of this testing formally, including a description of how the tests were done?

I believe Matheus has some performance numbers now that he can share :smile:

[kentcdodds]

What if ya'll installed node@10 on-demand? It's distributed on npm :) I _think_ npm 5 is required, but that's a reasonable requirement I think. Then you could install it if they're using an older version and run docz with node 10 :)

[shellscape]

@kentcdodds haha I can already hear the cries of doom from the package-size-watcher crowd.

[kentcdodds]

Just tried and installing node@10 by itself and node_modules 87440 bytes, so it's sizeable... But I just tried installing docz by itself and node_modules is 341632 bytes...... soooo.... I mean....

And you'd only do it for people who don't already have node 10 installed. Definitely better than dropping support for old versions altogether.

I suppose another solution is to drop support and tell people to install node 10 themselves.

[pedronauck]

Yeah, I'm really thinking about drop support as we did with Babel 6 and talk to people move on. But this can be a pretty tuff decision to make now because I'm thinking either in launch Docz v1.0 refactored with hooks when it's stable. So, when we launch a major version of Docz dropping support to older versions of React in benefit of the new APIs can be a good time to drop support for older versions of Node too, will be such a great performance improvement even on server and client :)

[kentcdodds]

I'd be in favor of Docz 1.0 forcing an upgrade to React 16.7.0 and Node 10 with docs explaining that people can install node 10 via npm if they want the latest version.

[kentcdodds]

Especially considering that Docz is a dev dependency, that wont be a big issue even for companies that are running node in production and haven't yet been able to upgrade I think.

[PlayMa256]

1.0 + node 10 is a good upgrade. +1 on that too.

I already have numbers for the benchmarks and they are sort of impressive. To not sound biased I'm preparing a folder with everything I used so people can reproduce too. I'll be posting that later.

[pedronauck]

For sure @kentcdodds, another great thing that we can do using Node 10 is workers. Today we have some heavy processes using the main thread. With workers, we can remove these process from the main thread and even from loaders. Concurrent Mode can bring a lot of performance improvements for us too. I very excited about put all these news techs together!

[PlayMa256]

@transitive-bullshit https://github.com/shellscape/webpack-plugin-serve/tree/feat/benchmark/benchmark

This is a benchmark folder that i created to be able to test the 3 most "important" development servers available right now. Initially it requires a manual run to see the results from speed-measure-webpack-plugin, but i'll work on an automated way to have 1 command generating a readable output. As we can see the improvements were good even on a small test like that, it can scale better on projects with a big amount of modules.

HMR can be measure too, but i'm struggling to find a way to measure it from external tools, other than looking at it.

I'm happy to help during the transition and with whatever is needed to improve the performance of docz!

[transitive-bullshit]

Thanks for following up @PlayMa256.

I've extended your benchmark here to be a little more realistic by using babel-loader and including 10 ES6 files for basic transpilation.

AFAICT while WPS is always faster, it's speed gains are constant ~200-300ms which is a negligible drop in the bucket once you start transpiling source files compared with the overall GOT (general output time).

If this perf gain is indeed constant and doesn't scale with the number of source files, then imho it's disadvantages greatly outweigh the perf gain and we should not take any action at this time.

If there are aspects to WPS that I'm not seeing that allow HMR to have perf gains which scale on the order of the number of files, then that's where I would recommend focusing your benchmarks.

[transitive-bullshit]

To clarify: I fully agree that WPS is better and that in the long-term docz and other projects should switch to it eventually. I just don't believe in the short-term that a constant 200ms speedup outweighs the disadvantage of requiring people to upgrade Node.js to latest and all the issues it will cause for people in less greenfield-friendly environments.

[shellscape]

disadvantage of requiring people to upgrade Node.js

That's more of a per-project subjective opinion, but I understand the position. FWIW you're looking at January 2020 before you can make the jump.

Without quoting each one in this reply, I toss my agreement behind the other replies in favor of Node 10 for development environments, and I think they're more compelling than fear of backlash. 🙇

[PlayMa256]

If there are aspects to WPS that I'm not seeing that allow HMR to have perf gains which scale on the order of the number of files, then that's where I would recommend focusing your benchmarks.

HMR won't change much given that most of the bottleneck happens on webpack and since we are tied to it, there isn't much (yet) to improve (it has to come from the core). Only improvement can be done on how fast the servers communicate the change to the browser (something that is not easy to measure since you would need to track when it is triggered on the server and also when it stops refreshing on the browser). Only way to "benchmark" this is on a real scenario comparison, manually swapping one to another one.

sibelius can talk more about it, he had a monorepo project where he was suffering a lot with HMR using wds and react-hot-reload, he had tweeted long time ago asking for help on this (including from the webpack team) and no one was able to make his life easier apparently.

Thanks for adding more modules to the benchmark, i had updated it! The update with react hooks + node 10 is totally worth in terms of performance overall!

[pedronauck]

Thanks to all tips guys, I tried extensively to use webpack-plugin-serve inside docz, but I had a lot of troubles that I couldn't resolve easily and I would have to modify so many things in the default architecture. So, how I don't have so much time to invest on this I was to the easiest way and implement the new devserver using webpack-dev-server.

Launched on v0.13.0 ✅