> The web is an app delivery platform now, not just an information delivery platform.

No arguments there.

> Plus, we have a lot of processing power on the client side, which should be utilised.

I don't agree with the "should" here at all. Lots of the stuff is done on the client these days which could be done cheaper on the server. If I'm visiting a site that's developed as an application then I fully expect to running a bunch of JS, no qualms there. But there is no reason my phone should be forced to build a bunch of HTML just so I can read an article, and that's the problem: people are developing information sites as "apps". This is a large factor of why my phone can't hold a charge for a full day.

> people are developing information sites as "apps"

This statement nails the problem that all of us suffer from. It’s like people have to add “feature” to make their site compelling because the information on it is not good enough.

I would happily build a service that simply took all the JS heavy sites people visit and present them as basic HTML.

Unfortunately, I don't think there'd be enough takers to make it a viable product.

Information for free, without ads is tough to do.

> But there is no reason my phone should be forced to build a bunch of HTML just so I can read an article

But the goal usually isn’t to let you read an article.

Often the goal is to get you to read another article, click an ad, sign up for a newsletter, or buy a subscription. Apps can be good for all that.

Original comment: users get a HUGE amount of value from JS

You are correct here: the goal is to get you to read another article, click an ad, sign up for a newsletter, or buy a subscription

But I think that contradicts the idea users get a lot of value from JS.

You are correct, and

The word "app" is a bit overloaded and I really just mean a buttload of client-side JS. What you're describing there is app-like but can be easily delivered with server-render HTML with minimal client-side JS enhancements. When I say "app" I'm more talking about an in-browser text editor, an image editor, a DAW, etc.

At the risk of sounding like a broken record, try and switch javascript off on your mobile device. It's like using an ad blocker, really.

But because we're not neanderthals, you can also whitelist the sites/apps you like to run JS (in Chrome) and/or use another browser for your JS-powered sites/apps.

Right, but I often want to read those sites so I don't bother (but perhaps I should go for it). Though really I'm speaking vicariously through the hoards of non-technical people who don't even know what JS is who enjoy long battery life.

You can enable per domain by clicking on the lock icon by the URL.

That said the modern web is generally very broken with js off, but it does get rid of most cookie banners, modal email sign ups prompts and generally lets your read article number 6 of the 5 free ones.

The web was an app delivery platform 20 years ago, at least that’s what the folks at Sun and Adobe tried to tell us. But then everyone pitched a collective fit and rejected injection of a runtime container into the browser. Now we have the current situation of an inferior technology and architecture being used as an app delivery platform. If one views a web browser as a proper platform for hosting applications I’d argue WASM and even the aforementioned tech (applets/flash) are superior.

In what ways are applets/flash superior to browser engines/JS? I really can't see it at all.

In the way I think IntellJ is a better application than attempting to rewrite IntellJ in JS and run it in the browser. This would hold for any number of applications. HTTP, HTML and the DOM were not designed to run rich applications. It’s been a continuous series of hacks to, IMO, solve a problem that was solved a year or two after this nonsense started. The problem was that of application delivery and updating. But iTunes quickly showed widely accepted software did not need to be distributed on physical media but could be installed and updated over the network.

I think PWAs are the future. The industry is just slow at getting to it.

It's not that the industry is slow. It's just hard to push PWAs forward when Apple is actively hostile toward web apps.

Still waiting on iOS Safari push notifications to actually work...

Why haven’t PWA’s displaced native Android apps? That can’t be Apple’s fault, can it?

The only people who truly want PWAs are web developers and product managers that do not prioritize their users.

Why learn anything new or spend anything extra when you can just ship substandard web crapware to users who have no choice (looking at you, Slack).

Isn't that like saying only big companies with specialized roles are allowed to provide app-like functionality?

Among others, smaller shops and single-person companies surely benefit from one delivery platform if you ask me. Even if it's not perfect.

I don't see how it's like saying that. Do you think a single person can develop a PWA but a single person can't develop an Android app?

> Plus, we have a lot of processing power on the client side, which should be utilised.

That does not mean it should be utilised by you. Have some humility as a developer.

> Plus, we have a lot of processing power on the client side, which should be utilised.

It would be one thing if this was a matter of consent. It isn't. It uses your resources without your permission. Leaving JS on is not permission to consume as much CPU as you want (otherwise, every website would also run a crypto miner).

> If a site uses it badly, just don't go to that site.

This sort of blitheness is very surprising to me. What if we're talking about a passport site, or an unemployment benefits site, and so on? Why is the onus on the user and not the developer?

Well said.

There needs to be an API in the client for specifying how much CPU can be used. Clearly things like crypto mining in the bg are considered abuse but what about just poorly written js? Clients should be able to police the code they execute.

The choice is with the user. The onus is on the developer to build something good and efficient, otherwise people will not use the product.

If the user is forced to use a terrible government website (as we all are from time to time), disabling JS will fix absolutely nothing there. If anything, it might make things worse, as there will be a bunch of things you simply cannot do without JS (e.g cropping a photo to upload to a passport site - how would you even draw out the crop region without JS?!)

JS is not the problem. Crappy developers and corrupt officials who award key contracts to crappy developers is the problem.

It's the ads that are the problem. A crappy website is sad but fixable. At least it provides some value.

Ads are are a nuisance race to the bottom.

Depends on what you're doing. Everyone uses the word "website" like it's just one type of thing. You DON'T need JavaScript for a website that has no interactability, like a personal blog with no comments or reactions features. You DO need it for... well, almost anything else you want to let the end user do.

I think a lot of these "you don't need JS" things you see out there are either (a) a sensible reminder that your JS-filled app doesn't have to do EVERYTHING with JavaScript (looking at you, JSS), (b) a contrarian "JS sucks" take, (c) an appeal to use outdated tech like PHP instead, or (d) just a clever way of getting attention on sites like hackernews.

It’s funny you mention HN. With comments and voting and no js.

How do you think HN handles voting and collapsing threads without a page load?

It's this JavaScript that is loaded at the bottom of every page:

https://news.ycombinator.com/hn.js

There is a no-JS fallback. If you disable JS with uBlock Origin or whatever, then reload the page and try voting, you will see the page reload. But thread collapsing won't work at all.

My argument lately has been: Should we be allowing code to run inside of our documents? Am I okay with PDFs, jpegs, mp4s etc. running arbitrary code when I open them?

imo the extension is how we communicate the purpose of the contents: if it's a .js or .exe file, expect execution, and take appropriate precautions

while media _shouldn't_ run arbitrary code, there's also nothing stopping a malicious actor from crafting something that breaks through a buffer overflow in the .mp4 codec for example

the safest bet would probably be "assume anything can run arbitrary code, even if it's not supposed to"

PDF files can run JavaScript. It's used in a lot of fillable forms.

https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/...

https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/...

It's still nice to make your page compatible with users who have Javascript turned off by default (noscript/umatrix). That way you can still use ancient HTML forms for server-side interactivity.

> Plus, we have a lot of processing power on the client side, which should be utilised.

Preferrably in useful work. The fact that end user interfaces are sometimes slower than what they were in the late 90s suggests this is often not the case.