I loathe the modern web. Speed is a secondary to "hey look what we're doing with our frameworks".
The basic shift back to pre-rendering + delivering only what's needed on the actual page is a big deal which hasn't got enough attention yet IMO. We went completely in the other direction for over a decade because we thought networks and browsers could handle it, but it was too easy to abuse and mobile took over.
There's no reason even very advanced websites can't load quickly, without having to fully compromise back to the 90s non-interactive websites.
News sites and marketing teams still ruin it regardless with all the crap they add on top. But it's far far better than loading a giant blob of 20 jquery libraries plus a big old angular.js or backbonejs app (sometimes both at the same time) encompassing a whole site in one file, even though you just wanted to visit the contact page.
I also blame Themeforest type developers because they're still stuck in the "let's add a hundred JS files so I can parallax and animate two divs" mindset.
Getting rid of unused css helps but the additional markup would make the page 4 or 5 times larger.
The Bootstrap stuff you seem bothered by is better for splashy big-headline marketing sites not high-density content like HN.
A lof of web designers cut their teeth designing marketing websites, not app UIs, so it's not surprising when I see it mindlessly used on sites like Reddit's new redesign.
It's really a sad state of affairs when an industry with such a strong historical connection with publishing is now reasonably cited as an industry worse at publishing than most others.
They regularly fail on basic UX. Their ability to turn a kilobyte of text into 10MB of trash is astounding, as is their ability to cripple modern computer hardware, or simply readability, with their latest 'innovations' in totally unnecessary JS/CSS fuckery.
uMatrix blocking all JS, including first party, helps. But you've still got bullshit like floating headers that follow you when you scroll down the article to contend with. I find myself creating cosmetic filters to remove pointless floating clutter on news websites more than any other sort of site. The industry seems utterly incapable of presenting a clean and readable article online.
But regardless of our personal work-arounds or workflows, those websites shouldn't be like that. The general public is still subjected to the default experience and that bothers me.
I don’t understand how online ads are as big a business as they are, other than the troll stuff on Instagram. The rest is pretty unremarkable and ineffective.
I can probably count on my hands they number of times I intentionally engaged with an ad in the last 25 years.
For one, they're on-line, = cheap to make and pretty much free to serve.
Two, with the amount of tracking done, on-line ads are attractive to advertisers because they can evaluate their effectiveness real-time, and often tell what ads are responsible for what real sales.
Three, with all the accrued complexity, it's a wonderland for third parties who help the advertisers navigate through on-line advertising landscape, and divine attribution. Now the trick is, if your customer (the advertiser) doesn't have even basic competence in statistics (they most likely don't), you can bullshit them with data to your heart's content. Which is what you're probably doing if your team doesn't have much statistical competence either. I've seen this happen.
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.
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.)
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
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.
> 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)
"All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection."
I tend to think “but what about making the web enjoyable for the end user?”
But more importantly, the fact that the page loads 2 seconds longer is a drop in the bucket compared to the insane processes our business people dream up.
I understand where they're coming from having dealt with a few legacy frameworkless spaghetti code bases that have no documentation. Give me bad code to maintain in a known framework over bad code without a framework anyday. Adding features and debugging in those conditions are no fun at all.
https://mobile.twitter.com/codinghorror/status/1049082262854...
Stop blaming the modern web. There are plenty of slow PHP and rails sites and plenty of slow React based sites. Of course speed is second priority, I'd much rather have users using my app with a mediocre experience than nobody using my app. However, as the web supports more tooling and frameworks continue to evolve towards web assembly, I believe will start to have web apps approaching native speed.
The reality is that requiring a server to render every page limits what you can do with your app. Even if modern tooling is overused, developers will always move towards what allows you to do more.
I'd much rather focus on making modern tooling faster than complaining about the modern web.
I always strive to keep the client side stupid. I should be sending as much of the final document as possible from the server and any interactivity needed should also produce as little work for the client as possible.
If the companies hiring web devs changed their mindset and listing a dozen different frameworks on your resume was perceived as the negative trendchasing architecture-astronauts that such developers often turn out to be (at least in my experience), and valued simple JS skills and experience instead, I suspect websites would end up being a lot different than they are today.
In contrast, many sites seem to think that 1MB of JavaScript, or even 5MB, are acceptable, and they can't even show simple static content when client-side JavaScript is disabled. On a slow link, 1MB of JavaScript means that the user has probably given up. And it's not just the size. 200KB of HTML is far far faster than 200KB of JavaScript; web browsers are highly optimized for handling HTML, while processing JavaScript is necessarily much slower. JavaScript is great for some things, but like a sledgehammer it's not always the best solution. Too many people aren't considering the real end-user experience. "Pretty graphics, but it takes 5 minutes to download" is usually not a worthwhile tradeoff.
To paraphrase Goldblum:
Your web designers were so preoccupied with whether or not they could use JavaScript, they didn’t stop to think if they should.