[Qwertious]

"The modern web" often depends on JS, but the World Wide Web was originally created as a system for sharing documents, and some people refuse to accept the slow change towards web-apps, especially in cases where it's unnecessary. For instance, news articles don't need JS.

JavaScript is fine for e.g. territorial.io - where JS isn't an implementation detail but critical to the core concept - but if it's unnecessary, then some people despise being forced to use it.

Disabling JS reduces third-party blocking code, tends to speed up page loads by removing the need to download JS scripts, has no degradation of the content 99% of the time, and is an extremely effective ad/tracker blocker. Overall, it's not hard to see why some people love it.

JS also breaks some web browsers, which pisses off anyone who likes those web browsers.

JS is often proprietary code running on the client's computer, or at least hard-to-verify open-source code that's running on the client's computer and creates unnecessary remote code-execution security holes.

I don't care personally, but I can see why some people do and I think "the modern web" is rather problematic and needs to be reformed.

I think JS can actually be a good thing overall (when executed properly), because it reduces the need to load content from the server and thus can make the user's app more resilient against inconsistent internet connections. Also, JS runs client-side which is better than relying on code that runs serverside, as a rule. (See "service as a software substitute".)

[onion2k]

the World Wide Web was originally created as a system for sharing documents

I agree with your post but every time someone says this about the early web I feel a strong stabbing sensation in the back of my mind. It's just wrong. The web was never just a document sharing system. In Tim Berners-Lee's original memo he talks about dynamic pages that are built on the fly, and 'special links' to external apps.

To quote the memo;

"Hypertext allows documents to be linked into "live" data so that every time the link is followed, the information is retrieved. If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide."[1]

Dynamic apps running in browsers weren't really a thing until the later 90s, but accessing apps via Common Gateway Interface that rendered HTML on each request was a thing right from the start. That's where I started my career. The web has never been about just static documents. If nothing else it it wouldn't have been necessary if that's what Tim was proposing - we had networked access to document systems before the web was a thing.

But also... Tim wrote his memo 34 years ago. 'The modern web' in the sense of Web 2.0 has been around for at least 20 of those years. Even if the original web was about document sharing, there's no reason to believe that's still the case.

[1] https://www.w3.org/History/1989/proposal.html

[forgetfreeman]

You aren't the only graybeard in the room. What you're describing isn't the original intent or usage of the web, but the very beginnings of the ongoing process of enshitification of the web writ large. Yes, from jump there were folks that refused to meet the media on its terms . Table based layouts, JavaScript googly eyes, "jello mold" layouts, flash-based fonts, etc. This trend has culminated in usability issues, page weights, and browser feature creep that can best be described as abusive bordering on sociopathic.

[sanderjd]

The original memo outlining the vision of the web was not describing "the original intent or usage of the web" but rather was "the very beginnings of the ongoing process of enshitification of the web writ large"?

This seems like a very extreme degree of revisionism.

Like, you could say, "the original vision was bad, because it included the seeds of enshitification". That seems plausible to me, from the perspective of people that just want static hypertext.

But it was clearly seeded in the original vision, not something that developed later.

[forgetfreeman]

I'm clearly not as familiar with Tim's writing as you. Please direct me to the relevant parts that call for walled gardens, grotesque disregard for screen readers, and all of the myriad layers of gratuitous protocol/language/feature cruft that's been troweled over the original medium in a largely successful attempt to convert it into a strip mall?

[sanderjd]

I'm not familiar with his writing at all. But conveniently, the person you replied to included a link to the full text they were quoting from. Did you miss that?

[onion2k]

in a largely successful attempt to convert it into a strip mall

Humans do that to everything. Why would you expect the web to be any different?

[pjc50]

> JS runs client-side which is better than relying on code that runs serverside

For what purposes/criteria? You can't just say "better" in a vaccum and not have an argument in HN comments.

The server-side CPU is often a lot more efficient and less thermally throttled, for example. A lot of client-side stuff seems like double-billing for energy: serialize data on server, deserialize it on the client, do a transformation which has also just been sent over by the server, then and only then render data.

[mschuster91]

There are distinct advantages of client-side rendering, but it depends on usage patterns.

One case is you're something like Reddit, Facebook or Twitter: the transformation logic (i.e. JSON-to-HTML) is cheap in bandwidth to send once and have the client re-use it countless times. Bonus point, you can re-use the backend code for various frontends (web app, native iOS/Android/... app, Electron app).

The second case is anything that has a large number of one-time visitors: delivery of the transformation logic can be done using a cheap (and visitor-local) CDN, and you only need to scale the backend servers according to load - and you only need to pay for this task, as the computational cost is outsourced to the visitors.

The case where server-side rendering shines however is infrequently visited sites or ones that don't have external or internal interfaces, like a company's or personal blog or homepage: there, the effort required to maintain complex logic on both server and client is greater than just throwing up Wordpress.

[JohnFen]

You're listing the benefits for the website, and you're right -- those benefits are why sites do this.

But what it's really doing is lightening the burden on the server by increasing the burden on the client. There is little benefit to your readership. And allowing client-side scripts also decreases security and privacy.

[Dalewyn]

>Also, JS runs client-side which is better than relying on code that runs serverside, as a rule.

This is not true, server-side code is a fixed, known environment so it is strictly better for any critical code and especially anything to do with security authentications.

[deely3]

Parent comment probably mean "better/clearer for user", while you arguing is what " better for provider".

[Dalewyn]

It's also better for the user.

Do you really want your super important and critical stuff to be handled by code that can be examined and modified on the fly with no damns given with the server completely unaware?

Not to mention server-side code by its nature doesn't execute client-side, which means less end user system resources used and thus less electricity consumed by and billed to the end user.

[sanderjd]

> Do you really want your super important and critical stuff to be handled by code that can be examined and modified on the fly with no damns given with the server completely unaware?

Is this supposed to be an obvious "no"? To me it's a pretty resounding yes.

Personally, I'd like servers to do a good job of returning well-structured data quickly, and to be able to manipulate that however I want on the client side.

[MrJohz]

Anything that is "super important and critical" will need to be validated on the server no matter what. But by pre-validating things in the browser, the user can have a more intuitive, seamless experience. Is the username you're typing already taken? No need to press the submit button, then scroll around trying to find the correct error message, we can give you feedback while you type.

You are right that there are tradeoffs, and I agree that client resource usage is under-analyzed, but sensible use of client-side code can make things like forms, visualisations, tables, etc much easier to use.

[onion2k]

server-side code is a fixed, known environment

At least until someone changes it.