Websites get slower faster than browsers get faster. Interesting thread from Alex Russell on birdsite: https://twitter.com/slightlylate/status/996204502490337280
I think part of the problem is cargo-culting. Around 2006 everybody started doing Ajax because Google was doing it, and GMail and GMaps were amazing. But Google also employed some of the smartest webdevs on the planet, and not every organization had the know-how to get it right.
Today webdevs are busy React-ing All The Things because Facebook does it, without realizing that FB also uses machine learning to optimize their module delivery system, among dozens of other sophisticated techniques.
And yes, I find it frustrating that, as someone who works on a browser performance team, we basically have to work as hard as possible just to stay in the same place. 😜 It's like Alice racing the Red Queen: https://en.wikipedia.org/wiki/Red_Queen%27s_race
Browsers today are way faster than they were 10 years ago, but you'd barely know it because websites just keep adding more JavaScript, more CSS, more images, more video, more bloat, etc. The web is an amazing platform, but it could be *so* much better than it is.
@nolan I've written a web app framework that doesn't use any JS. It's fast. (Do I win anything?)
I probably should put up a demo somewhere, huh...
@woozle Server-rendered websites are still the best choice for a lot of use cases. :)
@kemonine
Wikipedia lists it under "software" as "Jekyll (programming language), a high-level language from Intel that can be losslessly translated to and from C", but doesn't actually have a page for it.
https://en.wikipedia.org/wiki/Jekyll
With some difficulty, I found this: http://jekyllc.sourceforge.net/
@nolan we're still in a bumpy period of piles of JS, but overall I feel like this is moving in an extremely positive direction. I'm just really optimistic that if we keep up the pace (even though things are still a mess now) in a few years we'll have cobbled together a situation where the open web is an order of magnitude better app store than apple's/google's
@kevinflo Yeah, I'm optimistic as well. Frameworks like Next.js make a lot of the right choices, and Webpack is moving in a good direction as well. What we need most urgently is for frameworks to move away from being runtime APIs and instead become optimizing compilers: https://svelte.technology/blog/frameworks-without-the-framework
@nolan Maybe it's time for web-browsers to stop getting faster? It would put some pressure on web developers instead.
@Sylvhem That's a great way to lose users to your competitor ;)
@nolan So we keep the race to the bottom instead :/ ?
@Sylvhem There's probably a point at which web users rebel. I think we're seeing that with adblockers already.
@nolan I hope so 🤞.
@nolan nobody linked to the The Website Obesity Crisis presentation yet? http://idlewords.com/talks/website_obesity.htm
@nolan That, and the FB website and app are actually terrible.
@nolan Other things dev miss when copying FB:
- Facebook users tend to use their native app on the slowest platforms
- Facebook is actually a horrible, confusing experience. 'How the hell do I do X on Facebook?' is a continuing complaint among my still-on-Facebook normie relatives.
- Facebook doesn't care if it consumes so much RAM and bandwidth that you can't really use it and other websites simultaneously.
@baldur Great points. But still, I am legitimately impressed with the expertise of their frontend team. Facebook is the reason we have specs like Service Worker navigation preload, cache-control:immutable, probably tons of other stuff I'm forgetting. In one Working Group meeting they showed how you could build an accurate CPU profiler using Web Workers and SharedArrayBuffer. Astonishing.
@nolan Facebook's web dev team is doing fantastic work. Their design team is world class as well.
But, despite this, the only genuinely good part of their platform is the feed (consuming from and posting to). Everything else is confusing, hard to use, frequently slow, and generally a pain. And there is a _lot_ of 'everything else' on Facebook.
These things, when taken together, should terrify anybody aspiring to copy Facebook's web dev strategies.
@nolan Does the Unix tradition give a light counter-example to this?
"Dennis Ritchie encouraged modularity by telling all and sundry that function calls were really, really cheap in C. Everybody started writing small functions and modularizing. Years later we found out that function calls were still expensive on the PDP-11, and VAX code was often spending 50% of its time in the CALLS instruction. Dennis had lied to us! But it was too late; we were all hooked." http://www.catb.org/esr/writings/taoup/html/modularitychapter.html
@nolan (In the sense that, something good (modularity, React et al.'s approach to webapps) was evangelized despite having high costs.)
@nolan I'll suspect people are Reacting because the code is the first comprehensible javascript they've ever seen...and there's value in that. It's less easy to spaghetti.
@Tremelune Yeah it is a nice programming model too. :)
What's right for Facebook and Google and huge well-funded teams with hundreds of person-years of experience isn't necessarily right for a mom-and-pop web shop, or even a medium-sized web shop. I hate to say "you must be this tall to build a website," but when it comes to stuff like dynamic client-rendered JavaScript-powered web apps, I think it definitely applies. Web frontend is some of the most difficult programming I've done in my 10+ years as a developer.