6 ms·

This covers many of the reasons I prefer web browsing without JS enabled: speed, less mem usage, safer. Before I started doing so, I thought that disabling JS w

by seccess 12y ago

This covers many of the reasons I prefer web browsing without JS enabled: speed, less mem usage, safer. Before I started doing so, I thought that disabling JS would make the internet unusable, but a vast majority of pages display their content just fine without it. In addition, it is really easy to add domains to the JS whitelist in Chrome without the need to go into the options menu every time (less so in FF). AND, Chrome uses separate whitelists for normal and private browsing, and will clear the private browsing whitelist when you close the window! There are some periodic annoyances, but I wouldn't think of going back to default-enabled. Browsing the web in Emacs is a bit too hardcore for me though :P

insertnickname 12y ago
More and more websites now reimplement loading the page in JavaScript. Just thinking about it makes me angry.
- gnuvince 12y ago
  I really dislike how a lot of multi-page navigation (i.e. getting results 51-100) is now commonly done with AJAX. It's not really faster than loading a new page, but it breaks the back button. "Oh you clicked on the 287th link and hit back? Here are results 1-50." So annoying.
  - clarry 12y ago
    What's interesting is that in the past, all the Real web devs knew that frames suck because they break navigation. Anyone who showed their framed site in a community of cool web devs would be laughed at. Now it's cool to break the back button (and links and everything) and make me watch spinners. It's as if the text and thumbnails they're serving today somehow take two orders of magnitude more bandwidth to load...
    - mattdw 12y ago
      Devs and designers are now (more so than ever) different sets of people, and designers are now calling the shots in most places. I'm a web dev, I know that ajax loading sucks, that without enough budget to do it right (and we never have enough budget) UX ends up broken, messing with scrolling sucks, page-based is best, don't make an app if it should actually be a site, etc. Do I get any say? Not really. What do I end up building? Magic-scrolling ajax-loading apps, and if I have any budget left at the end of the job it goes on tweaking typography (i.e. designer-visible stuff) rather than fixing back buttons. Which is to say, devs still know that this stuff sucks, but we're no longer in charge of the relevant decisions.
      - oneeyedpigeon 12y ago
        Please don't make this about developers versus designers. Good web designers will not make those kinds of mistakes. Bad developers might.
  - tuxracer 12y ago
    The pushState API has been available for years. This isn't an inherent limitation of single page apps. Even where the pushState API isn't available (older versions of IE) the anchor tag can be be used to maintain browser history so the back button doesn't break. https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/M...
    - gnuvince 12y ago
      But here's the deal: now the web developer has to manually do something that used to be intrinsic to the way the web worked. Really feels like a step backwards to me.
  - endgame 12y ago
    DISCOURSE I AM LOOKING AT YOU. In a real forum I'd open pages 1-n in tabs and read them on PT. On discourse I have to open the same page N times and scroll to a spread of points down the page.
- timothya 12y ago
  Why does that make you angry? Sometimes, reimplementing how loading works can make your website more performant, for example. If JavaScript gives developers the power to make their websites better, why shouldn't they take advantage of that power?
  - clarry 12y ago
    If they haven't benchmarked their site on my computer, they don't know whether it's making their websites more performant. But years of experience with JS disabled by default (and only enabled when necessary) makes it very clear to me that using JS, at least on my system, is almost never a way to make any site more performant. On the contrary, it increases load times, cpu usage, and memory usage. It might also force me to use bloated crappy browsers like Firefox or Chrome where I could otherwise use something like w3m or links, which will display the page in a fraction of the RAM, much faster. I wouldn't be disabling JS if it weren't such a pain in the ass. Or maybe I still would, just for security.
    - timothya 12y ago
      Plenty of sites do use client-side instrumentation, and so they do indeed benchmark their site on your machine, and then make decisions based on the results of those benchmarks (likely aggregated with many other benchmarks from many other users). Yes, sometimes JavaScript is used poorly in ways that make sites bloated and slow, but plenty of sites use it properly in ways that only make their sites better (collecting the appropriate data to confirm that what they are doing is making their site better).
      - clarry 12y ago
        People talk about these sites every once in a while. But my experience is that enabling JS makes things worse across the board. If there's some site that would perform better with it, these are very much in the minority. And in my experience, "old web" sites with out JS loaders and such are almost always much faster & easier on the resources. Even if some sites deploy instrumentation, it doesn't mean they're necessarily lifting a finger to make it faster for me.
digisign 12y ago
Noscript and ghostery (for the less hardcore) do similar for Firefox. Don't browse without them! It's like a condom for the internet. I cringe every time I load up a browser on the iPad and wonder what information sites are gathering.
- JetSpiegel 12y ago
  HTTPSwitchboard for Chrome-like, and Policeman for Firefox. Those 2 extensions replace NoScript, RequestPolicy, AdBlock, you name it.
mitchtbaum 12y ago
HTTPSwitchboard is so awesome for this. https://github.com/gorhill/httpswitchboard https://github.com/gorhill/httpswitchboard P.S. Next version might be a local proxy (well, usually local) which will improve browser performance, cross-compatibility with other browsers and across OSes, and all around fit better, imho (which is that a browser's only job is to render web content).
- deleted 12y ago
  [deleted]
- not_with_retard 12y ago
  It says right on their github that it's no longer being developed, and has split into two other extensions.
chestnut-tree 12y ago
"I thought that disabling JS would make the internet unusable, but a vast majority of pages display their content just fine without it" I also browse the web with Javascript disabled (using Noscript), but have formed the opposite impression: more and more sites won't display their content (or display their content incorrectly) if Javascript is disabled. Most of the sites I'm looking at are not "web apps" or SPAs (single page apps), they are sites with text articles or links so they have no real reason to break without Javascript. (It's always annoying when you attempt to click a link only to find it won't work unless Javascript is enabled.) The rise of Javascript frameworks is only fuelling this trend of Javascript-dependent web sites. I've said this before, but Web developers pick the tools that make their lives easier (as you'd expect), but that doesn't always mean that users get the best experience.
- chriswarbo 12y ago
  > It's always annoying when you attempt to click a link only to find it won't work unless Javascript is enabled. Ah, the number of times I've asked colleagues to stop doing this! If you want a JS-powered link/button/whatever on a page, insert it using JS; then you're guaranteed that it will only show up for those who can use it. Likewise, all togglable content should begin visible, and selectively-hidden by JS during page load; that way, it only gets hidden for those users capable of showing it again. Also, although this is rarer, all work should be done in small, isolated event handlers. That way, when some unexpected situation arises (eg. the user is blocking your chosen spyware platform), that particular handler dies, but all of the rest keep working (eg. the button handlers, the slideshows, etc.).
  - krick 12y ago
    The truth is almost nobody cares about js being disabled anymore. Even if today you think it's an overestimating (I don't think so anymore) over few more years it won't be even for you. Just 2 years ago it was like "What if a customer doesn't have js enabled? We don't want to loose him just over that! Let's support both versions.", today it is already more like "No js? Weird, lol. Well, it's his own problem anyway, no reason to spend time&money on that in 2014.". When I for some reason was forced to use lynx, which I don't normally do, I was simply amazed by how smooth browsing is, it doesn't feel like the usual "internet" anymore, more like navigating your project via text editor on the local filesystem. But unfortunately as you go further than browsing ArchWiki it becomes almost unusable due to lack of static (in the sense "no js") sites support.

by seccess 12y ago

insertnickname 12y ago

More and more websites now reimplement loading the page in JavaScript. Just thinking about it makes me angry.

gnuvince 12y ago
I really dislike how a lot of multi-page navigation (i.e. getting results 51-100) is now commonly done with AJAX. It's not really faster than loading a new page, but it breaks the back button. "Oh you clicked on the 287th link and hit back? Here are results 1-50." So annoying.
- clarry 12y ago
  What's interesting is that in the past, all the Real web devs knew that frames suck because they break navigation. Anyone who showed their framed site in a community of cool web devs would be laughed at. Now it's cool to break the back button (and links and everything) and make me watch spinners. It's as if the text and thumbnails they're serving today somehow take two orders of magnitude more bandwidth to load...
  - mattdw 12y ago
    Devs and designers are now (more so than ever) different sets of people, and designers are now calling the shots in most places. I'm a web dev, I know that ajax loading sucks, that without enough budget to do it right (and we never have enough budget) UX ends up broken, messing with scrolling sucks, page-based is best, don't make an app if it should actually be a site, etc. Do I get any say? Not really. What do I end up building? Magic-scrolling ajax-loading apps, and if I have any budget left at the end of the job it goes on tweaking typography (i.e. designer-visible stuff) rather than fixing back buttons. Which is to say, devs still know that this stuff sucks, but we're no longer in charge of the relevant decisions.
    - oneeyedpigeon 12y ago
      Please don't make this about developers versus designers. Good web designers will not make those kinds of mistakes. Bad developers might.
- tuxracer 12y ago
  The pushState API has been available for years. This isn't an inherent limitation of single page apps. Even where the pushState API isn't available (older versions of IE) the anchor tag can be be used to maintain browser history so the back button doesn't break. https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/M...
  - gnuvince 12y ago
    But here's the deal: now the web developer has to manually do something that used to be intrinsic to the way the web worked. Really feels like a step backwards to me.
- endgame 12y ago
  DISCOURSE I AM LOOKING AT YOU. In a real forum I'd open pages 1-n in tabs and read them on PT. On discourse I have to open the same page N times and scroll to a spread of points down the page.
timothya 12y ago
Why does that make you angry? Sometimes, reimplementing how loading works can make your website more performant, for example. If JavaScript gives developers the power to make their websites better, why shouldn't they take advantage of that power?
- clarry 12y ago
  If they haven't benchmarked their site on my computer, they don't know whether it's making their websites more performant. But years of experience with JS disabled by default (and only enabled when necessary) makes it very clear to me that using JS, at least on my system, is almost never a way to make any site more performant. On the contrary, it increases load times, cpu usage, and memory usage. It might also force me to use bloated crappy browsers like Firefox or Chrome where I could otherwise use something like w3m or links, which will display the page in a fraction of the RAM, much faster. I wouldn't be disabling JS if it weren't such a pain in the ass. Or maybe I still would, just for security.
  - timothya 12y ago
    Plenty of sites do use client-side instrumentation, and so they do indeed benchmark their site on your machine, and then make decisions based on the results of those benchmarks (likely aggregated with many other benchmarks from many other users). Yes, sometimes JavaScript is used poorly in ways that make sites bloated and slow, but plenty of sites use it properly in ways that only make their sites better (collecting the appropriate data to confirm that what they are doing is making their site better).
    - clarry 12y ago
      People talk about these sites every once in a while. But my experience is that enabling JS makes things worse across the board. If there's some site that would perform better with it, these are very much in the minority. And in my experience, "old web" sites with out JS loaders and such are almost always much faster & easier on the resources. Even if some sites deploy instrumentation, it doesn't mean they're necessarily lifting a finger to make it faster for me.

digisign 12y ago

Noscript and ghostery (for the less hardcore) do similar for Firefox. Don't browse without them! It's like a condom for the internet. I cringe every time I load up a browser on the iPad and wonder what information sites are gathering.

JetSpiegel 12y ago
HTTPSwitchboard for Chrome-like, and Policeman for Firefox. Those 2 extensions replace NoScript, RequestPolicy, AdBlock, you name it.

mitchtbaum 12y ago

HTTPSwitchboard is so awesome for this. https://github.com/gorhill/httpswitchboard https://github.com/gorhill/httpswitchboard P.S. Next version might be a local proxy (well, usually local) which will improve browser performance, cross-compatibility with other browsers and across OSes, and all around fit better, imho (which is that a browser's only job is to render web content).

deleted 12y ago
[deleted]
not_with_retard 12y ago
It says right on their github that it's no longer being developed, and has split into two other extensions.

chestnut-tree 12y ago

"I thought that disabling JS would make the internet unusable, but a vast majority of pages display their content just fine without it" I also browse the web with Javascript disabled (using Noscript), but have formed the opposite impression: more and more sites won't display their content (or display their content incorrectly) if Javascript is disabled. Most of the sites I'm looking at are not "web apps" or SPAs (single page apps), they are sites with text articles or links so they have no real reason to break without Javascript. (It's always annoying when you attempt to click a link only to find it won't work unless Javascript is enabled.) The rise of Javascript frameworks is only fuelling this trend of Javascript-dependent web sites. I've said this before, but Web developers pick the tools that make their lives easier (as you'd expect), but that doesn't always mean that users get the best experience.

chriswarbo 12y ago
> It's always annoying when you attempt to click a link only to find it won't work unless Javascript is enabled. Ah, the number of times I've asked colleagues to stop doing this! If you want a JS-powered link/button/whatever on a page, insert it using JS; then you're guaranteed that it will only show up for those who can use it. Likewise, all togglable content should begin visible, and selectively-hidden by JS during page load; that way, it only gets hidden for those users capable of showing it again. Also, although this is rarer, all work should be done in small, isolated event handlers. That way, when some unexpected situation arises (eg. the user is blocking your chosen spyware platform), that particular handler dies, but all of the rest keep working (eg. the button handlers, the slideshows, etc.).
- krick 12y ago
  The truth is almost nobody cares about js being disabled anymore. Even if today you think it's an overestimating (I don't think so anymore) over few more years it won't be even for you. Just 2 years ago it was like "What if a customer doesn't have js enabled? We don't want to loose him just over that! Let's support both versions.", today it is already more like "No js? Weird, lol. Well, it's his own problem anyway, no reason to spend time&money on that in 2014.". When I for some reason was forced to use lynx, which I don't normally do, I was simply amazed by how smooth browsing is, it doesn't feel like the usual "internet" anymore, more like navigating your project via text editor on the local filesystem. But unfortunately as you go further than browsing ArchWiki it becomes almost unusable due to lack of static (in the sense "no js") sites support.