Comment by jeffhuys
3 days ago
I get what you're trying to say, but aren't you blowing it a little out of proportion? At my job we have an SPA that loads a dashboard with 20+ widgets, all doing their own requests, transferring 2+ MB (compressed) of JS. It loads in two seconds, with all caches disabled. And I mean full load, not "ready for interaction". It runs on Vue 3.
I agree that the web could be lighter, but "finding one that will do a first load under 10s is close to impossible" sounds like exaggeration - it might not be due to the framework or lack thereof.
Btw, the webapp I'm describing is NOT built by the best of the best.
Now test it again on a 5 year old mobile device on a 3g connection with some packet loss, not in the sterile environment that is your office with a last-gen i7 processor.
Well, the post I replied to said "on a 10G connection peered within 5ms of the host" so I think it's fair to assume they also were in a sterile environment. I'm even on a lower connection with 20ms+ ping!
The thing is, enterprise web applications are not built for phones. This would be like telling someone to run the latest Ubisoft game on a PC from 2-3 generations ago, and expecting it to perform well.
Today's applications are more complex than ever, bloated perhaps, but the demand for features, complex visualizations, etc. rise with the patterns of seeing them more in other applications.
This. So many people—both on the dev side and the annoyed HN commenter side—act as though all websites have the same requirements. They don't. The usage profile varies enormously, and if you treat every website as just a website without considering the context it's used in you're going to either waste a lot of time optimizing things that don't matter or you're going to make your app suck by not adjusting properly for your users.
5 year old mobile isn't as slow as you make it out to be. Cheap 2025 phones is significantly slower than my 8 years old iPad. Also 3G could be fast and it isn't the protocol that makes the speed to <1Mbps.
Could be a desktop PC with 25/3 ADSL where somebody is streaming Netflix and a game console is updating itself.
I know I'm weird because I grew up in the 90s, but 2 MB of JS to show a dashboard with widgets still doesn't quite compute in my brain.
It's not just 2 MB of JS. I'm describing ALL traffic, also the JSONs received, CSS, images, everything.
Besides, we show many charts, and believe me when I say: financial people are PICKY when it comes to chart functionality. It needs to have EVERYTHING or you're not considered serious.
It sounds like you're developing a turn-key highly interactive application for a very particular niche of users. It makes sense that for them the tradeoff of downloading 2MB of Javascript makes sense versus enjoying their bells and whistles.
But for the rest of the internet, where users sometimes view your page with decrepit browsers riding on hobbled connections, 2MB is too much. Worrying about these people is not blowing it out of proportion. It's basic human decency.
4 replies →
Heh, I just literally built a toy dashboard in dioxus that loads just about 2MB of code, and then 700KB of css (tailwind, not optimized) and 1.5MB of payload data to visualize. Then again the 2MB includes ~1.7MB of just static data that I included in the wasm build for convenience since it will always be needed. :D
(this was a learning project in my free time, no I'm not defending this in any way, although I'm actually quite happy with the solution of including static data in my binary)
It's interesting. I believe many of the people here know how it goes. There's no possibility of shrinking this further. It will only expand; we just have too much going on. We do have a genuine use for SPA, though - our webapp IS as complex a web-app can get, we offer no mobile version (for that, get the app).
Transfer's only part of the story (and 2MB is a ton on anything but a great connection)—the rest is memory use, which will tend to be some multiple of the transfer size, plus whatever your code initializes, and processor cycles.