Comment by pjmlp
19 hours ago
99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.
19 hours ago
99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.
>99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.
That is because the latest framework always fixes everything that wasn't broken before.
There is no good technical solution for rendering on the server and upgrading to an interactive experience on the client.
If you can tolerate the (fairly minor) SEO consequences, just render on the client exclusively and fetch data via http calls. I've made small but quite interactive websites with entirely static Svelte + some router (routify/sveltekit/etc.) SPA that just uses http calls for whatever the server needs to be involved in. It's not the right choice for everything, but for some things it works excellently. With a relatively lightweight frontend like Svelte, as well as splitting the SPA into multiple bundles (so it's in some ways not an SPA anymore) makes it perfectly usably snappy even over 200+ms latency, and very fast over a normal connection.
Ignoring for a moment that most websites don't need any interactivity: Even for those that need it, for almost any of them something JQuery-like is more than enough. You really, really, really don't need the latest super big framework.
2 replies →
Most websites don't need an interactive experience on the client, for what is static content.
I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.
Basically Flash 2.0.
This is actually plausible as a way to prevent adblock.
Bad take.
HTML is abysmally lacking for any interactive (which is what this article is about).
Decades later, even something as common as a combobox is unsupported.
EDIT: Downvotes but no argument.
It comes down the web browser being used for two different use cases and two camps arguing past one another.
Documents vs Programs
The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser.
Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.
> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity.
Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.
3 replies →
Hence CSS.
> 99% of the time those sites could be plain HTML and CSS
Some of that css and html doesn't run reliably and consistently on all browsers. A visit to sites such as canIuse helps build up an idea of the extent of the problem.
Also, you seem to ignore the fact that JavaScript frameworks use said html and CSS extensively, and provide the necessary abstractions to bridge the unreliability gap in addition to introducing features that html and css do not support.
What I really find funny about this issue is the fact that this type of claim implies that virtually all software engineers who for some reason aren't html+css purists are utterly incompetent and completely unable to assess any technical tradeoffs. Imagine yourself walking around with the belief that an entire field is manned by people who don't have a clue about what they are doing.