> 1. How do you handle npm dependencies that don't expose ES modules?
See my comment above.
> 2. How do you handle the performance impact of your browser doing multiple sequantial requests because it doesn't know your whole dependecy tree?
Put all your dependencies in the HTML file, so it fetches them all in parallel. So instead of just loading the root application file and forcing the browser to resolve dependencies:
You can see a demonstration of this technique on my production site, a complex JavaScript SPA that loads everything (including dynamic content) in less than one second: http://vnav.io
For a small performance boost, you can load smaller files first via <link rel=preload>.
> Put all your dependencies in the HTML file, so it fetches them all in parallel.
> ...
> You can see a demonstration of this technique on my production site, a complex JavaScript SPA that loads everything (including dynamic content) in less than one second
But it doesn't work like this in practice! There is a limit to the number of concurrent connections a browser will make, Chrome for example is <=10 IIRC. You can see this in the waterfall:
`rendering.js`, the last `.js` in the queue, stalled for 300ms.
Additionally, each round trip is dependent on:
- The user's latency
- Your server's response time
So with each connection there is overhead. You would be much better served concatenating these files.
`util.js` took 510ms, of which 288ms was spent stalled (i.e. waiting for a connection) after which spent 220ms waiting (time-to-first-byte).
Furthermore, Lighthouse gives your page a performance score of 60, which isn't great. Key metrics:
- 1.7 seconds to paint (which is okay)
- 7.7 seconds to interactive (which is terrible)
Finally, why on earth are you redirecting to HTTP after serving an HTTPS response? This makes your page load even slower:
> But it doesn't work like this in practice! There is a limit to the number of concurrent connections a browser will make, Chrome for example is <=10 IIRC. You can see this in the waterfall:
In HTTP/2, which our site will switch to soon, the concurrent limit is 100. The world's changed, change with it, and throw away those bundlers.
Mixed Content: HTTPS sites cannot connect to HTTP resources. The game needs to dynamically scale without expensive load balancers in front. Until I get dynamic DNS and HTTPS working, the site will not have HTTPS.
So your solution to build systems has absolutely none of the benefits that build system do in fact bring, or the ecosystem of a language that you might consider terrible but actually has a decent amount of quality re-useable code. But this works for your very specific use-case?
See my comment above.
> 2. How do you handle the performance impact of your browser doing multiple sequantial requests because it doesn't know your whole dependecy tree?
Put all your dependencies in the HTML file, so it fetches them all in parallel. So instead of just loading the root application file and forcing the browser to resolve dependencies:
Load the dependencies like this: You can see a demonstration of this technique on my production site, a complex JavaScript SPA that loads everything (including dynamic content) in less than one second: http://vnav.ioFor a small performance boost, you can load smaller files first via <link rel=preload>.