You do you, but no ECMA6 stuff? I don't use a lot of ECMA6 either because JS is at ECMA14 and continues to change. I can't imagine reinplementing stuff on every project you work on, though perhaps your work is very different to mine. That said, treeshaking has really brought down the cost of imports and there are few occasions where using a custom solution over a reliable third party library is a good option. Curious to hear your thoughts.

[–] TootSweet@lemmy.world 0 points 1 year ago (1 children)

Treeshaking imports (which, admittedly, I just learned about from some googling) assume that the JS you're importing comes from another file (that the browser would have to fetch separately), yes? I believe that's not a restriction of RequireJS (which I have experience with through my work but wouldn't use on any personal projects.)

I'm just thinking performance-wise you'd get better performance by putting all of your JS in one (or a very few) files to be fetched from the server via one (or very few) requests. I am perhaps more of a stickler for shaving a millisecond here and there. (Which is part of why I wouldn't use large JS lubraries. I wouldn't want to make the browser have to load them.)

[–] jpeps@lemmy.world 1 points 1 year ago

It's very typical to import code from other files, but it's also typical to have a minification step that essentially performs what you're saying, compressing the files down into something more optimal. In fact more advanced solutions essentially stream the minium amount to users as needed, and compute as much as possible in the server side.

To be honest, I'd bet a lot than by not utilising larger libraries and their standardised functions, your code has a good chance of running slower. Besides, for the typical computer and network capabilities today, there's a lot of wiggling room.

That said, for absolute tip top of performance (where experience is a trade off) you can find fun things like this, where groups do have to push for the upmost performance.