The Web I Want (2018)
quii.dev
quii.dev
I do simply throttle my entire CPU when I'm on a virtual dekstop / workspace where there's a "surf the Web" browser opened (as opposed to, say, a workspace where I have a browser I use to test stuff in dev).
It's all automated from my window manager: everytime I switch workspace the maximum CPU speed allowed is modified. I go to workspace 3, where my editor/IDE is, the CPU governor is set to "ondemand" (i.e. the CPU can boost to 5.5 Ghz if it wants to). I go to other workspaces: the CPU governor is set to "powersave".
It's brutally efficient. No more noisy fans because this and that websites are busy executing oh-so-important JavaScript code to track me.
I don't bother modifying the max TDP of the GPU when I switch workspaces but I could (the reason I don't bother is that I'm using fanless GPUs in my two main machines).
It just works.
In the past I used to put CPU and RAM quota on processes/group running browsers but I find it much easier to just modify the CPU's power settings upon switching workspaces.
It's trivial to do and there's really not much websites can do about it. They can basically suck it.
But there are also plenty of times when I don't want the minimalistic approach the author argues for. Not everything on the web needs to be the equivalent of a printed black and white pamphlet. Modern web offers so much potential for unique interactive experiences, storytelling, media sharing, etc that isn't available in print or other content mediums.
Often I want to watch high res videos, or see detailed photos that I can zoom in on and appreciate the details. I want interactive JS experiences like the wonderful ciechanow.ski explanation tools. I want dynamic pages like a tip calculator or the daily wordle or a Photoshop like webapp, that I can save and use entirely offline. Sometimes I want a heavy gif filled homage to GeoCities, or a hypertext comic that blends in micro games and animations as part of the storytelling. I might want to check out a cutting edge 3d experience that only works with a special Chrome beta flag turned on. Sure, a subset of users on old hardware might not be able to enjoy it the same, but at the same time we have more computing power and faster connetions than we've ever had before, and to not use any of it would be a waste. The web I want is full of unique and different experiences, even if they're "suboptimal" in some way.
There may be times when a SPA is heavy or unnecessary, but there are also plenty of times when it makes almost no noticeable difference to me if there's a couple extra megabytes on a blog page. If their vision or workflow is built around client-side heavy React rather than HTMX that's fine, that's what they were comfortable working with, and they were still inspired to make the site and share it with me often for free (and of course there would be tradeoffs to any other approach, like more round-trips to the server for minor interactions, or not being able to do fun page transitions, or whatever else).
- Eric Hoffer, The Temper of Our Time
A friend gave me this quote a while back, and I find myself thinking about it constantly with regards to the state of tech. The web this author wants sounds great, but probably won’t exist because major economic forces drive the exact pressures that cause these problems.
There's the obvious stuff, like simply blocking third party tracking JS.
There's some small quality of life bits -- a non-trivial number of websites load JS to make prettier UI elements (like a nicer date picker) because the defaults are so ugly (on desktop at least -- mobile tends to be better). If browsers shippednicer default UI elements, folks would be be less inclined to write their own using JS.
And then there's larger fundamental changes to the API themselves. If HTML6 included virtual DOMs or reactive primitives, that might reduce the inclination towards framework bloat.
Doubtful this will ever be a mainstream default. If by some miracle it did then I imagine CNAME cloaking or proxying via first party would immediately take hold. Not necessarily bad but certainly very disruptive to the status quo.
It's also not clear how browsers could do it. Do you prevent all network calls from scripts loaded from a 3P host? Do you similarly lock 1P scripts to only making network calls to 1P hosts?
Please no virtual DOM. A virtual Dom is pure overhead compared to how svelte or solid renders.
But I’d be very curious about what proper browser integration would look like for reactive frameworks if you have an instinct for what better apis could look like?
It would not be as efficient as Svelte and Solid since those can use the compiler to further optimize code, but having the framework-less version of JS be "as good as" a framework like Vue or React would be a big plus for moving away from frameworks generally.
Apart from that, the general problem of reactivity boils down to "map this DOM element to this variable, and if the variable changes, update the DOM element". You could imagine an API sort of like this:
<span bind-var="variableName" bind-gen="functionName">
Default Value
</span>
Yeah, I know what you mean. And I agree that something like that could be faster than react if it were written in C++. But if we're going to bake something into the browser, I'd like it to be something good. The "Regenerate big chunks of HTML then do expensive tree-diffing operations" approach is, as you say, always going to be less efficient than how Svelte or Solid render. I'd much rather skip DOM diffing entirely and go straight to that.
> Where `bind-var` specifies a variable that, if updated, signals that the span should be replaced with the return value of the function specified by `bind-gen`
Nice - thanks for the example. I suppose the trick is implementing this in such a way that it doesn't depend on "watching" a variable in javascript. (Well, or we'd need to also add that as a feature to javascript - which would be a bit wild.)
Most commercial websites want analytics on how users browse and click on the website. So this point goes out the window.
I don’t dispute the thesis of “web pages today are often way too bloated”, but I think it’s important to be realistic about the problem space. The author calls out JavaScript driven carousels as an example of unnecessary bloat… yet the Amazon.com home page features one such carousel prominently. I doubt they would put it there without A/B testing the heck out of it. To be fair, Amazon is way smarter about it than most in how the page paints and is interactive very quickly, but my point is that it seems to me that most web users want something more than what JavaScript-less HTML and CSS can provide.
edit: looks like I'm not the only one, there's a collection of <adjective>motherfuckingwebsite URLs floating around: https://github.com/lyoshenka/awesome-motherfucking-website
This is basically how programmers use terminals. But somehow we thought that "users" want things differently ...
It is clear the web is turning into trash or is already there, depending on your view. What genuine efforts have been made to rebuild the web without starting on the web/browser? We could just start over and not allow the same things that made the web today turn to to shit.
But the takeaway from these posts seems to be “JavaScript is bad.” This completely misses the point — anyone with, say, a recipe site strewn with ads and newsletter popups is doing so for the money. If people were willing to pay for recipes online, maybe things would be different. But the core economic model of most websites is to use ads to let it be free. You can’t change the UX around these types of sites without changing the economics. (Though some, like Brave, have tried.)
Media companies can and do build minimal feeds (lite.cnn.com), but they’d never allow that to be the default since it doesn’t make any money.
IMO, these conversations need to talk less about the tech (which isn’t super relevant — you can make plain HTML shitty too with enough ads), and more about the economics of the internet.
And if we’re talking about niche hobby and personal sites, people just use whatever tool they want because they’re experimenting and having fun. Being fast and efficient isn’t always the goal for someone playing around in their free time.
Until we start discussing that, we're just going round and round with micro-optimizations while the elephant in the room continues swinging around.
Back in the "good old days" people keep mentioning there were maybe some single digit million people online. Today there are ~5 billion. So by what measure are things clearly worse? And for whom?
As for what measure, things are probably worse from a privacy/tracking stand point and also from a user centralization stand point. At least in my opinion.
What you're describing sounds like Gemini, which has been fairly successful in its own niche. https://gemini.circumlunar.space/
Either way my experience of the web is fast and generally fine and any site that wants me to jump through hoops in ublock to run I don't bother with and I'm happier for it.
Pages can still load CSS, so they can do formatting.
Sure, it's easier for whomever built it, but it's also harder for anyone else. You are using these tools and frameworks to serve yourself, not your customers.
It's like using VB to customize MS office, or the total lock-in you face with SAP customizations. But in those cases it maybe brings some value. With web sites you're really building complexity without improving presentation or adding value.
Not very much. It's not unusual to load a humongous site with tons of libraries to get one or two sentences of information you wanted, usually after the obligatory 3 paragraphs of bullshit AI text.
My guess is that the actual information, in text, that you consume in various forms is extremely small. The ratio keeps getting worse and worse for the consumer.
The JavaScript hate is justified for large websites where you download MBs of javascript. I'm discovering that a lean JavaScript framework and streams are a much better idiom.
If I could go back in time, then I would love to long-lived sockets to be used rather than short-lived request-response.
QUIC is a big step in the right direction as long as middleboxes don't hollow it out.
I recently did another experiment [3] where each static DOM tree becomes a custom element, which also reduces the amount of data that needs to be transferred.
I should probably make a Show HN post soon...
The Web I want - https://news.ycombinator.com/item?id=17816494 - Aug 2018 (2 comments)
Who cares what technology is used to build it. That’s an implementation detail for us builders.
Pragmatism > Idealism
Not as if using an adblocker immediately speeds up your web browsing or anything.
But the web isn't just for documents & exploring content. Or the content is complex & interesting & rightfully semi dynamic.
I really worry & grow concerned when people impose their quasi-religious beliefs about what the web is for. There's absolutely real harm & bad, and much of it comes from the crazy institutional/industrial nature of software development and many of our current tools have degraded the humanness of the web. The harms are real.
But so many people for so many widely different/opposing reasons want us to abandon HTML, and it's so hard for me to imagine what open society is left with if we move all app development back to native stacks. The Towards A Modern Web Stack view is that app makers can just target the web as a dumb delivery target, with WebGPU & webusb HID instead of html & the html events. They are horseshoe views, that almost meet in agreeing that html shouldn't be for X or shouldn't be for Y.
Identifying problems & desire ables are great. But we seem to have a small but very vocal group that decides & loudly advocates for what we can't use the web for. So so many of these concerns seem implementation & company specific. And these ills- so many of them would best be remedied by getting better at html webdev, by finding different paths to app building, ideally that are more We Component based, that make the page more honest & truthful & manipulable & up front. If we just categorically try to make the web unable to have these problems, humanity will be even less well equipped, have less agency to fight the hydra of capitalist dominion where it arises elsewhere.
This is the fundamental misconception that most "get off my lawn" people like the author have, which leads to a variant of this exact post getting voted to the top here every single day.
The web is not about delivering big blobs of text and images. It may have been at one point, but we are far beyond that. Instead:
1. The web is now first and foremost an application delivery platform. The web browser is an OS. The website is an executable program.
2. The web is not a niche hobby for nerds like it was "back in the day", but a $15+ trillion global business.
The sooner you can accept both of these, the more sense everything will make. What you did as an early adopter of the internet 30 years ago is irrelevant. You are not getting that time back. The party is long over, and everything is only going to get more commercial as time goes on.
- Stack Overflow
- Hacker News
- Youtube
- Various news blogs
- Gmail
- Shopping/Amazon
- Maps
With the exception of maps, pretty much all of that would be perfectly fine server side rendered (and a lot is, I think). Even gmail would be fine that way, tbh I find it kind of annoying that things like the back button work in unexpected ways.
Things I don't do often but which would be fine server side even though they're SPAs:
- Taxes. Turbotax is very smooth and fancy, but frankly if it gets my taxes done quickly I just don't care that much.
Stuff that's heavy in JS, but which is pretty far weighted content-wise:
Also, a lot of the things that are essentially "web apps" I end up using the desktop/electron version anyway, like Slack or VSCode.
I really think most sites would be better if JS was kept to the bare minimum. The things that actually act like applications often end up with a desktop electron version anyway.
Hacker News upvote/downvote buttons work without Javascript
I'm not entirely sure that sort of feature requires javascript at all.
JS is fine for dynamic contents (likes, upvotes) but the rest of the page can be completely static...
Do you really need to see likes being updated in realtime? Or infinite scrolling (instead of sane pagination)?
But applications can be small and performant.
It takes skill, time, and work; a hard sell, these days.
Nowadays, we can throw together two or three massive dependencies, and get a really high-tone app.
That waddles like an overfed walrus.
I think the frameworks are mostly so obsessed with the problem of complex applications that they miss having good support for the simple case of server rendering with little-to-no javascript in the browser. If your website looks like a blog, it will work better if the server ships html to the browser. And maybe, only html. Web browsers handle html really well.
Because you can make content websites using hundreds of kilobytes of react, people do because that’s what they learned at their coding bootcamp. React lets you do server side rendering, but it’s seen as some advanced feature, not as the default for how we should be building the web. (In fairness, SSR is quite complex if you also want to re-hydrate in the browser).
Most websites should be using tools which do server rendering by default.
Meaning the server sends html, or the server sends an image?
edit: html, at least with react
HTML is faster to load on all devices, usually smaller over the wire, trivially cacheable at every level. Its easier to debug, easier to archive or backup, and it plays nicely with screen readers, search engines and reader mode. The back button always works and does what the user expects. And it looks web-native everywhere.
I wrote a 9000 word blog post a couple years ago covered in diagrams. The page renders near-instantly on all browsers I've tried, and scrolling is buttery smooth. How did I do that? Its simple. When users open the webpage, I send them an HTML file.
That's the demographic that this "whiny boomer nerd" Serves, and they matter to me. I'm quite aware that many non-whiny-boomer-nerds feel as if these people should not exist, but they do exist, and mass murder is not an option, so some of us whiny boomer nerds actually care enough to try helping them.
Also, it's kinda fun, helping folks that can't make non-whiny-boomer-nerds rich, simply because it upsets non-whiny-boomer-nerds to see these “not worth the trouble” folks experiencing better Quality, Security, and performance, than the non-whiny-boomer-nerds do.
I know that it’s kind of immature, but I've always had a bit of a rebellious streak, and I’m easily amused.
Apart from a couple of really big websites the vast majority of the remaining ones could easily be a static website. course we ended up in dumbed down version of reality where people can't do without Facebook / Instagram so instead of having public information you have to go to a Facebook fan page or Instagram profile...
There's no problem. It's all blog post author imagination. Turn off the ad blocker.
The web advertising industry is on the side of web users. Web users are getting everything they want, and more!
Look https://news.ycombinator.com/item?id=35852516 made the front page 5 days ago and is another blog post saying the same thing. The problem is, without actually surveying a bunch of sites and looking at what they load and why they load it we won't know where the bloat comes from. I'm not convinced that JS is the issue because a simple JSON payload response (sans TCP overhead and connection establishment) is a matter of bytes.