3 ms·

Yeah, but those fixes and workarounds are only almost enough to sometimes compensate for the code bloat that the frameworks themselves have caused.

dmix 7y ago
People seem to be confusing web 2.0/bootstrap style design (see: Reddit's bad redesign) with the frameworks here but the component based approach combined with webpack/compilation steps, which are very much mainstreaming, are fundamentally different than top heavy JS frameworks I spent most of the last decade using. I dont think people have really seen what server-side rendering (ala Next.js/Nuxt.js), decoupled components, modern treeshaking, minification, and chunking can do for performance. We've yet to have a full web framework designed entirely to encompass this from day one but they're coming and getting better at it. Outside of the endless 3rd party crap the 'business' guys add, if anything, it's no longer the JS framework size and library cruft I'm worried about it's how many object watchers I've got at runtime via Vue.js and reactive style programming (which automatically adds Object.observe style watchers to all data) + component initializers (which can add overhead to simple HTML templates). Fortunately with the new Vue 3 function API there is a clear distinction between observed values vs static/immutable/config data. The amount of observers per page dropped dramatically. Otherwise looking at a Vue project in the performance tab shows it's highly async and efficient. The new Vue functional API (allegedly) is also going to be far easier to treeshake so you really only ever get the library features you're using. Even for something like Lodash or Ramda where you might use only 10% of the functions it's a big deal. I'm sure React is making similar progress in this direction and it was already smaller than Vue. CSS Frameworks have some ways to go and PurgeCSS isn't perfect but using a functional CSS framework like Tailwind or Tachyons also helps in this regard, so all of the stuff isn't intertwined and can be stripped out. This type of tooling really does massively improve the state of things automatically, even with poor coding practices or large applications spanning multiple pages. SSR, treeshaking, chunking, stripping unused CSS, etc is a 'zero cost' type optimization that I've seen turn 700-1000kb dev assets into loading 100kb base + a few 5-10kb js/CSS files dependent on the page.
- csande17 7y ago
  I think you and the parent commenter are coming at this from fundamentally different perspectives. The parent commenter remembers a time when websites were server-rendered by default. The server would send down HTML, along with a small amount of CSS and JavaScript to style it and add interactivity. You didn't need an elaborate chain of compilers and bundlers and frameworks and chunkers to make sure you didn't ship several megs of dead code to the client; you just didn't ship several megs of dead code to the client. That's their baseline for web performance. Your comment, on the other hand, seems to use the current giant-JavaScript-framework sites as the baseline for performance. And yeah, you can get a lot of cheap wins if you start from there. (For starters, you can break up your JavaScript execution into tiny slices so that, even if you're using 80% of a CPU core and draining the user's battery for no real reason, you're at least not blocking the browser UI thread.)
  - dmix 7y ago
    This is more than just wrapping stuff in cards and making the font 2x, it's about the abilities of what websites can achieve. The design is a part of that but it's also influenced by what you can do differently than a pure HTML + a bit of jquery site. I basically rebuild past era bootstrap style Rails HTML views with some jquery into modern Vue components for a living on a B2B app. I'm very familiar with the old way and how much better a proper modern replace could be. I can pack a ton of information into smaller flexible places and integrate action-relevant help boxes and only showing the parts of forms as needed. Page render times to first action are about 10x faster on average (no joke) and our users use 1000's of objects on a single HTML form. I'd love to see someone try rendering that pure SSR framework with partials in a performant way and usable way. This type of interaction extends well outside of my business/B3B domain as well. I'm quite excited for the future of web development after a decade of fearing more JS everywhere (which I was contributing too). Another great HN style site is Basketball Reference, I personally love these information dense designs but it's not very scalable with tons of information, elements, and what it could really achieve if it was a desktop application or fully flexibly UI wise. https://www.basketball-reference.com/teams/TOR/2019.html https://www.basketball-reference.com/teams/TOR/2019.html This site could massively improve with real time filtering, multi-select forms, interactive data exports tools, multi-team/page comparisons, information highlights on hover, inline math tools, etc. On the site currently it looks great on the surface but once you engage with any JS-y stuff or imagine what's possible if it was a desktop app, and the previous tools would be extremely limited in scope. You can do this very powerful stuff now without clogging up performance and load times. That's a big deal. We've been dealing with slow clunky JS components forever now and it can be way better.
userbinator 7y ago
Seeing the parent post you're replying to reminds me a lot about how mainstream compiler optimisation works: create a lot of crap "unoptimised" output, then add many additional layers of complexity in an attempt to get rid of the unnecessary crap, instead of the quaint idea of simply not creating so much crap in the first place. "All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection."

dmix 7y ago

People seem to be confusing web 2.0/bootstrap style design (see: Reddit's bad redesign) with the frameworks here but the component based approach combined with webpack/compilation steps, which are very much mainstreaming, are fundamentally different than top heavy JS frameworks I spent most of the last decade using. I dont think people have really seen what server-side rendering (ala Next.js/Nuxt.js), decoupled components, modern treeshaking, minification, and chunking can do for performance. We've yet to have a full web framework designed entirely to encompass this from day one but they're coming and getting better at it. Outside of the endless 3rd party crap the 'business' guys add, if anything, it's no longer the JS framework size and library cruft I'm worried about it's how many object watchers I've got at runtime via Vue.js and reactive style programming (which automatically adds Object.observe style watchers to all data) + component initializers (which can add overhead to simple HTML templates). Fortunately with the new Vue 3 function API there is a clear distinction between observed values vs static/immutable/config data. The amount of observers per page dropped dramatically. Otherwise looking at a Vue project in the performance tab shows it's highly async and efficient. The new Vue functional API (allegedly) is also going to be far easier to treeshake so you really only ever get the library features you're using. Even for something like Lodash or Ramda where you might use only 10% of the functions it's a big deal. I'm sure React is making similar progress in this direction and it was already smaller than Vue. CSS Frameworks have some ways to go and PurgeCSS isn't perfect but using a functional CSS framework like Tailwind or Tachyons also helps in this regard, so all of the stuff isn't intertwined and can be stripped out. This type of tooling really does massively improve the state of things automatically, even with poor coding practices or large applications spanning multiple pages. SSR, treeshaking, chunking, stripping unused CSS, etc is a 'zero cost' type optimization that I've seen turn 700-1000kb dev assets into loading 100kb base + a few 5-10kb js/CSS files dependent on the page.

csande17 7y ago
I think you and the parent commenter are coming at this from fundamentally different perspectives. The parent commenter remembers a time when websites were server-rendered by default. The server would send down HTML, along with a small amount of CSS and JavaScript to style it and add interactivity. You didn't need an elaborate chain of compilers and bundlers and frameworks and chunkers to make sure you didn't ship several megs of dead code to the client; you just didn't ship several megs of dead code to the client. That's their baseline for web performance. Your comment, on the other hand, seems to use the current giant-JavaScript-framework sites as the baseline for performance. And yeah, you can get a lot of cheap wins if you start from there. (For starters, you can break up your JavaScript execution into tiny slices so that, even if you're using 80% of a CPU core and draining the user's battery for no real reason, you're at least not blocking the browser UI thread.)
- dmix 7y ago
  This is more than just wrapping stuff in cards and making the font 2x, it's about the abilities of what websites can achieve. The design is a part of that but it's also influenced by what you can do differently than a pure HTML + a bit of jquery site. I basically rebuild past era bootstrap style Rails HTML views with some jquery into modern Vue components for a living on a B2B app. I'm very familiar with the old way and how much better a proper modern replace could be. I can pack a ton of information into smaller flexible places and integrate action-relevant help boxes and only showing the parts of forms as needed. Page render times to first action are about 10x faster on average (no joke) and our users use 1000's of objects on a single HTML form. I'd love to see someone try rendering that pure SSR framework with partials in a performant way and usable way. This type of interaction extends well outside of my business/B3B domain as well. I'm quite excited for the future of web development after a decade of fearing more JS everywhere (which I was contributing too). Another great HN style site is Basketball Reference, I personally love these information dense designs but it's not very scalable with tons of information, elements, and what it could really achieve if it was a desktop application or fully flexibly UI wise. https://www.basketball-reference.com/teams/TOR/2019.html https://www.basketball-reference.com/teams/TOR/2019.html This site could massively improve with real time filtering, multi-select forms, interactive data exports tools, multi-team/page comparisons, information highlights on hover, inline math tools, etc. On the site currently it looks great on the surface but once you engage with any JS-y stuff or imagine what's possible if it was a desktop app, and the previous tools would be extremely limited in scope. You can do this very powerful stuff now without clogging up performance and load times. That's a big deal. We've been dealing with slow clunky JS components forever now and it can be way better.

userbinator 7y ago

Seeing the parent post you're replying to reminds me a lot about how mainstream compiler optimisation works: create a lot of crap "unoptimised" output, then add many additional layers of complexity in an attempt to get rid of the unnecessary crap, instead of the quaint idea of simply not creating so much crap in the first place. "All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection."