5 ms·

> the idea of letting a site execute Turing-complete computations I'll admit that I have never been keen on the "browse with Javascript disabled" idea, but aft

> the idea of letting a site execute Turing-complete computations I'll admit that I have never been keen on the "browse with Javascript disabled" idea, but after my digging around yesterday to figure out why Reddit kept asking me to enable DRM [which I totally should've blogged about but oh well....] it shocked me to see just how much JS code was being loaded on each pageview. Now I'm seriously considering taking the NoScript plunge. The problem is that a light sprinkling of Javascript really can go a long way towards making HTML more usable -- how can we find a way to permit the "good" uses of Javascript while prohibiting all of the "bad"?

ciarannolan 6y ago
I browse with js off by default using the setting in uBlock Origin. It works great. When you encounter a site (usually news sites) where the article looks wonky, just use Firefox's "reader view" which pulls out the text and puts it into a nicely formatted, clean tab.
- dwd 6y ago
  Until they work out how to properly disable reader view because it allows you to avoid JavaScript driven paywalls and Incognito/Private Mode nags.
  - ciarannolan 6y ago
    Good point. I think some sites have already figured this out. I'll find one every now and then that clearly has a giant chunk of text in the center, but the reader view option doesn't activate. Wonder if there's a flag that disables it or something.
    - nothal 6y ago
      I find that Pocket frequently works to get around paywalls. I use it primarily for this purpose.
    - dwd 6y ago
      It might be as simple as not adding any semantic markup (an article element for example) for Reader View to use, but you could do all sorts of things with element positioning or pseudo elements to mess it up for non-humans.
      - ciarannolan 6y ago
        Apparently it's a pretty complicated, holistic system of pulling just the main text. FF uses this for its reader view: https://github.com/mozilla/readability https://github.com/mozilla/readability
userbinator 6y ago
how can we find a way to permit the "good" uses of Javascript while prohibiting all of the "bad"? By imposing resource limits? I know browsers already have time limits on script execution, but perhaps a memory limit would help too. A "light sprinkling of Javascript" would probably need KBs or a few MB at most to do what it needs to. The problem is that none of the mainstream browsers nor web developers (and especially not Google's) will want to do that --- compare new vs (unfortunately, quickly disappearing) old YouTube, for example; the latter is a mostly-static site with JS enhancements, and the former is basically a SPA. Despite the reduction in functionality of the former, the most common complaints are about how slow it is, and it uses a huge amount of RAM too.
- echelon 6y ago
  Make websites pay to run remote instructions on users' computers. It'd never happen, but it's a fun concept.
Deimorz 6y ago
I'd recommend uMatrix over NoScript. I used NoScript for years but switched over to uMatrix a few years ago (at the time it was working in Firefox Quantum but NoScript didn't yet), and I like it better now. It's quite a bit easier to see what's going on, toggle scripts and other assets from multiple sources, and you can change the defaults to do things like allow first-party scripts by default if you don't want to go all the way to full blocking. It takes a while to get used to using a script-blocker like it, but it's pretty straightforward most of the time, and once you get your most commonly-used sites set up you don't need to mess around with it very often.
- Polylactic_acid 6y ago
  I had an issue where every time I restarted firefox it would lose my umatrix data.
  - RealStickman_ 6y ago
    Sorry to ask, but you clicked the padlock, right?
    - Polylactic_acid 6y ago
      Nope. Is that how you save?
      - deleted 6y ago
        [deleted]
      - RealStickman_ 6y ago
        Yes. Otherwise everything will be lost when you close the browser.
      - xaqfox 6y ago
        There is also a cloud backup feature in the options if you are into that sort of thing.
zucker42 6y ago
LibreJS may be an option, but I've never used it myself.
zamubafoo 6y ago
Something that's surprised me is that there hasn't been a push to allow users to restrict a websites access to JS APIs. If I can restrict certain sites to different browser APIs, it would make it so much easier to get rid of annoying browsing behaviour. For example, there is no good reason to allow websites to sniff my clipboard or to play multimedia without my consent.
- metalliqaz 6y ago
  God, what a good idea. Why doesn't Chrome do this the way Android does?
- zerocrates 6y ago
  I think there is a move toward that, certainly for newer features as of several years ago (though they present their own issues to work out, see the deluge of permissions prompts for notifications). Clipboard stuff is permission gated on some browsers at least already, I think. Autoplay disabling is an option for most (all?), though that's a little different. The issue with introducing a permission system to an older feature is always a balancing act between increasing user control and potentially breaking older content.
