Hacker News Reader

Comment by dreadlordbone | Hacker News Reader

>JavaScript disabled by default.

To ignore one of the pillars of the modern web seems silly to me. I understand that a lot of sites have become bloated and resort to chunking in JS, but I disagree that JS is used as just seasoning on top of a website.

View on HN

Disagree. We should build better standards so that JavaScript is not necessary to consume content. We should also separate apps from web pages.

What about "content" that certainly is a document, but which just happens to not be a hypertext document? For example, a mind-map, or zoomable-level-of-detail timeline. Content that, on the modern web, you'd expect to be sent as a lightweight Javascript viewer app wrapped around the document itself. But where that's only required because the web-browser itself isn't already doing the job of attempting to render that document. Like it does with, say, SVG.

A lot of people think that "web browser" has some fundamental identity with "hypertext document viewer", but that's not what "the Web" is — the web is the set of resources you can request over HTTP; not the subset of those resources that are formatted in HTML. A "web browser" is fundamentally "a tool for letting you navigate to the resources at HTTP URLs" — essentially an address-bar with a "meta-renderer sandbox" attached.

(Remember RealPlayer, QuickTime, and other plugins you could install that would enable your web browser to "natively" render new content types? Those things are all also "the web"!)

And to put an even finer point on it: if you put a PDF, or an SVG image, at a URL; and that PDF or SVG image contains clickable links — then that document is a web hyperdocument. A web of PDFs is just as much a web as a web of HTML documents is! So not even "publishing hyperdocuments on the web" is necessarily coupled to HTML. (Tangent: remember VRML? It allowed clickable links, too. VRML was a hyperdocument format!)

