undefined | Better HN

0 pointsdbb017y ago0 comments

In my experience SPAs are actually much more prone to bloat and the resultant performance issues. If you have thousands of components you definitely need to dive into all the complexity of code splitting and server side rendering to make your app fast. You can very quickly find that you have a 4MB JS download.

Of course each application has different needs, but for large multi-developer UIs, I think a better option is to split your front end into distinct server based pages where you leverage React/GraphQL/SPA/PWA features for great DX within those pages. That way you can keep it fast and potentially limit some of the complexity.

0 comments

tracker17y ago

I'm on a moderately complex UI right now, that has a JS payload around 364kb gzipped, react-dom, chart.js and material-ui/core bits accounting for most of the heavy bits. I've also been heavy handed with pulling out libraries that could be done easy enough with just React and JS. Svg is suprisingly easy in React, and a couple events while tricky aren't as bad as some other tooling I've used in the past.

Overall it loads in right around 1s, as I mentioned the splitting for async load on demand doesn't work at the moment, which I had the initial load for a page not using chart.js down to around 115kb gzipped. Part of that also includes the embedded SVG icons as well as the JSS for styling.

It's not paying attention when lodash + underscore, + rambda + momentjs, etc. all get loaded via dependencies... most of that can expressly be avoided with specific smaller frameworks and tooling.

https://i.imgur.com/gf5cpNd.png

j / k navigate · click thread line to collapse

0 pointsdbb017y ago0 comments

0 comments

tracker17y ago

It's not paying attention when lodash + underscore, + rambda + momentjs, etc. all get loaded via dependencies... most of that can expressly be avoided with specific smaller frameworks and tooling.

https://i.imgur.com/gf5cpNd.png

j / k navigate · click thread line to collapse