5 ms·
> My company does complex cloud and on-prem web-based apps, JS front and back. Then you've certainly run into power users. Chances are browsers can load and d
by chmod775 5y ago
> My company does complex cloud and on-prem web-based apps, JS front and back.
Then you've certainly run into power users.
Chances are browsers can load and display a 2MB server-generated HTML table faster than the DI system in your 5 MB angular app can start all the required services to be ready to launch your pagination component.
However once it is ready it may be quickly apparent that users would be much more productive using that giant table and CTRL+F than a laggy angular app that would struggle even handling that much data at once in an idiomatic way.
Of course I am making this up to illustrate a point. However I use "one giant HTML table" as a sort of bar to meet when developing in modern frameworks. If with this insanely complicated and large array of tools I can't even do better than that (faster to implement!) competing solution, I might as well not bother.
That "a bunch of large server-rendered HTML tables" just so often happen to be the previous solution that was in place, and power users are likely to complain if we do worse, is just the cherry on top.
To do better we often have to avoid certain things that would be considered modern. Like not putting lots of empty space in our layout, no server-side search that would introduce too much (pointless) latency compared to client-side, and some un-idiomatic stuff to actually handle large[1] amounts of data without change-detection/updating in our framework of choice eating user's CPUs for breakfast.
[1]: The amount of data/elements at which change detection in idiomatic Rust and Angular becomes slow wouldn't have been considered 'large' 15 years ago. Though obviously people then had to put thought into this stuff and it certainly wasn't automatic.
- cerved 5y agoI want all my data in a gigantic HTML table, said no user ever
- fake-name 5y agoHi. I'd love this. I'm a user.
- reboog711 5y ago> in your 5 MB angular app Related anecdote: I just did a production build of the Angular 13 app I'm working on and it was 686K. That includes all the Angular framework, and a component library which includes a data table.
- chmod775 5y agoWell. Good work then! Your build is half the size of twitch.tv's vendor.js. If you go on their front page, then click a stream, your browser will have loaded around 15MB of JS (~3.4MB over the wire). To be fair they're a video streaming service so they probably don't care about a few extra megabytes here and there, but on lower spec'd hardware you'll feel all that JS: a solid 5s of CPU time just spent executing JavaScript on my thinkpad during that test, not including the time to load it. And it's not like they're done. If you then do pretty much anything, it'll have to load even more. Apparently if you click a name in chat, it has to load another 998.96KB JS file (features.chat.components.viewer-card-*.js) to render those tiny cards that contain maybe 50 bytes of information. That's a good bit larger than your entire application! There's operating systems that fit in less than what twitch needs to show a glorified tooltip. On my hardware they could probably boot in that time too.
- PeterWhittaker 5y agoWell, if our apps resembled these large tables of which you speak, maybe…. :-) Our apps are related to compliance and risk management with a good sprinkling of custom developed workflow. Most of the screens users see are fairly light. It isn’t the amount of data that matters to our users, it’s what we do with it. And how quickly we can new things when they realize they need new.