The Web I Want (2018)(quii.dev)
quii.dev
The Web I Want (2018)
https://quii.dev/The_Web_I_Want
69 comments
This should be standard on every OS. What a beautiful use of workspaces.
This is very interesting. Can you elaborate on this a bit more? I'm assuming this is Linux? How could this be achieved? Are there done special scripts or programs?
Just write the desired governor to /sys/devices/system/cpu/cpu${X}/cpufreq/scaling_governor, e.g. powersave, performance etc. Poke about in there to see what governors are available, and do it in a loop to set all cores (you can get the number from /proc/cpuinfo).
That's an interesting idea I might have to try out!
I think this is a fine ideal for some websites but not a universal truth. For example I love the plaintextsports.com website and check it near daily on my phone, and it does a perfect job. And of course I agree that there is a lot of bloat especially around marketing / tracking snippets that slow things down and don't provide the end users with any upside.
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).
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).
Agreed. Sorry for piggybacking off your post, but I'm trying to build a search engine, and one thing I want to surface are interactive websites. Does anyone have suggestions for Javascript features I could extract that might indicate a site is doing something cool/interactive? I'm not a frontend developer--keywords I have now are .wasm, webhooks, WebGL, canvas.
Maybe add WebSockets and WebWorkers?
“Every great cause begins as a movement, becomes a business and eventually degenerates into a racket.”
- 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.
- 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.
At this point, I feel like the party best equipped to reduce JavaScript bloat are the web browsers themselves.
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.
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.
> There's the obvious stuff, like simply blocking third party tracking JS.
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?
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?
> If HTML6 included virtual DOMs or reactive primitives, that might reduce the inclination towards framework bloat.
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?
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?
By virtual DOM, what I mean is telling the browser I would like to replace the innerHTML of an element with another bit of HTML, and the browser should figure out an efficient way to "diff" the update rather than replace all the children wholesale.
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:
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>
> By virtual DOM, what I mean is telling the browser I would like to replace the innerHTML of an element with another bit of HTML, and the browser should figure out an efficient way to "diff" the update rather than replace all the children wholesale.
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.)
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 websites are about delivering and exploring content. HTML is amazing for this, and you don't need JavaScript.
Most commercial websites want analytics on how users browse and click on the website. So this point goes out the window.
Most commercial websites want analytics on how users browse and click on the website. So this point goes out the window.
This is why the web (and computing in general) is the way it is today: everything prioritizes what businesses and developers want, and the desires/needs of the people who actually use it are considered afterthoughts and annoying inconveniences. :-(
Also, I’m not sure that most websites are about delivering and exploring content. I think most websites are fundamentally about either delivering ads or selling you stuff. “Delivering ads” usually requires JavaScript, and “Selling stuff” can be done without a bunch of JavaScript, but the experience wouldn’t be great.
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.
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.
[deleted]
This website says it better:
https://motherfuckingwebsite.com/
https://motherfuckingwebsite.com/
I agree with this in principle and my own personal site is basically "just" a website, but the lack of _any_ styling to make things look just a little nicer always turned me off to this rant in particular. I am not good with CSS, but there's plenty of essentially drop-in CSS files out there that would take a text heavy barebones site like this from "basically a text file open in notepad" readability to something a normal person would actually want to read. It's so easy that there's really no excuse not to grab one and drop it in.
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
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
You could take the original motherfuckingwebsite's approach and allow the user to set a default CSS in their browser.
This is basically how programmers use terminals. But somehow we thought that "users" want things differently ...
This is basically how programmers use terminals. But somehow we thought that "users" want things differently ...
Given the subject, it seems ironic that the page is loading htmx.min.js (40kB/15kB transferred). Can anyone tell if it's doing anything whatsoever on this page? I suspect it wasn't there at the time this was published but the author later added it to all pages on their site.
OP here! The hx-boost hijacks links to make it feel like an SPA. I added it for fun NGL, removed it now though :)
I’m not sure why that commenter who observed these claims get surfaced all the time yet nothing has changed, got flagged/downvoted. I was about to say the same thing. I’ll add a genuine question here in hopes to spur some discussion:
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.
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.
I think there are a lot of huge misconceptions about modern web dev in posts like these. The part of the internet that’s trash is pretty much anything related to ad tech (and therefore tracking). But this is also what funds basically the entire web. Probably the best thing about the web is how accessible it is — you can use it for free if you can find an internet connection. Plus, its inherit flexibility makes it a very powerful platform. These together make it incredibly popular, but also make it ripe for abuse, and make advertisements a requirement as long as people don’t want to pay.
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.
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.
That's a great summary: economics of the internet.
Until we start discussing that, we're just going round and round with micro-optimizations while the elephant in the room continues swinging around.
Until we start discussing that, we're just going round and round with micro-optimizations while the elephant in the room continues swinging around.
> It is clear the web is turning into trash or is already there
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?
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?
I just want to point out that more people using X doesn’t necessarily make X better. More people using the web today it’s just that, more people using it.
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.
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.
For me its just anecdotal. the metric is "# of times i laugh out loud when a mobile browser pops up to show me a link and its just rendered jump and popups and things I can generally not interact with"
> 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.
What you're describing sounds like Gemini, which has been fairly successful in its own niche. https://gemini.circumlunar.space/
What you're describing sounds like Gemini, which has been fairly successful in its own niche. https://gemini.circumlunar.space/
I've ublock installed with the advanced user setting ticked, JavaScript disabled by default. The amount of blogs that load nothing until JavaScript is enabled is ridiculous. And some sites simply don't run unless you enable 60 odd 3rd party JS scripts to run.
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.
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.
I think the next step is a plugin which runs the scummy JS, captures the DOM, and makes it available in some kind of P2P fashion so that others can just load it without running the JS. I'd put $5/month in an account to pay people to cache the web for me, $10 if they'd clean up the ads while they were at it.
Here's an option: have a browser set up to defer all "onload" Javascript until the user clicks on something. Then you see if you want to do anything on the page. If nothing happens until you let Javascript run, the page looks silly and the user goes elsewhere.
Pages can still load CSS, so they can do formatting.
Pages can still load CSS, so they can do formatting.
Frameworks are a form of lock-in, or a moat. Once you build something complex, the cost of your customer changing supplier is higher. You build that local pub website using big fancy stuff and they can't hire a WordPress person to do some simple updates. Never mind a plain HTML and CSS person.
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.
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.
Interesting thought experiment: aside from streaming videos, how much bandwidth do you actually need a day? That's updates, posts, tweets, news articles, and so forth.
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.
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.
Agreed. Everyone nowadays wants to make their media in non-text forms like videos, when I would honestly prefer that your tutorial on how to bake cookies could just be in text form. We shouldn't have to load megabytes of JavaScript to "watch" a recipe online that could easily be done in writing.
I feel the frustration, and the core of the frustration is that the requirements for the web were fundamentally wrong. Thus, we keep adding new things to the browser to enable new things.
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.
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.
One of the issues with long-lived sockets is power consumption. Generally you need to send keep alive packets or else the connection is dropped and doing that forces your modem to wake up and send bytes.
QUIC is a big step in the right direction as long as middleboxes don't hollow it out.
QUIC is a big step in the right direction as long as middleboxes don't hollow it out.
This blog post itself nearly practices what it preaches. But I don't see why it even needs htmx.js since it's entirely a static site, as far as I can tell.
OP here! The hx-boost hijacks links to make it feel like an SPA. I added it for fun NGL, removed it now though :)
Aha well that's interesting, I didn't know about that feature.
Server Side Rendering is making a big comeback these days. I think we will see a big drop in transported bytes over the wire.
I've been working on a React-inspired framework in Ruby [1,2]. It only requires a few kilobytes of JavaScript, and only includes the relevant stylesheets for each page. Works pretty well and I guess I'm in a rural area (about 90 minutes down the river from Iquitos, Peru) on a 4G connection.
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...
1. https://github.com/mayu-live/framework
2. https://mayu.live/
3. https://github.com/aalin/rdom
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...
1. https://github.com/mayu-live/framework
2. https://mayu.live/
3. https://github.com/aalin/rdom
Discussed (a bit) at the time:
The Web I want - https://news.ycombinator.com/item?id=17816494 - Aug 2018 (2 comments)
The Web I want - https://news.ycombinator.com/item?id=17816494 - Aug 2018 (2 comments)
The web I want has fun, interesting, healthy applications that make the world a better place to live in.
Who cares what technology is used to build it. That’s an implementation detail for us builders.
Pragmatism > Idealism
Who cares what technology is used to build it. That’s an implementation detail for us builders.
Pragmatism > Idealism
Well, the point I'm making is the technology choices we make, have an impact on the experience of the user, literally the 2nd paragraph.
Only 1 mention of ads, and it's quickly brushed aside.
Not as if using an adblocker immediately speeds up your web browsing or anything.
Not as if using an adblocker immediately speeds up your web browsing or anything.
Case in point: http://68k.news/
There's a lot of good heart here & I dig it.
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.
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.
> Most websites are about delivering and exploring content. HTML is amazing for this, and you don't need JavaScript.
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.
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.
I don't know, when I think about the majority of the sites I visit daily, it's pretty much just content. Like, let's see:
- Stack Overflow
- Hacker News
- Reddit
- 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:
- Twitter
- Facebook
- Instagram
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.
- 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.
None of these sites on your list would be operable without JavaScript, even with reduced functionality. Heck Hacker News, probably the gold standard for simple websites, would itself be unusable. You wouldn't even be able to get the upvote/downvote buttons to work.
> Heck Hacker News, probably the gold standard for simple websites, would itself be unusable. You wouldn't even be able to get the upvote/downvote buttons to work.
Hacker News upvote/downvote buttons work without Javascript
Hacker News upvote/downvote buttons work without Javascript
I was under the impression that a few versions ago, links got a "ping" feature. Having an upvote icon become a link with a "/#" href would keep it from refreshing, and the ping would send data about the vote.
I'm not entirely sure that sort of feature requires javascript at all.
I'm not entirely sure that sort of feature requires javascript at all.
It wasn't sait _without_ but with _reduced_ JS.
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)?
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)?
That's why I said a minimum of JS, not none. You don't need 500KB of frameworks for an upvote button
This is true.
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.
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 it's worth asking why, which I guess is less fun than complaining. Are the frameworks too fat? Do they encourage wasteful network requests? Are things not being compressed? Do developers not understand how to incrementally ask for data?
Part of it is the obsession with SPAs. If your site is an application, it makes sense to ship a javascript blob to the browser and have that render everything. But 90% of websites aren’t apps. They’re news sites. They’re blogs. They’re project pages on GitHub or npm.
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.
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.
"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
Meaning the server sends html, or the server sends an image?
edit: html, at least with react
Yes, HTML.
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.
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.
Everything's downstream from the incentives. What kind of users do you attract by making your website faster/more efficient? People who can't afford a new phone, and whiny boomer nerds. Both of those demographics are more trouble than they're worth.
Speaking as a "whiny boomer nerd," I can say that another demographic is people that need the types of services we provide, and can't afford squat, because they are destitute, physically or mentally challenged, rebuilding shattered lives, or dealing with serious IRL challenges.
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.
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.
I don't agree.
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...
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...
That’s right. It’s futile to fight the battle of “the web should never have changed after year X” where year X happens to be when you first got interested in the web.
Amen.
Let's have an example of website that could be improved by reducing use of Javascript. According to the so-called "tech" company employees on HN, it's all theoretical. The web is actually just fine.
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!
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!
This post itself offers nothing concrete to criticize; I guess you're just supposed to read it and vibe? Why did the site load 35 MB of content, what are those chat channel requests, etc etc.
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.
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.
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.