Hacker News Reader

Comment by snickerer | Hacker News Reader

Allowing scripting on websites (in the mid-90s) was a completely wrong decision. And an outrage. Programs are downloaded to my computer and executed without me being able to review them first—or rely on audits by people I trust. That’s completely unacceptable; it’s fundamentally flawed. Of course, you disable scripts on websites. But there are sites that are so broken that they no longer work properly, since the developers are apparently so confused that they assume people only view their pages with JavaScript enabled.

It would have been so much better if we had simply decided back in the ’90s that executable programs and HTML don’t belong together. The world would be so much better today.

View on HN

> Programs are downloaded to my computer and executed without me being able to review them first—or rely on audits by people I trust

Would've been cool if we could know if site X served the same JS as before. Like a system (maybe even decentralized) where people could upload hashes of the JS files for a site. Someone could even review them and post their opinions. But mainly you'll know you're getting the same JS as before - that the site hasn't been hacked or that you're not being targeted personally. If a file needs to update, the site could say in the changelog something like "updated the JS file used for collapsing comments to fix a bug". This could be pushed by the users to the system.

Especially important for banking sites and webmail.

Stepping back, it's pretty ridiculous that I need to download executable code, often bloated, solely to view read-only content. Just render the thing on the backend and send it to the client.

But the web-dev-hype people told me that JS-heavy SPA’s (and associated designs) were faster and better for the user!

I didn’t bother validating this, but I’m sure they wouldn’t lie or misinterpret!!

For me personally the most infuriating example of this is the Azure Updates[1] page, which in my job I need to check nearly daily to see what's reaching EoL, what's new, etc...

A couple of years ago they redeveloped it as a SPA app.

The original server-rendered version of it worked just fine, but it "had" to be made into an interactive client-side monstrosity that loads many times slower for "reasons".

It doesn't even load successfully about a quarter of the time. It shows items in reverse order (entries from 2013 first), which is some sort of async loading bug. They will never fix this. It's been there for two years already, it'll be there for a decade more, mark my words.

Then, it takes about a minute to load sometimes on a poor connection.

The links are JavaScript and don't allow "open in new tab".

Etc...

All of this to enable client-side filtering, which is a non-feature nobody ever wanted. A simple server-side filter capability would do the same thing, faster.

And anyway, the filtering is broken! If click the "New or updated" filter, it drops down an empty selection with no options. Clicking anything else doesn't change what is shown!

While developing this over-engineered monstrosity, they took the original site offline for "maintenance!"

Hilariously, despite Azure having multiple CDN products, the Azure Updates page doesn't correctly use their own CDN and marks almost everything as "no-cache; no-store" causing 2.5 MB (after compression) to be re-transferred every time, despite using unique signed URLs with SHA256 hashes in them!

This is the state of web-dev in the 2020s: A multi-trillion-dollar software company can't hire developers that know anything else other than SPA web app development!

This commonly used page has spectacularly poor web engineering, and this is from a company that sells a web app platform, a CDN, and the ASP.NET web app development framework!

If they can't get it right, who can!?

[1] https://azure.microsoft.com/en-au/updates/

GitHub also got infected with this horrible "JS SPA" disease shortly after MS bought them. Now you can't even browse files or view issues without it.

If they can't get it right, who can!?

Berkshire Hathaway, apparently: https://www.berkshirehathaway.com/

Pure content, not fluff, and even has a small but unobtrusive ad.

Weird, I remember Github as a pioneer of SPAs: in ~2013 you could browse code tree without the page reloading.

Though I agree today's Github is awful slow, JS is required to see issues, …

And https://www.berkshirehathaway.com/ loads blinding fast

My favorite part of that site, besides it loading incredibly fast, is even though it has an ad, for a wholly subsidiary, on it it is hard coded in the html.

> Programs are downloaded to my computer and executed without me being able to review them first—or rely on audits by people I trust.

JavaScript and WebAssembly programs are always executed in a sandboxed VM, without read access to the host OS files (unless, of course, you grant it).

Enabling scripting was a necessary step for interactive websites. Without it, a full page load would be required every time you upvote a Hacker News comment. In my opinion, the real problem is that browsers allow too many connections to third-party domains, which are mostly ads and trackers. Those should require user-approved permissions instead of being the default.

The Triptych Proposals [1] cover a lot of common use cases for submitting information to a server and updating part of a page. Something like that should have been possible to implement early in web history (I perceive some similarity to frames).

Modern CSS (and some newer HTML features) also reduces the need for scripting.

I very much doubt that "Enabling scripting was a necessary step for interactive websites." (emphasis added). It may well have been the most convenient and fastest way to get the functionality to the most users. With Javascript each website could provide functionality without waiting for such to be implemented by all browsers.

However distribution of power also leads to more complex trust relationships (even if one is confident that sandboxing is effective). Independent implementation also leads to more complexity overall.

[1] https://alexanderpetros.com/triptych/

In the world we have now, limiting XMLHttpRequest and Fetch to the same host as the current page would be great. But if that had always been the limitation, I fear that the adware peddlers would have just gotten proficient at shipping PHP packages/extensions that you could run on the same server as your site, and we'd be in largely the same situation, except that blocking the stuff would be harder than it is for us today.

Why can't MY browser send some random JS to THEIR website? If it's safe for me to run some stranger's code, should it be safe for strangers to run my code?

There is obviously huge demand for scripting on websites. There is no one authority on what gets allowed on the web, if the existing orgs didn't implement it, someone else would have and users would have moved over when they saw they could access new more capable, interactive pages.

The 49MB webpage just shows what our priorities are. It shows the target audience has fast internet that can load this without issues. On my average home connection in Australia, I can download a 49MB page in 0.3 seconds. We spend time optimising for what matters to the end user.

Is the page actually done downloading 0.3 seconds after it starts? Or is it just (your Internet speed) / 49MB = 0.3 seconds?

Disable not just JavaScript, but also CSS. I'm not kidding. Many websites actually contain all the content in HTML but use CSS to hide and then use JavaScript to show it again.

If scripting wasn't allowed, we'd probably all have a different browser that allowed it - probably wrapped in a Flash wrapper.

Reply on news.ycombinator.com