Hacker News Reader

https://www.w3.org/2001/tag/doc/leastPower.html

From the perspective of a web developer or publisher, they of course want as much power as possible. But this is really a tradeoff, directly taking away power from end users - the accessibility you handwaved away, as well as things like adblocking, user-styling, caching, and every other unenumerable concern of endpoints.

I'm not saying that a delivery system for opaque executable blobs isn't the inevitable fate of the web, just that this shouldn't be viewed as progress but rather decay.

> the accessibility you handwaved away, as well as things like adblocking, user-styling, caching, and every other unenumerable concern of endpoints.

You are speaking of things that can and should be addressed with APIs provided by the browser.

Are you thinking this API would be extension-facing, or page-facing?

For the former, then the browser still needs to be able to understand the page to implement this API functionality. Turing-completeness is incompatible with this understanding.

For the latter, then that requires page authors to explicitly opt-in to those mechanisms. Obviously they won't do this when incentives are opposed (eg ad blocking). And even in the cooperative case, would require pages to anticipate all features viewers would require.

I disable JSbecause, on a lot of sites, I'm only there to read words on a page and those words come up instantly without JS and in as long as 30 seconds with it.

Why do you think Google created AMP (which is just a fancy way of telling devs to stop using JS for text sites)?

Look, there are plenty of site for which JS makes a huge difference - proper web applications. For every one of those site there are 9 that load half a MB of cruft so they can animate their stupid banner.

I'm not saying text content doesn't have its place, but what I am saying is that unless you're absolutely certain your users aren't going to be using JS (hint: that's effectively no one) then it's just not worth your time to accommodate those users - especially when they optionally disable JS, AND you have to degrade the experience for the rest of your users in most practical applications. How often do you design features for 1% of your users?

A lot of it is about performance, if you need JS to fetch the content of your site after the SPA or Shell has loaded then you are incurring a significant amount of overhead for something that could have been streamed from the server and rendered as it was parsed by the browser.

Performance will come as the need develops. Yes it's faster to render something on the server right now, but that may not be the case in the near future. The concept of loading something from the server is also only accounting for a very specific use case. These days most websites will require more data from the server after the webpage has been loaded anyway.

Server rendering simply wont make sense for some binary applications, such as games.

Playstation Now exists and is server rendering for games: https://en.wikipedia.org/wiki/PlayStation_Now

>AND you have to degrade the experience for the rest of your users in most practical applications

I would say the opposite. The absolute majority of developers who insist on requiring JavaScript with no option to gracefully downgrade on pages that do not need it are the ones degrading the web experience.

From my experience having JS turned off, most sites render the text I want to read in a readable fashion sans JS.

All the time, as 1.2% of my monthly users is 1.15 million people (hint: that’s effectively a lot of people). People will be accessing my content and using my services with Javascript deliberately off or situationally unavailable, and they need to be able to do so. It’s defensive design.

Is it really true you don't need JS for AMP? Checkout Washingtonpost.com/pwa

AMP pages can’t include any author-written JavaScript. Instead of using JavaScript, interactive page features are handled in custom AMP elements. The custom AMP elements may have JavaScript under the hood, but they’re carefully designed to make sure they don’t cause performance degradation.

https://www.ampproject.org/docs/get_started/technical_overvi...

Thanks for sharing. How do you go about taking a current website and building a PWA? Do I have to change my website architecture drastically?

I'm interested what if my site already is 'amp' - do I really need to have a duplicate page? And add even more markup?

I don't understand amp, Google already has loading time as signal, just increase it even more.

If your web page doesn't work without javascript it is probably doing something between malicious (Like refusing to let me download an element displayed on a page) to staggeringly malicious (Like tracking me with analytics) to petty (Like dictating how I read a page).

It's not that nothing should change, it's that change should make things better. I firmly believe pages made better by javascript are such a small minority as to be an rare exception, but overall the web is so much better with that 'feature' disabled.

> I'm so tired of people using "it doesn't work without JavaScript!" as an argument. To me it sounds as relevant as saying "it doesn't work without HDMI!"

I don't understand your reasoning; I don't have any HDMI equipment (except my RaspberryPis, which are headless servers anyway), so I certainly would avoid anything that's HDMI-only.

Just because you, at the moment, only use the Web for a few pre-approved purposes (e.g. viewing rendered pages) via the handful of user agents which support Javascript, on operating systems supported by those user agents, on hardware supported by those operating systems, which is powerful enough to run it all, that doesn't mean everyone else is. Some are less fortunate, as they have older, or less-powerful equipment. Some are more fortunate, as they are using the Web in more imaginative and novel ways than you are.

Okie doke, you are missing out on a lot of HDMI-equipped hardware, and if you don't use JS, you are missing out on a lot of JS features.

Web pages can be rendered any which way you please, it's no skin off a developer's back if you don't have JS enabled for their JS project.

> Okie doke, you are missing out on a lot of HDMI-equipped hardware, and if you don't use JS, you are missing out on a lot of JS features.

I don't specifically avoid HDMI, I've just never encountered a situation which involved HDMI. Also, I hear it's riddled with DRM, and I don't see the point upgrading when it seems to be becoming obsolete anyway (DisplayPort? ThunderBolt? Newer USBs? etc.)

I have no issue with JavaScript itself. I have issues with what web developers do with it:

- Hideous wastefulness of resources, causing constant unnecessary repaints, enormous RAM usage, etc

- “Experiencejacking”: things like scroll hijacking, back button hijacking, etc

- All the privacy invasions that JS enables

These wouldn’t be issues if sites suffering from them were the minority, but they’re not. Most sites have mountains of poorly optimized JavaScript that gives zero thought to performance or resource consumption. Once it works, it’s shipped.

The fact is that front end web dev culture as a whole places very little value in things like performance, battery life, resources, and ultimately, respect of the end user’s desires, and that’s a huge problem. As long as the whizz-bang shiny flashy checkboxes are checked, it’s all good.

The problem, as people see it, is there is a whole space of websites that use features they don't need. Think of all the 1pageapp content sites.

To borrow your comparison, people who are bothered by what I describe above see it like a website saying, "Hey, we won't work on your device unless it's HDMI because of the design choices we made!"

The difference now is that most people are using browsers that will automatically update in order to work with new features.

And someone will mention how a full-scale language inside a browser is the hugest attack vector of all. Soon as a binary delivery platform - yay!

It's not a real environment though. It's a sandboxed environment with limited, user-authorized APIs.

Nowadays even Wikipedia has a section on JavaScript sandbox implementation errors. Even without taking JS into account, browsers, colossal beasts they are, have had a history of security vulnerabilities in HTML, CSS and image decoding routines. With JS added... again, Wikipedia says it best: "JavaScript provides an interface to a wide range of browser capabilities, some of which may have flaws such as buffer overflows." Ergo, no amount of "sandboxing" will ever save you from trouble.