Message from JavaScript discussions

July 2018

— Kinda does but not to start, that's something you look at before you're ready to ship to prod


Ultimately you should look to avoid cargo culting before considering file size as a problem, cart before horse etc...

— If your file size is substantiated by using every line of code you import, it changes what kind of problem you're dealing with, whereas if you're just picking the smallest lib regardless of tree shaking it's kind of a waste of time

Message permanent page

— Kinda small lib can kinda eat a lot of memory. never know until tested

— Thats a different problem vs raw/compressed filesize

— Like considering what a good agnostic filesize is, 1MB, an 8kb lib isn't going to change the performance of the transfer of that data much

Message permanent page

— People who actually do have this as a problem do dynamic deferred rendering, and have the server autodetect when the rendering should be serverside vs clientside

Message permanent page

— I would replace rendering word to parsing.. all those server sides

— Whatever results in a full render of the page

— Stuff like running React on the server and client at the same time, pre-rendering certain pages if the server detects a slow connection or slow device in general

Message permanent page

— Slow connections can't really be fixed this way easily (very niche to your stack) but slow devices can be, since the CPU locked work gets pushed on the server CPU instead

Message permanent page

— Mithril is nice