5 ms·

>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 res

>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.

kiwidrew 6y ago
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.
- dreadlordbone 6y ago
  Eh it's called a frugal "web browser" - I get the purpose of a document reader.
  - userbinator 6y ago
    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.
achn 6y ago
Disagree. We should build better standards so that JavaScript is not necessary to consume content. We should also separate apps from web pages.
- derefr 6y ago
  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.)
  - millstone 6y ago
    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.
    - derefr 6y ago
      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.
- adrianN 6y ago
  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.
  - the_other 6y ago
    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.
  - EveYoung 6y ago
    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?
emptyparadise 6y ago
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.
- benatkin 6y ago
  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. =)
  - userbinator 6y ago
    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.
  - emptyparadise 6y ago
    I think most people, me included, specifically mean client side JavaScript in conversations like this.
    - benatkin 6y ago
      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.
GoblinSlayer 6y ago
Most web is text and uses javascript only for google analytics, nothing essential.
- XCSme 6y ago
  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).
thunderbong 6y ago
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.

kiwidrew 6y ago

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.

dreadlordbone 6y ago
Eh it's called a frugal "web browser" - I get the purpose of a document reader.
- userbinator 6y ago
  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.

achn 6y ago

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

derefr 6y ago
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.)
- millstone 6y ago
  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.
  - derefr 6y ago
    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.
adrianN 6y ago
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.
- the_other 6y ago
  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.
- EveYoung 6y ago
  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?

emptyparadise 6y ago

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.

benatkin 6y ago
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. =)
- userbinator 6y ago
  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.
- emptyparadise 6y ago
  I think most people, me included, specifically mean client side JavaScript in conversations like this.
  - benatkin 6y ago
    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.

GoblinSlayer 6y ago

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

XCSme 6y ago
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).

thunderbong 6y ago

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.