3 ms·

Having the browser make one request per npm bundle sounds awful. It’s great if client has fast internet and server is close by, or mostly localhost, but latency

by nojvek 6y ago

Having the browser make one request per npm bundle sounds awful. It’s great if client has fast internet and server is close by, or mostly localhost, but latency will play a far bigger role than the 50ms startup time. That’s not a good metric to look at. The metric that corresponds to user experience is cold compile + page reload time, incremental compile + page reload time i.e. How long before I press enter on a command and I see something usable in a browser to devloop on. If you let the browser load the first file, parse and figure out the next file to load, a large project could have 100s of roundtrips. That’s why JS bundlers were created in first place. To avoid the cost of a long critical chain. Using a device from Africa (Uganda) to connect to US servers, one feels how bad an experience latency can make. More and more development is done on cloud machines or remote host, so this isn’t a rare usecase. What I do hope for is if there is a new bundler, it can use the webpack plugin ecosystem. It’s massive and anything new has to foster a similar ecosystem of tooling. Or please just make webpack fast with incremental disk compiles. I would pay money for that.

WorldMaker 6y ago
HTTP/2 and HTTP/3 both go long ways to mitigating the costs of multiple requests over single large bundled requests. It's still early days in HTTP/2 and HTTP/3 adoption, of course, but we're almost to the point where HTTP itself takes care of many of the reasons bundling used to be needed. (Especially as you get into more advanced features like Server Push.) Also, several of the restrictions baked into the ESM module format are specifically designed so that browsers don't need the full file to load, and can use an optimized import parser that doesn't need to wait for the full JS parser run to find the next modules to load. (I've seen benchmarks where modern browsers have discovered/loaded the entire module graph before the HTML parser has even finished building the DOM and signaled DOM Ready.) That said, reading the site, Snowpack's focus on one ESM per npm bundle is primarily just for the dev experience where you are on localhost and latency isn't an issue. It takes several approaches to further bundling for Production intended builds, including directly supporting webpack as an option (and thus webpack's plugin ecosystem).

by nojvek 6y ago

WorldMaker 6y ago

HTTP/2 and HTTP/3 both go long ways to mitigating the costs of multiple requests over single large bundled requests. It's still early days in HTTP/2 and HTTP/3 adoption, of course, but we're almost to the point where HTTP itself takes care of many of the reasons bundling used to be needed. (Especially as you get into more advanced features like Server Push.) Also, several of the restrictions baked into the ESM module format are specifically designed so that browsers don't need the full file to load, and can use an optimized import parser that doesn't need to wait for the full JS parser run to find the next modules to load. (I've seen benchmarks where modern browsers have discovered/loaded the entire module graph before the HTML parser has even finished building the DOM and signaled DOM Ready.) That said, reading the site, Snowpack's focus on one ESM per npm bundle is primarily just for the dev experience where you are on localhost and latency isn't an issue. It takes several approaches to further bundling for Production intended builds, including directly supporting webpack as an option (and thus webpack's plugin ecosystem).