m463 6y ago
You might want to try umatrix. there's a slight learning curve. I set the defaults to load only the main site, and load no javascript. Then per-site I turn things on until it's workable. basically start with: * * * block * * frame block * * script block * 1st-party * allow * 1st-party frame allow then enable stuff for good sites. that + reader mode makes even horrendous sites pleasant.
tannhaeuser 6y ago
> how can we find a way to permit the "good" uses of Javascript while prohibiting all of the "bad"? I always thought HTML could've been gradually extended with new elements for capturing and replacing UI techniques which Javascript is essential for, but that hasn't happened. Instead, HTML is stuck with what was envisioned in 2008 or earlier (coming from a hierarchical document structure for casual academic publishing), and everything else in the browser (CSS, Javascript) evolved to work around it. Today, we have CSS with it's absurd ninja powers to completely change and reinterpret the HTML DOM with a secondary document structure in the name of "semantic" HTML, locked to a 1990's idea of how a generic document should look like. It seems the evolution of HTML as a markup language suffered from being organizationally fossilized, after W3C ventured into an unrealistic XHTML2 moonshot, thus giving HTML language extensions a bad name, and the proponents of CSS believing their own "separation of concerns" story after the fact when it just started out as a hack to overcome HTML's limitations (it being in the hands of W3C and W3C focussing on a ten-year roll to replace HTML with XHTML and other XML vocabularies). HTML/SGML always had all the power you could want to define new vocabulary, even ways to define new elements in terms of fragments/combinations of existing ones for vocabulary evolution. To be fair, though, during most of the web's existence, a visual language had to evolve as there simply was no blueprint available for how we'd use hypertext on a massive scale, especially with mobile devices. Unfortunately, the mechanisms HTML5 today has for vocabulary evolution (ie. custom elements and maybe template elements and web components) all require tons of Javascript as well. FWIW, there's GNU's LibreJS initiative to block all but F/OSS or "trivial" JavaScript, but I don't believe it has had any impact (and it focuses solely on the licensing aspect).
- spankalee 6y ago
  One way web components can evolve to help this is with declarative custom elements, a feature many of the people who've worked on web components have wanted to pursue. The idea is that you could define a custom element, with style and DOM encapsulation, purely in markup with either no script at all, or script only for progressive enhancement. There are still a few features that need to be finalized and proposed, like Template Instantiation [1] to allow for expressions in HTML. When put together it would look something like this: <custom-element name="x-summary" attributes="href"> <template> <style> ::slotted(h1) { color: blue; } </style> <article> <a href="{{ href }}"><slot name="title"</a> <slot></slot> </article> </template> </custom-element> Which you can then use like: <x-summary href="http://..."> <h1 slot="title">Hello</h1> <p>This article is about...</p> </x-summary> Combine this with HTML modules[2] so you can import these definitions and you could build reusable widgets without script, and some UAs could evolve their script settings to allow HTML modules but not JavaScript modules for a more locked down experience. From there I'd hope we could find a way to use worklets to allow components to use script, but limit them to only the component's shadow DOM, not the global DOM, and not have default access to APIs like XHR and fetch, or other APIs used for fingerprinting. [1]: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... [2]: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HTMLModules/explainer.md https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/maste...

ciarannolan 6y ago

I browse with js off by default using the setting in uBlock Origin. It works great. When you encounter a site (usually news sites) where the article looks wonky, just use Firefox's "reader view" which pulls out the text and puts it into a nicely formatted, clean tab.

dwd 6y ago
Until they work out how to properly disable reader view because it allows you to avoid JavaScript driven paywalls and Incognito/Private Mode nags.
- ciarannolan 6y ago
  Good point. I think some sites have already figured this out. I'll find one every now and then that clearly has a giant chunk of text in the center, but the reader view option doesn't activate. Wonder if there's a flag that disables it or something.
  - nothal 6y ago
    I find that Pocket frequently works to get around paywalls. I use it primarily for this purpose.
  - dwd 6y ago
    It might be as simple as not adding any semantic markup (an article element for example) for Reader View to use, but you could do all sorts of things with element positioning or pseudo elements to mess it up for non-humans.
    - ciarannolan 6y ago
      Apparently it's a pretty complicated, holistic system of pulling just the main text. FF uses this for its reader view: https://github.com/mozilla/readability https://github.com/mozilla/readability

userbinator 6y ago

how can we find a way to permit the "good" uses of Javascript while prohibiting all of the "bad"? By imposing resource limits? I know browsers already have time limits on script execution, but perhaps a memory limit would help too. A "light sprinkling of Javascript" would probably need KBs or a few MB at most to do what it needs to. The problem is that none of the mainstream browsers nor web developers (and especially not Google's) will want to do that --- compare new vs (unfortunately, quickly disappearing) old YouTube, for example; the latter is a mostly-static site with JS enhancements, and the former is basically a SPA. Despite the reduction in functionality of the former, the most common complaints are about how slow it is, and it uses a huge amount of RAM too.

echelon 6y ago
Make websites pay to run remote instructions on users' computers. It'd never happen, but it's a fun concept.

Deimorz 6y ago

I'd recommend uMatrix over NoScript. I used NoScript for years but switched over to uMatrix a few years ago (at the time it was working in Firefox Quantum but NoScript didn't yet), and I like it better now. It's quite a bit easier to see what's going on, toggle scripts and other assets from multiple sources, and you can change the defaults to do things like allow first-party scripts by default if you don't want to go all the way to full blocking. It takes a while to get used to using a script-blocker like it, but it's pretty straightforward most of the time, and once you get your most commonly-used sites set up you don't need to mess around with it very often.