(Are plaintext files that happen to include textual URLs, hyperdocuments? If so, then a gopher or FTP client would also technically be a "web browser." That's going a bit too far, I think.)

GP's critique is not that web browsers render SVG and PDF in addition to HTML. It's the outsized role of JavaScript specifically: our browsers execute arbitrary (possibly user-hostile) code while simultaneously trying to protect us from its effects.

The point I was trying—perhaps failing—to make, is that it doesn't make much sense to create a web browser that can render "web documents" but not "web apps", since the concept of a "web document" is basically "anything you can access over HTTP", and so a "web browser" — a tool for viewing arbitrary "web documents" — really doesn't work as a concept except by adding some mechanism to execute arbitrary code in the service of viewing those arbitrary documents.

That mechanism doesn't necessarily need to involve code being delivered directly from the same server the document is coming from, mind you. It could instead involve an out-of-band app store, where accessing a URL zero-installs a heavily-sandboxed plugin required to view it, and loads it into the browser. (Implementations of this: iOS App Clips; Sandstorm grains.) But those apps are usually still created by the same developer as the document anyway, so there's little difference between this out-of-band zero-install app approach, and having Turing-complete web documents. Either way, the developer of Boogle Maps can still mine bitcoin in the background while you have the map loaded.

Web documents and web apps are getting split anyway with site specific apps, so web browser can focus on text documents just fine.

That’s mostly a marketing trick to get the company’s brand on your phone home screen.

It’s also a side effect of the demands of the attention economy fighting against Apple’s refusal to allow web notifications on iOS.

I imagine apps are better at being apps than a web browser, and due to their complexity webapps are also tightly coupled to a specific brand and version of browser, so you have less compatibility problems by bundling your preferred vm with your application.

I'd argue today that "apps" do pretty well whether they're in a browser or native. Native Slack is pretty good. Web Google Docs/Sheets is pretty good. VSCode is almost the same regardless of where you run it. But equally, Sketch and Ableton Live are also pretty good. Native Teams and Zoom are travesties of usability and stability.

Basically, I don't see consistent patterns of good or bad between web and native apps to justify your comment that "apps are better at being apps than a web browser".

Most GUI apps, native or otherwise, get associated with a brand. Especially the good ones. I'd buy Ableton swag, I love the brand that much.

The VAST bulk of web apps are NOT browser version specific. It's largely only bespoke, internal corporate apps that are tied to one version of a browser.

Relevant post: https://news.ycombinator.com/item?id=25915313

...on mobile.

The B2B productivity/collaboration app space — where you can expect that all your users are mainly using full PCs — is firmly all-in on in-browser web-apps, with their mobile experiences being second-class afterthoughts.

You are arguing a point I didn’t make. I think it would be great if we build standards for consuming media and content like mind maps and charts - I just don’t want to be forced to open up to running any arbitrary code to be able to consume that content. We’ve been lead into a false dichotomy.

My point was that — allowing that "the web" is just arbitrary 'stuff' at URLs, and that a "web browser" is a tool for viewing that arbitrary 'stuff' — there are always going to be novel non-standardized, proprietary document types residing at URLs, that people will nevertheless expect their web browser to display for them (and rightly so!)

How will users view these documents in a timely manner (i.e. not on the W3C's glacial schedule)? Whatever your answer, it's going to necessarily involve some kind of arbitrary code execution at some point. Whether that means Javascript; Java/ActiveX applets, or PPAPI (NaCl); Chrome Apps or other in-browser centrally-managed-lifecycle apps; installable NPAPI plugins like Flash; or COM component servers (as seen when e.g. IE/Edge is navigated to an .xlsx file URL.)

Presuming the user discovers they can't view document X, and therefore goes and hunts down tech Y and installs it to make X viewable, all such "tech Y" are equivalent in the sense that they're someone's arbitrary proprietary code, that the user is rolling the dice on hopefully allowing them to view X, while not doing anything other than allowing them to view X.

> allowing that "the web" is just arbitrary 'stuff' at URLs

It's not. The majority is just textual content I want to read. Possibly with a few images.

I don't need Javascript for that. And being forced to use Javascript for it is the exact problem.

For the minority (something clever that requires user interaction beyond reading text and looking at pictures, this "non-standarized", maybe even "proprietary" stuff) Javascript is just fine.

But don't force me to use Javascript for the rest.

We tried that with XML, and no-one liked it.

The majority of web developers think the semantic web is a waste of time. (I don’t)

Pushing your point further, you’re saying that every new development that could be shareable over the web gets published as a standard and that browser developers build implementations of those standards, before the content is released. By the time that’s happened, your mind map will be out of date.

When anyone creates a novel representation someone will need to develop new code that renders it. Whether that goes into a native browser or a Java applet or a JS script, it’s still arbitrary code downloaded from a source you need to establish trust with.

You’re taking this too far. (And I admit my illustration smudges both your and my point).

The problem we really have is that advertising and SEO have corrupted the web to the point of unusability. If we (google mostly) hadn’t monetised individual tracking, we wouldn’t need the worst bits of what people do with javascript. Publishers are fighting for your attention because that creates surface for advertising. And advertising creates revenue. If they could sell content directly rather consumers wouldn’t get caught in an attention war and websites would be less intrusive and demanding.

Javascript itself isn’t the problem. I’m not convinced that scripted documents are the problem. The problem is surveillance capitalism and the attention ecconomy.

Javascript is not necessary to consume content. It wasn't necessary twenty years ago. It's necessary to deliver complex applications that happen to also run in the browser. We don't need another standard to usurp HTML+Javascript, we need to stop the practice of using technology that is meant for writing applications like Google Docs to display two paragraphs that were copied from the AP news feed.

We didn’t need it, but it does make content better.

Most of the problematic javascript that exists isn’t “content”, or even “apps”, it’s surveillance capitalism, attention capital and advertising.

I think it really depends on the audience. While certain use cases justify optimisation and SSR, for many sites it just doesn't matter that much. If most of the users are on desktop and have fiber/4G, why bother with all of that?

It looks to me like this design concept is meant as a browser for consuming the web of documents, i.e. pages meant primarily for reading. A news article or a blog post has very few legitimate reasons for using Javascript. (Perhaps some very advanced interactive charts/graphs/maps?)

You'd obviously want to use a different browser to run sophisticated webapps.

Eh it's called a frugal "web browser" - I get the purpose of a document reader.

When you are "browsing the web", i.e. looking for information and following links to various places, how much of your time is spent interacting with complex webapps vs. reading text, looking at images, and following links?

I would say that if you are using a webapp, you are not really "browsing the web" anymore, but simply interacting with an application in much the same way as if it was a local one.

It says 'disabled by default'. Which means, you can enable it.

Also, this kind of a browser is not really for the general populace.

I mostly browse with Javascript disabled. If a site doesn't work without Javascript, I have a shortcut key to enable it.

I think breaking the pillars of the modern web is kind of the point here. JavaScript is necessary for web applications and it can be enabled manually for those, but it shouldn't be needed for static text.

JavaScript frameworks like Next and Nuxt are great at generating static markup. One thing slowing them down a bit, and giving AMP a larger share of attention, is that not enough people are browsing with JavaScript disabled. Disabling JavaScript on the browser doesn't mean JavaScript is out of the picture. =)

Indeed, I don't think the people arguing against JS are arguing against all uses of it --- rather, it's become synonymous with "client-side scripting/code execution", and even if that was a totally different language, the point still stands.

I think most people, me included, specifically mean client side JavaScript in conversations like this.

Well, with Next and Nuxt, the client side JavaScript is also running on the server. It's isometric. So you turn it off, but it keeps running.

Most web is text and uses javascript only for google analytics, nothing essential.

I tend to disagree, most of my web usage is:

* Google (which uses JS for autocomplete and faster results)

* Gmail (uses a lot of JS)

* Media: YouTube/Twitch.tv (they use JS)

* Chess (chess.com, uses JS)

Yes, I sometimes read News or HackerNews and Reddit but they also use JS (comments, upvotes, inline media playing infinite scroll).

Reply on news.ycombinator.com