3 ms·
I think you and the parent commenter are coming at this from fundamentally different perspectives. The parent commenter remembers a time when websites were ser
by 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 agoThis 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.
- csande17 7y ago> 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 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. > 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. I guarantee that it is possible to write any of these features in traditional HTML, CSS, and JavaScript without relying on today's frameworks or build infrastructure. I know this because even the most advanced build pipeline in the world must eventually compile down to traditional HTML, CSS, and JavaScript; that's all browsers run, no matter how many layers you add to try to abstract yourself away from it. I also know this because websites existed that had these features prior to React becoming popular. > We've been dealing with slow clunky JS components forever now That's the thing -- there was a time before slow, clunky JS components. (They used to be slow, clunky Flash components :P)