Polylactic_acid 6y ago
I had an issue where every time I restarted firefox it would lose my umatrix data.
- RealStickman_ 6y ago
  Sorry to ask, but you clicked the padlock, right?
  - Polylactic_acid 6y ago
    Nope. Is that how you save?
    - deleted 6y ago
      [deleted]
    - RealStickman_ 6y ago
      Yes. Otherwise everything will be lost when you close the browser.
    - xaqfox 6y ago
      There is also a cloud backup feature in the options if you are into that sort of thing.

zucker42 6y ago

LibreJS may be an option, but I've never used it myself.

zamubafoo 6y ago

Something that's surprised me is that there hasn't been a push to allow users to restrict a websites access to JS APIs. If I can restrict certain sites to different browser APIs, it would make it so much easier to get rid of annoying browsing behaviour. For example, there is no good reason to allow websites to sniff my clipboard or to play multimedia without my consent.

metalliqaz 6y ago
God, what a good idea. Why doesn't Chrome do this the way Android does?
zerocrates 6y ago
I think there is a move toward that, certainly for newer features as of several years ago (though they present their own issues to work out, see the deluge of permissions prompts for notifications). Clipboard stuff is permission gated on some browsers at least already, I think. Autoplay disabling is an option for most (all?), though that's a little different. The issue with introducing a permission system to an older feature is always a balancing act between increasing user control and potentially breaking older content.

m463 6y ago

You might want to try umatrix. there's a slight learning curve. I set the defaults to load only the main site, and load no javascript. Then per-site I turn things on until it's workable. basically start with: * * * block * * frame block * * script block * 1st-party * allow * 1st-party frame allow then enable stuff for good sites. that + reader mode makes even horrendous sites pleasant.

tannhaeuser 6y ago

> how can we find a way to permit the "good" uses of Javascript while prohibiting all of the "bad"? I always thought HTML could've been gradually extended with new elements for capturing and replacing UI techniques which Javascript is essential for, but that hasn't happened. Instead, HTML is stuck with what was envisioned in 2008 or earlier (coming from a hierarchical document structure for casual academic publishing), and everything else in the browser (CSS, Javascript) evolved to work around it. Today, we have CSS with it's absurd ninja powers to completely change and reinterpret the HTML DOM with a secondary document structure in the name of "semantic" HTML, locked to a 1990's idea of how a generic document should look like. It seems the evolution of HTML as a markup language suffered from being organizationally fossilized, after W3C ventured into an unrealistic XHTML2 moonshot, thus giving HTML language extensions a bad name, and the proponents of CSS believing their own "separation of concerns" story after the fact when it just started out as a hack to overcome HTML's limitations (it being in the hands of W3C and W3C focussing on a ten-year roll to replace HTML with XHTML and other XML vocabularies). HTML/SGML always had all the power you could want to define new vocabulary, even ways to define new elements in terms of fragments/combinations of existing ones for vocabulary evolution. To be fair, though, during most of the web's existence, a visual language had to evolve as there simply was no blueprint available for how we'd use hypertext on a massive scale, especially with mobile devices. Unfortunately, the mechanisms HTML5 today has for vocabulary evolution (ie. custom elements and maybe template elements and web components) all require tons of Javascript as well. FWIW, there's GNU's LibreJS initiative to block all but F/OSS or "trivial" JavaScript, but I don't believe it has had any impact (and it focuses solely on the licensing aspect).

spankalee 6y ago
One way web components can evolve to help this is with declarative custom elements, a feature many of the people who've worked on web components have wanted to pursue. The idea is that you could define a custom element, with style and DOM encapsulation, purely in markup with either no script at all, or script only for progressive enhancement. There are still a few features that need to be finalized and proposed, like Template Instantiation [1] to allow for expressions in HTML. When put together it would look something like this: <custom-element name="x-summary" attributes="href"> <template> <style> ::slotted(h1) { color: blue; } </style> <article> <a href="{{ href }}"><slot name="title"</a> <slot></slot> </article> </template> </custom-element> Which you can then use like: <x-summary href="http://..."> <h1 slot="title">Hello</h1> <p>This article is about...</p> </x-summary> Combine this with HTML modules[2] so you can import these definitions and you could build reusable widgets without script, and some UAs could evolve their script settings to allow HTML modules but not JavaScript modules for a more locked down experience. From there I'd hope we could find a way to use worklets to allow components to use script, but limit them to only the component's shadow DOM, not the global DOM, and not have default access to APIs like XHR and fetch, or other APIs used for fingerprinting. [1]: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/w3c/webcomponents/blob/gh-pages/proposals... [2]: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HTMLModules/explainer.md https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/maste...