4 ms·
Fully agreed. Two aspects that I don't see acknowledged often enough: (1) Not everyone has fast internet. This is particularly the case in rural locations and d
by austinjp 4y ago
Fully agreed. Two aspects that I don't see acknowledged often enough: (1) Not everyone has fast internet. This is particularly the case in rural locations and developing nations. We're witnessing internet inequality and heavy websites are fuelling it. (2) Information transfer requires fuel and burning fuel is destroying our habitat. It might seem trivial to shave kB off download sizes, but the cumulative effect of large sites doing this should be acknowledged and encouraged.
My reaction to this ridiculous situation:
Use Preact instead of React -- I'm planning to switch to Svelte next -- and using minimal dependencies and writing my own minimalist implementations where feasible. I need to get better at this.
Use code-splitting and lazy loading to keep gzipped download under 100k for all content per "page".
Avoid web fonts, images, tracking, 3rd party crap, cookies, advertising, etc etc etc. I'm lucky enough to be in a position where nobody is telling me to put this stuff in.
Tree-shake, minify, compress (brotli if possible). Sure, it takes processing power to decompress at the other end, but my suspicion is overall compression wins. Happy to be proven wrong.
User-test everything on a throttled connection at 3G speeds. Or "poor 3G" or whatever the browser dev tools have. This is subjective, of course, but gives me a good sense of user experience.
It's not a perfect recipe, but downloading megs of crap for a web page is totally unacceptable.
(Obviously all the above side-steps the "no JS" perspective.)
- Existenceblinks 4y agoYep, anything else works, they are mostly sub 10kB view lib. It's fascinating that the current situation is widely acceptable.
- cutler 4y agoSolid.js may change all this.
- eyelidlessness 4y agoSolid is great, and its focus on performance definitely helps. But for now I think a couple of other tools are better positioned here, as they already focus on shipping less JS to the client in the first place. For instance Astro (“islands architecture”/“partial hydration”; it supports Solid islands however!) and Qwik (“resumability”/on demand loading of interactive JS as it’s needed). In a lot of cases, just shipping less JS in the first place is going to perform better for resource constrained usage. Solid is currently more oriented towards fully interactive SPA use cases, but they do have partial hydration (or something like it) on the roadmap.
- seydor 4y ago> This is particularly the case in rural locations and developing nations. Also in a conference / the train / the beach / driving / any crowded place / in space
- FrenchDevRemote 4y ago>(2) Information transfer requires fuel and burning fuel is destroying our habitat. It might seem trivial to shave kB off download sizes, but the cumulative effect of large sites doing this should be acknowledged and encouraged. No. This is cached if the devs aren't incompetent, the lion's share of information transfer is video streaming, not large JS files.
- austinjp 4y agoData still has to get to the cache, get stored, and sent to clients. More data = more energy, cache or no. Your point about video streaming being a far larger amount of data is of course fully valid. But I was replying to a thread about JavaScript.