Ask HN: Why would you disable JavaScript? - <AUTHOR> Base info: I'm a front end dev born in the early 90's with three years experience.
A lot of older dev's that I've worked with have told me that best practice often includes making sure that the site is usable even if you've got javascript disabled.
To me, this is completely bonkers. Are we really supposed to cater to the sub 2% that chooses not to use javascript?
To me it would make more sense to use that time to make the sites usable for visitors with disabilities by including screen reader support and stuff like that. <comment><USER2> Because it reduces the attack surface of the browser?

Because not all search engines could cope with it (this reason now obsolete).

Because of a variety of screen readers and browsers which don't (reason also obsolete).

It's good practice to not go with batshit insane navigation, however (infinite scroll interactions with the back button, anyone?), or require JS for trivial inanities, or not have relatively meaningful URIs.

<comment><AUTHOR> Great answer. I wouldn't couple js with insane navigation though, that's a different problem entirely (which we as a community need to shun until it disappears).

</comment></comment><comment><USER3> It kills a lot of autoplay videos, popups -- the "in page" variety -- and other dark patterns I see on a lot of sites. The only regret I have is that ads get disabled too so if it's a place I really enjoy a lot and they have a means to donate, I give them something.

Besides this, it also gets rid of a lot of ad tracking without having to install any plugins specifically to block it. I'm a big fan of using existing features, both in software and hardware, to their fullest before extending them.

But the biggest reason is my computer is a bit slow too and I don't want to spend hundreds more just to consume text; something that hasn't changed since the dawn of the web and something I've been doing for years. It's wasteful to pollute my closet and a landfill in the future with e-waste because single- page apps and fancy transitions don't work properly.

</comment><comment><USER4> > Are we really supposed to cater to the sub 2% that chooses not to use > javascript?

In my opinion: No.

JavaScript should be treated as default feature of the browser now. It's about as worth the effort as catering to people who want to use Lynx as their browser.

The screen reader argument is bogus too, modern screen reader software is not hampered by JS.

I also wonder if those who disable JS because of the increased attack surface also disable CSS as well.

<comment><USER5> Don't troll. CSS cannot run arbitrary code on your device.

<comment><USER4> Neither can JS, as it is sandboxed.

The interpretation and application of CSS directives is not Turing complete, but often enough to leak information from your browser.

<comment><USER6> > Neither can JS, as it is sandboxed.

Not true. It's definitely possible to escape the sandbox. Some examples:

[https://github.com/rapid7/metasploit- framework/tree/master/m...](https://github.com/rapid7/metasploit- framework/tree/master/modules/payloads/singles/firefox)

[http://www.mozilla.org/security/announce/2013/mfsa2013-12.ht...](http://www.mozilla.org/security/announce/2013/mfsa2013-12.html)

[http://www.iss.net/security_center/reference/vuln/googlechro...](http://www.iss.net/security_center/reference/vuln/googlechrome- javascript-bo.htm)

[https://bugzilla.mozilla.org/show_bug.cgi?id=805121](https://bugzilla.mozilla.org/show_bug.cgi?id=805121)

[https://www.usenix.org/legacy/event/woot08/tech/full_papers/...](https://www.usenix.org/legacy/event/woot08/tech/full_papers/daniel/daniel.pdf)

</comment></comment></comment></comment><comment><USER7> I have it selectively whitelisted via NoScript, rather than just disabled. I only enable it for a domain when there's a compelling reason (i.e. it's not just for ads/trackers) and even then, the permissions will be temporary unless it's a site I frequent.

Most of the time browser security flaws rely on JavaScript in some way, so this makes me more secure by default at the expense of usability. It has a happy side-effect of disabling other random annoying things as well.

</comment><comment><USER8> From the UK government:

> Surprisingly, the proportion of people that have explicitly disabled > JavaScript or use a browser that doesn't support JavaScript, only makes up a > small slice of people that don't run JavaScript.

[https://gds.blog.gov.uk/2013/10/21/how-many-people-are- missi...](https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out- on-javascript-enhancement/)

</comment><comment><USER9> I normally browse using Firefox with the NoScript add-on. The other day I was using Chrome, and following an HN link, the article had an ad with colored balloons cascading down the screen. On another site, I got a pop-under ad. On yahoo News, the javascript took so long to load the browser locked up for ~10 seconds - I couldn't even scroll. Using Chrome felt similar to browsing in the mid-2000's.

Honestly, I think the overuse of javascript on media sites has become so f'ing obnoxious that I don't know how people put up with it.

</comment><comment><USER10> Thats a great question, and the answer depends on what your product is. If you are making SaaS or a web based app, then it is perfectly reasonable to require JavaScript. If you are making public websites, that display content or represent a brand, then you probably want to cater to those who don't have it enabled. Also remember it is not just the 2% that have javascript disabled that you need to consider. You should also take into account anyone who would require 508 compliance on your site. Thinking about 508 often leads to a more conscious decision on how to structure script based functionality on your page.

</comment><comment><USER11> Turn the question around. What exactly are you providing with Javascript that is _essential_? If in the final analysis there is nothing essential, only spit-n-polish, then _why not_ cater to a broader audience by employing progressive enhancement.

In my opinion better designs would emerge from the influence of this design constraint, along with better tools and frameworks.

<comment><USER12> JavaScript allows you to use WebGL, which is essential for high-performance 3D interactive content in the browser.

Granted, not many websites need WebGL, but the ones that do need JavaScript.

<comment><USER13> I'd suggest that you've not really answered the question.

yes webGL is a nice feature, but is it _required_?

For example, a menu is required for navigation, however it doesn't need animations to work. Sadly there has been a trend for things that actively slowdown or hamper speedy navigation (the breaking of the back button, animated transitions etc.)

Thats not to say JS is inherently bad. but when a website sucks 90% cpu to essentially display text, there is something drastically wrong.

</comment></comment></comment><comment><USER14> It's called "progressive enhancement". There's a lot that's been written about it, and it's still a debate-provoking topic, but it's not just about catering to people that choose not to use javascript.

[http://en.wikipedia.org/wiki/Progressive_enhancement](http://en.wikipedia.org/wiki/Progressive_enhancement)

[http://jakearchibald.com/2013/progressive-enhancement- still-...](http://jakearchibald.com/2013/progressive-enhancement-still- important/)

</comment><comment><USER15> I wouldn't. But I have Ghostery installed and in some cases it completely destroys sites. So my guess is that the 2% you're mentioning could get a bit higher. I don't know how popular utilities like Ghostery or NoScript are outside our community but I won't be surprised if their usage rises.

<comment><USER16> People should be testing what happen to their site when random resources you're pulling in don't load.

Only time ghostery breaks sites for me is when some massive 'page failed to load' element site on top of the content. I can delete those with dev tools.

</comment></comment><comment><USER17> I don't disable JS in the browser preferences. I use FF with No Script to enable it selectively for only the sites and the functionality I need.

Example 1: HN needs JS only for voting so I don't enable it here unless I want to vote a post or a comment. However HN's JS is trivial and can be easily inspected so I might want to enable it permanently as well.

Example 2: YouTube requires JS from 6 domains but I can keep four of them disabled and still be able to view videos. I really don't need googlesyndication.com, plus.googleapis.com and googletagservices.com (among the other things I'm missing comments but who cares). Some of them are probably just spyware. I also don't need google.com but Google Maps don't work without it so I probably already enabled it before going to YouTube.

Example 3: TechCrunch is a nightmare of nested JS requires. However I can read it without enabling any JS and it's also much faster to load.

If your site is (example) an Angular single page application I'll probably enable enough JS to make it move and check it out. If there are so many JS dependencies that I can't find the right combination and I see JS coming from well known spyware domains I might decide to skip that site completely. There are sites like that. If I'm really interested I fire up Chrome and give them a try in there. Actually, I might install the new Opera only for using it as a honeypot for that kind of sites.

<comment><USER18> Browsing the web must be a pretty painful experience for you

<comment><USER19> From my experience with NoScript, quite the opposite: no annoying video popups (yes, yes, technically it's a full-page DIV nowadays), no animated nonsense.

And in cases where JS is required for the page to work, I enable it with two clicks.

</comment></comment></comment><comment><USER20> There are many different reasons why Javascript should only be enhancement.

First of all, it always additional stuff to load, which takes time. Think, you are on your mobile with shitty cell reception. It happened for me just a few weeks ago in Nepal and Bhutan. If your site rely on Javascript, you cant even do a simple reload.

Javascript also adds an additional layer. It takes time to execute. You could argue, that device are fast enough, but for me that is only the argument for the lazy people who don't want think. Like, what about I can't afford a faster device or I don't want. Like, my mom still has a PPC Mac Mini and she don't want a newer computer, because she is very fine with it. My dads PC is even older running an version of Windows XP using some version of Opera.

In general your thinking should be not about how many people I am excluding, but instead how many people I am including.

Like e.g. I am using DataTables myself to make it nice and pretty. I could include the data via JSON instead of including an HTML table beforehand. But why? If I include the HTML table, then I can assure the 100% of the HTML browser, whatever type, can display it.

It is always about inclusion, inclusion of every people who has some sort of disabilities or dislikes. This should be very first priority. Then the second priority should be about making it nice, pretty and shiny.

</comment><comment><USER21> I always disable JS by default. It prevents a lot of the cross-site tracking bullshit from working. And catering to users with disabilities tends to be easier when your page content is represented as page content and not dynamically loaded by JS.

<comment><AUTHOR> Dynamically loading content has problems beyond screen readers, for stuff like SEO, so I get your point. Another guy did post this link though, showing that most screen reader users have js enabled: [http://a11yproject.com/posts/myth- screen-readers-dont-use-ja...](http://a11yproject.com/posts/myth-screen- readers-dont-use-javascript/)

<comment><USER21> Of course they do, or they would not be very useful given the number of horribly-built websites today, but even the JS-enabled screen readers can get confused by dynamically loaded content, sometimes getting it in the wrong order or not being able to access content that's triggered by things like infinite scrolling. Still, requiring JS for core non-interactive functionality is a net negative for any website. Why spend more effort on making your site more annoying?

</comment></comment></comment><comment><USER22> If the purpose is to present static information, such as what you get with a newspaper Javascript shouldn't be necessary. It is just plain lazy design.

It should only be necessary with interactive pages, or web apps.

The 2% who choose not to use Javascript are mostly the tech savvy ones who know the kind of malware vector Javascript is. Some of them may be your employers, so be careful when you use bonkers to describe their preferences.

</comment><comment><USER23> Back in the day it was also about supporting the various lo-fi web browsing devices that were around at the time. WAP on mobile phones, and TV set top boxes (Was it called WebTV? Those were the days.)

Now I agree it's only to support web fundamentalists who disable it completely, and those people surely must be used to having sites not work properly.

At the same time, if you require JS for things that don't need it, like basic navigation or dropdown menus, then that's lame for a different set of reasons.

In general, the principle of progressive enhancement is still a useful and important one. It's good to know how to make a great website in pure html and css, and then to layer the JS on top, simply because it's an effective technique that results in good code and usable websites.

</comment><comment><USER24> Maybe some people care about their privacy? A lot of ignorant webmasters load Facebook, Google analytics, twitter buttons and other privacy violating JavaScript. The only way to guarantee some level protection is by disabling JavaScript, plugins and cookies.

</comment><comment> raving-richard Yes you are supposed to cater to the 2%. Wolfram Alpha says 2% of the US population is 6.39 million people. That's how many potential people from just one country you are treating badly. And as for screen reading users, that's just another 2% isn't it (or another "tiny" number). Why do you care about them? Well, it is the law, but, it's also just sensible.

Also, people browse with poor Internet connections, and even if they have JS enabled, the JS might time-out before it downloads, and so they'll just have to see your content without it.

I browse without JS on most sites (and I need a good reason to enable it) for at least the following reasons:

1\. It's safer for me.

2\. I've lived and will live in places with really shit Internet connections.

3\. It also conveniently gets rid of a bunch of crap (flashing stuff, ads, flashing ads, etc.) without me having to do anything specifically.

4\. It blocks some tracking across the Internet (I also use RequestPolicy to really drive that message home).

Other reasons as well. Edit: including it's too often used for unnecessary fan-inducing overly-CPU using shit.

So you don't want me as a potential visitor? A tech-savey person? I'm not your target audience? That's OK, there's loads of other sites on the web, and I'm sure that yours is crap anyway. After all, if it wasn't crap, you'd have made it work without JS.

Edit: And if you are stupid enough to not be able to make your site work without JS, then at least put a noscript message explaining why your site is special enough to require JS, and why I shouldn't just close the tab and go to the next site. If you explain that it is necessary to make the froggles boggle, I'll think about it more than if you just say "you need to enable JavaScript or upgrade your browser". No, fuck you, I don't need to enable JS, you need to make your site work without it. Displaying text and images in no way requires JS, unless you're a real thicko who shouldn't be allowed to have any commit privileges.

<comment><USER25> wow, that's really hostile. Why are you so angry about this?

<comment> raving-richard Because people go and make sites that don't work with JS. Even though often it's /more/ work to make the site not-work with JS. And then they justify it by saying "well it's only 1 or 2 percent". It's not hard. And then "professionals" (like the OP) think that everyone has the latest fancy computer with super fast Internet (there are _developed_ countries with rubbish Internet connections, let alone the less-developed countries that often share a single megabit per second for the whole country).

It's like people saying "well blind people, they don't even count, like who cares about accessibility anyway?". Fuck those people.

It's like the people who think it's just fine and dandy to have Google Analytics and Facebook trackers, and all the rest. Even when they should know better! You're contributing to a worse society by giving these companies so much power!

Next these young white men will wonder why anyone cares if someone jokes about "raping some bitch". I mean it's just a joke right? It's not serious. Why are you getting so up tight. Geeze, women. PC is just going too far.

And I guess this is just for your. Because this has dropped of the front-page. I think I need to go back to /., which while awful in it's own way, doesn't have men too young to shave asking stupid questions.

<comment><USER25> Slightly hilarious, because /. is _full_ of men too young to shave asking stupid questions.

I'm not asking a question about style or sites, or use of JS. I'm asking about your anger. Are you really this angry over stuff? I have a lot of experience with mental health issues and raging at the world because it doesn't behave the way you'd like it to is a sure-fire path to any one of a number of disorders.

I'm not going to tell you to calm down, because that's patronising. But maybe you could take a look at your anger and ask yourself why you're so angry (without blaming it on other people's behaviour).

</comment></comment></comment></comment><comment><USER26> It can be very useful and be used to add useful features.. but 90 percent of javascript is for delivering unwanted annoyances like ads... or when not malicious it can be used to annoy. making what looks like ordinary links to unexpected things and now the browser back button doesnt go back because I was actually clicking js links and operating a js app rather than clicking real links..

There's a small subset of great uses of javascript. The rest is just hovering toolboxes so I can easily "+1" the page despite not having a google+ account.

I prefer the web without the annoying stuff. Once js gets past the "look at what I can do" phase id welcome it more openly.

</comment><comment><USER27> It depends on what you are making I think. If you are making a website, a site like Youtube lets say, where the goal is to have as many people use it as possible it would make sense for you to have it work with a variety of limitations that users might have. If you are creating a very specific SAAS then you are probably able to convince many users to run javascript if they get something good back for it. In the end, if you are willing to pay $50/month for something, you might also be willing to enable JS, while if you are visiting a random website that doesn't work without JS you might think 'never mind, I don't need this'.

</comment><comment><USER28> We're building an app in AngularJS right now and have had to think about this.

What we concluded was for our use case, if they weren't happy running JavaScript, they probably weren't going to be happy with our content which is live video streams.

We also took a long hard look at browser compatibility and decided we didn't care about anything below IE9. That's a ballsy move to some people, but we are a modern tech firm developing modern tech.

We're happy to build the best experience we can using the best technology, and letting the market come to us. If they can't access it because of technology reasons, well, somebody else can pick them up as an audience. If they can't get a modern browser running on their Windows 95 box, they're probably going to be happier installing Linux and something a bit more modern anyway.

The one area where there is some pushback is accessibility. I'm not just talking about screen readers here, but colour blindness and navigational coherence.

You don't get to choose what technology and capabilities your audience have, but you do get to choose if you care about them.

In our case, we have decided the cost of supporting the 2%-5% we're actively excluding would actively harm the rest of the audience in a noticeable way - so we have chosen not to do it.

</comment><comment><USER29> For website content (landing pages, articles, etc), you want it to work without Javascript so that crawlers index it properly.

For web applications where you don't care about content being indexed, I wouldn't worry about it being a javascript only application (and this is the direction lots of apps are heading with frameworks like Ember.js, Angular.js, and Meteor).

<comment><AUTHOR> Even in these cases there are workarounds that prerender the page and serve them to crawlers. They're not pleasant to work with, but we went with that solution on an old site we did in angular.

</comment></comment><comment><USER30> Why would I disable JavaScript?

Several reasons, for me. (NoScript):

It renders many attacks moot. JS is complex - a lot of browser attacks rely on it, either directly or as a trigger.

It really helps with privacy - for example, PanOptiClick currently says that I leak ~12.3 bits of information. With JS enabled, I'm unique from fonts alone!

It helps with battery life - the number of times where I've wondered why I'm losing battery life so rapidly, only to find some webpage is idiotically running JS continuously...

It helps with data usage - not (generally) the JS itself, but the resources pulled in by JS. Varies from website to website, but in general definitely helps.

Webpages tend to load faster - I have iffy latency on this connection, and cutting 2+ round-trips off of website loading times really helps.

Now, as to your comment "it would make more sense to use that time to make the sites usable for visitors with disabilities": the simplest way to make sites usable for visitors with disabilities is to make sure they are usable without JS.

</comment><comment> Al-Khwarizmi If your PC is old and you don't have much CPU or RAM to spare, disabling JavaScript gives a _big_ performance boost.

</comment><comment><USER31> A site doesn't have to work completely without JavaScript, but its a good idea to support primary flows without it and make sure your site loads and basically functions. If you are talking about a product who's features and UI require JavaScirpt then let the user know why the product can't be used and move on.

</comment><comment><USER32> Wouldn't it depend on the type of audience you're trying to appeal to?

I would imagine the amount of people disabling JS would be a lot more coming from a site like HN, compared to say, pintrest. It would be worth making sure your site functions without JS if you know a lot of your audience will be disabling JS.

</comment><comment><USER33> Well, if it's a website then it should be optional. If it's a web application then it shouldn't be. HTML and web are about linked documents after all. The fact that industry decided to slap a scripting language on top and call it GUI doesn't change the initial concept.

</comment><comment><USER34> Depends on what you're building, I guess.

For particulary security sensitive areas, like banking web software, I'd very much appreciate it working with JS disabled, since I take particular care on security when visiting those (updated, secured, sandboxed OS within VM, not used for anything else).

<comment><AUTHOR> Good point, it sure makes sense for sites with higher security demands. I'm in the ad world though, and there's not that much security risks involved in campaign sites.

</comment></comment><comment><USER35> A user disabling JavaScript is only one piece of the no-JavaScript puzzle.

Here are some more: [http://isolani.co.uk/blog/javascript/DisablingJavaScriptAski...](http://isolani.co.uk/blog/javascript/DisablingJavaScriptAskingTheWrongQuestion)

"To me it would make more sense to use that time to make the sites usable for visitors with disabilities by including screen reader support and stuff like that."

That assumes the choice is mutually exclusive, and also that we live in a world of perfect delivery and execution of JavaScript.

Progressive enhancement not only ensures core functionality is available regardless of JavaScript, but also when a hiccup of some sort happens on the Web, the user in the process of buying from you isn't then stonewalled.

</comment><comment><USER36> I'd disable javascript sometimes because it takes up CPU cycles and memory on my laptop and starves my other applications. GMail specifically has gotten so bad that I've started using the HTML version of Gmail just to avoid all the unnecessary javascript cruft.

</comment><comment><USER37> I think you're spot on. I've noticed working with various people and ages that we get stuck in our beliefs. Their information is outdated and they haven't realized yet that screen readers and security are dated arguments.

The only hardcore crowd who disables Javascript entirely are people who are paranoid about ads and the uber nerd (as seen here on HN).

As a web developer myself, I would never waste what busy time I have catering to this audience. It's the same argument for why, at a certain point, you have to make a clearcut decision about how far back into legacy browsers you care to support. Large parts of Asia are stuck on IE6 because they have pirated Windows XP, but most of us don't care and probably don't need to.

</comment><comment><USER38> It really depends on your audience. As a general rule, you should try to make your site allowable for javascript-disabled-noobs to still be able to go through the primary functions of your site.

With that said, out of our 1m visitors a week, we have less than 0.1% with it disabled. So it's a tradeoff - how long will it take you to code the extra to allow those 0.1%, and does this require extra code and junk up.

We don't support any browsers once it gets to below 1% - aka IE7 so I don't generally go out of my way to make sure everything works for non-javascript users.

It used to be more important back in the day with the old school mobile browsers etc with the good ol' WAP (as Jonnie says)

</comment><comment><USER39> There are some who would consider that the default behaviour of JavaScript in web browsers is unsafe. They went off and made things like [https://developers.google.com/caja/](https://developers.google.com/caja/) and [http://www.adsafe.org/](http://www.adsafe.org/).

In my day to day web browsing I don't really see good use cases for JavaScript. In addition, IMO rendering feels faster with JS disabled, specially on mobile devices (iPhone 5s).

A part of your "sub 2%" includes some security researchers. Think about that for a moment.

</comment><comment><USER40> It is obviously not feasible to make all full-blown web apps work without JS, but many basic websites are also packed with annoying amounts of JS that do not do the user any good (for details see the other comments).

</comment><comment><USER41> Because it's prone to bad coding and makes my browser crash. Even sites made by giants like google and facebook crash because of bad JS code.

Because web experience has become shitty ever since excessive usage of JS. I'm sick of pages that download megabytes of JS libraries just to animate a button hover. Thanks to CSS3, Now we can do all the needed UX/UI stuff without JS. Make the web better by not using JS.

</comment><comment><USER42> >To me it would make more sense to use that time to make the sites usable for visitors with disabilities by including screen reader support and stuff like that.

If your site works without Javascript, you pretty much get this as a bonus. Two birds with one stone.

Also, people use things other than the browser to access your content. Think wget, curl, stuff like that. Do you have a reason to make it harder for them?

</comment><comment><USER43>
        Are we really supposed to cater to the
        sub 2% that chooses not to use javascript?

To put this into proper perspective, IE 6 still has 4.2% of the browser market, and I doubt the vast majority of us still support _that_ ([https://www.modern.ie/en-us/ie6countdown](https://www.modern.ie/en- us/ie6countdown))

So, to put it simply, no.

<comment> raving-richard I don't support MSIE 6, or 7, or 8, or indeed any version of MSIE at all. But, and here's where it's different to not supporting users without JavaScript enabled, sites I make are still perfectly viewable in MSIE. And Lynx. And other esoteric browsers.

Progressive enhancement/graceful degradation allows me to build sites that work everywhere.

Not support users with JS turned off is exactly the opposite.

</comment></comment><comment><USER44> It seems there are less reasons the more time passes. I thought that screen- readers don't support javascript (imagining something like lynx), but it turns out that its a myth by now: [http://a11yproject.com/posts/myth-screen-readers- dont-use-ja...](http://a11yproject.com/posts/myth-screen-readers-dont-use- javascript/)

<comment><USER45> I can confirm this. Recently got a complaint from a blind user about an inaccessible form element that was buried deep deep within our JavaScript web app. We learned a couple of things that day.

</comment></comment><comment><USER46> The best reason I've heard, is around redundancy/robustness.

HTML recovers from invalid syntax and missing resources, it'll still function as a page displaying content with functioning links to other pages and such.

Same can't be said of JS, one missing resource or syntax issue and it can break, which depending on how much you rely on it can leave the page unusable and a user stuck.

</comment><comment><USER47> My primary browser has JS, cookies and plugins completely disabled, and when I open a link and get nothing but a white page it is pretty frustrating. I understand that with these settings i'm not going to see any fancy animations, menus, ads, games, ecc but I at least expect to see some text.

I don't expect nothing else, if I can get some text I'm happy.

</comment><comment><USER48> It really depends on your product. If you have an e-commerce site, you may find that 5% of your browser base could be IE8. You still want them to spend money.

It's very much a financial decision. Who is your target market and is it reasonable to assume they will have a modern browser OR you can dictate that they have a modern browser.

You then have the issue of accessibility.

</comment><comment><USER49> IMO, it depends on the nature of application that you are building. If it's going to be used by an audience that includes people stuck with ancient browsers, then ignoring that 2% could be a loss. But in most general cases, it's obviously better to cater to those ~17% people with reading disabilities (I read this figure somewhere).

</comment><comment><USER50> I disable it on my very very old netbook because the difference in page load speed is huge in most cases. It has the added bonus of not firing up the CPU as much so the laptop fan doesn't kick in as often. If a website needs javascript, I either don't go to it anymore or selectively enable scripts to get the site working.

</comment><comment><USER51> Others have covered why one might disabled JavaScript. Adding to the reasons why one shouldn't develop depending on JavaScript is clients using browsers that may depend upon a proxy server, e.g. Amazon Silk and Opera Mini. Pages loaded in these browsers may have only limited support for JavaScript.

</comment><comment><USER52> If your website is security or cryptography related, then you'll need to cater to your demographic. These are the overly cautious types who use NoScript and disable javascript everywhere.

Otherwise, I wouldn't worry about it.

</comment><comment><USER53> Wow. I see from comments, such an enormous many people disabling javascript!

<comment><USER54> Huge sampling bias here. Most people who keep Javascript enabled aren't going to comment here.

<comment><USER53> do I see correct? you are saying, paradox's just happened!

</comment></comment></comment><comment><USER55> Yes, I do that all the time when I'm watching porn. Both JavaScript and cookies. It sure makes me feel a lot safer.

But, unless you're building a porn site, I wouldn't worry much about it.

</comment><comment><USER56> Because I want to read text, not run some unknown code on my machine.

If you're not showing plain text with JS off then you're bonkers, and I don't really need your site.

</comment><comment><USER57> I would disable javascript to stop loading social-crap-buttons and overbloated sensless js. it's save my accu on mobile phone.

</comment><comment><USER58> Besides security reasons, I turn it off on my mobile. 10kb of text load much faster than 500kb of javascript and some text.

</comment><comment><USER59> I have a JS blocker browser plugin/extension as standard, so I always end up browsing sites with JS off.

</comment><comment><USER60> It would make sense back then when browser security was potatoes. Today, even firefox made it hard to disable Javascript. In fact, our startup website doesn't even load unless you have Javascript enabled.

Also, it's not sub 2% today, it's more like sub 0.01%.

</comment><comment><USER61> As an aside, if I recall,  was deprecated in HTML5.

<comment><USER62> Nay. Its status is currently candidate recommendation,[0][1] so I assume they are trying to integrate it into the HTML5 standard as well.

Although, I am sure someone proposed to make it deprecated in HTML5.

[0] [https://developer.mozilla.org/en- US/docs/Web/HTML/Element/no...](https://developer.mozilla.org/en- US/docs/Web/HTML/Element/noscript)

[1] [http://www.w3.org/TR/html5/scripting-1.html#the-noscript- ele...](http://www.w3.org/TR/html5/scripting-1.html#the-noscript-element)

</comment></comment><comment><USER63> lynx rules, for HTML, the 90's internet technology.

</comment><comment><USER64> the reason I do it is because I dislike being tracked by marketing companies and other entities. and it's pretty effective.

</comment><comment><USER65> Your main question seems to be the least relevant. You're speaking to the "2%" because many of them hang out here and all you have now is reasons that they turn off JS. I think what you really want to know is 1) What kinds of sites can get away with failing completely when js is disabled? 2) Are there any good estimates on the number of people who regularly browse with JS disabled? (Because I'm not sure if your 2% estimate is correct.)

As for the primary question, personally I think that application-sites like GMail, Google Docs, etc can get away with posting a polite message that "this site requires Javascript". However, any site where text content is the main attraction should show the content without Javascript being required (so, News, Blogs, etc).

However, if you're working for people who were doing web development in the 90's, who insist that every single feature of every single page should work without Javascript...you should run. Those people are dinosaurs and they're living in the past.</comment>


Ask HN: Is it possible to implement scrum in a multi-project environment? - <AUTHOR> The agency I've been working for some months now, decided, after years of waterfall mode, to move into Agile development.
I have experience in a scrum (I know agile is not only scrum) environment but have never worked in a multi-project company before, so I wonder if it's possible to adopt scrum in a company like that (Because I'm referring to projects and no products to start with :)).
Of course not every project has the same amount of work, some of them require a few hours of maintenance a month, some full development of new features...
We don't have enough people to have a team per project (we're around 5 backend developers, 1 Fronted dev + 2 interns, 1 designer and 1 designer/frontend developer) So I don't really know how it would be possible to have self-organized cross-functional teams, define a sprint, etc.
Do we need a different product backlog per client, with a different sprint planning, retrospective? Several PO's? How do we split the teams?
Also, if the clients need to approve the designs, how do we integrate UX/UI into a cross-functional team? Wouldn't this put in risk the sprint? Should we ditch scrum and pick something else?
I know, so many questions but would really appreciate if anyone can share some info/ experiences!
Thank you <comment><USER2> I've worked at an agency that went fully into Agile and Scrum.

When it worked well, we had a single sprint board with different product backlogs, with different PO's for each product (where possible). All dev work would go onto a single sprint board, and we'd all attack the highest priority story (where possible) until the dev work was complete. UX/UI were introduced into the team, and when it worked best they worked with the frontend developers to create designs and prototypes to be signed off, and this went through typical backlog grooming until it was ready to go fully into the sprint.

In my experience, Scrum only works in an agency environment when "the process" is strict. All ceremonies/meetings run for the amount of time required, all clients are aware of the process and have a product owner on hand to speak to, standups are kept short and purely as a technical update, rather than a reporting meeting, and sprints are worked out properly and never overloaded, with sprint points being adjusted based on velocity.

When we stuck to this process, everything worked brilliantly, and the way we worked felt more robust. Instead of everything coming across the line in one go, we were testing and releasing individual stories on time, and when things inevitably changed we adjusted where needed or told the client to wait until the next sprint.

Of course, over time our management took liberties. Standups were attended by account managers (who decided they were no longer product owners) and turned into 30 mins+ reporting meetings, sprint retros and reviews stopped, and sprint planning was reduced to an hour. Additionally, we were asked to deliver part-way through a sprint and to deliver to UAT with no testing. The difference in delivery was night and day. We went from a team that could deliver quickly with ample testing time and enough of a break between sprints to not feel stressed, to a team of cowboys that deliver buggy code.

</comment><comment><USER3> Is it the same projects/ code for all clients? If so do they get the same built product? 1 backlog.

Different code for different clients? Many backlogs.

Projects share code base maybe?

Then you need Prioritization, planning and if you don't have that as a prerequisite then do Kanban maybe.

It sounds like you cannot split the team and depending you could just have 1 product owner or a proxy PO.

If clients need to approve designs that's design and backlog grooming- once the story is ready move it into a ready state (tag or state attribute)

If you're reactive then kanban works better than sprints but of course depends on your environment, product/project mix, support vs product dev, and team composition</comment>


The Year Without a Summer - <AUTHOR> https://en.wikipedia.org/wiki/Year_Without_a_Summer <comment><USER2> I'm continually amused that one of my favorite stories exists because of a volcano. If there ever was an episode of "Connections" that I could get in to, it'd be about this.</comment>


Tail Call Amputation - <AUTHOR> http://www.tbray.org/ongoing/When/200x/2009/10/27/Recur <comment><USER2> For immediate recursion, an explicit keyword makes perfect sense, and indeed may be seen as preferable owing to gotchas around what might otherwise be interpreted as a non-tail call, such as not structuring things with accumulator(s) as necessary.

Tail call can start to work magic, though, when you use it with mutual recursion. Tail calling is not just a kosher way to write a loop just to fit in with a functional religion; it makes it possible to structure programs that have certain performance characteristics that are hard to achieve any other way.

Consider a simple interpreter of opcodes, for a simple virtual machine. A trivial interpreter could use a big switch statement, with one entry per opcode; but that wouldn't be particularly neatly structured, because you'd likely have to inline most opcode implementation bodies into the switch in order to get decent performance.

An optimization is a threaded code interpreter; scan through the program once, transforming opcodes into function pointers, where each function implements a single opcode, and proceeds to the next opcode by calling it directly. But this causes a problem in most imperative languages, without low-level hackery or an unsafe feature like gcc's computed goto: the stack will grow with every opcode interpreted, because each call grows the stack. Tail call support permits this approach in both a safe and efficient way.

I do agree, though, that even in these cases, some kind of tail call directive would be preferable, to indicate to the compiler that a tail call is expected here for algorithmic correctness, and help the programmer avoid accidentally inhibiting tail calling.

<comment><USER3> So build up a lazy seq of fns and then dorun it. There are ways and means ;-)

<comment><USER4> Building up thunks carries some overhead. In languages without TCO, virtual machines are usually written with e.g. a big switch statement with everything in one big function just because any overhead there will impact _every single operation_ that runs on the system. Not every VM needs to be fast, of course, but it's a common requirement for production versions.

</comment></comment></comment><comment><USER5> Bray says "structured goto" like it's a bad thing. He should re-read Knuth's classic paper, "Structured Programming with Goto":

[http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pd...](http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf)

This is the original source of the much-quoted "Premature optimization is the root of all evil." Unfortunately, few people read the rest of the paper. Many of Knuth's "structured goto" examples have since been added into mainstream programming languages as exceptions or various types of "break" statements, but the most interesting ones still work only as tail calls or gotos, and therefore are simply not possible in certain languages. In fact, most programmers these days would never even think of the solutions that Knuth considers most elegant, because current languages have left them with a huge conceptual blind spot.

</comment><comment><USER6> He's practically the poster boy for _Sufficiently Smart Compiler_ cheerleading, but he despises the most useful real-world example? And he's in the middle of a blog series about how awesome auto-parallelization will be? How is observable nondeterminism not a much bigger lie than TCO?

If you like Clojure's _recur_ but find its syntacticalness distasteful, and clueful compilers abhorrent, the Y Combinator is exactly what you want.

<comment><USER7> I don't know much about Tim Bray, and I don't usually read its articles. But this argument is OK.

Having a smart compiler is one thing ... but a tail-call is not a simple optimization that speeds up your software. And personally I haven't seen a "sufficiently smart compiler" that does a reasonable job ... Haskell's GHC does a pretty good job, but without having internal knowledge the results are often horrible.

When you modify your function and accidentally move the call such that it's no longer in a tail position (and this one does happen) that function may not run anymore.

Engineers relying on tail-calls end up looking at the generated bytecode/assembler to ensure that it's really a tail-call, otherwise the software crashes.

That's why a tail-call should be explicit. Because you're relying on it for the computation to complete. It's not for speed, it's for correctness, and with implicit tail-calls you are effectively trading one kind of accidental complexity for another.

<comment><USER4> Is it really that hard to tell whether or not a call is in a tail position? It's like type inference - it has a major impact on what kind of code is idiomatic, and if you know the language, you'll need to understand it. Still, TCO is a lot less complicated than pointers or all of the conceptual baggage necessary to design OO class hierarchies well.

<comment><USER8> "Is it really that hard to tell whether or not a call is in a tail position?"

It is easy to forget when you are focusing on the logic of the code, and easy to change accidentally. Clojure explicitly tells you when you are trying to recur from a non-tail position, which is rather nice, and not possible with implicit tail call optimization (how do you know if the programmer really wanted a tail call or not?).

Having the compiler catch your mistakes is always nice.

</comment></comment></comment></comment><comment><USER9> Modest agreement here.

I am a big fan of being able to get stack backtraces when I have a problem to debug. But tail call recursion silently throws away stack frames. You get great performance benefits from doing so, but I'd like an option when debugging to get at the information that has been thrown away.

During debugging I'd prefer to change recur into a function call than make an edit that kills the optimization for less obvious reasons. So far so good.

But recur is less flexible than tail call optimization. Consider for the moment a problem that you have modeled with finite state machines. Each state is a function, and a state transition is signaled by calling the next function. With tail call optimization this won't grow your stack. With recur you have no choice because you can't jump to another function.

<comment><USER10> I believe the _trampoline_ function / special form can do the mutual tail-call in clojure (<http://clojure.org/api#toc569>) :

      trampoline can be used to convert algorithms requiring
      mutual recursion without stack consumption.

but I haven't used it yet, am still fairly new to lisp / clojure, so certainly am not an expert in this field. YMMV

<comment><USER9> Good point. That is possible, albeit with a modest overhead. The overhead would be irrelevant except that state machines get used in very performance critical ways, such as inside a regular expression engine. But possibly Clojure isn't the right language if you care about performance that much.

Incidentally I'd be shocked if trampoline was a special form rather than a function. I'm not sure what type a function is (I don't use clojure nor is it installed here), but it should be possible to implement it something like this:

      (defn trampoline [f]
        (if (eq? (type f) 'function')
          (recur (f))
          f))

<comment><USER11> Indeed, Clojure's trampoline is a function:

      (defn trampoline
        ([f]
          (let [ret (f)]
            (if (fn? ret)
              (recur ret)
              ret)))
        ([f & args]
          (trampoline #(apply f args))))

</comment></comment></comment></comment><comment><USER12> First, recur is annoying because functions can have multiple arities, but you can only recur to the same arity. So

      (defn foo
        ([bar baz] ...)
        ([bar] ... (recur x y)))

would fail because you're in foo/1 when you call it which seems broken to me.

Second, not all lisps are as PC as clojure (though most try), CL lets you use 'go (goto) within a tagbody which afaic is the right thing.

<comment><USER13> Yes, that does seem broken. All the state is in the arguments, so it shouldn't matter what function you "recur" to.

I know this is a hack, but in Perl you can "goto" a function to remove the current function from the stack and replace it with the thing you goto. This seems about the same as "recur", but more flexible.

</comment></comment><comment><USER14> There does seem to be some dislike for recursion versus iteration in his writing. He doesn't seem to be bagging primarily on recursion in languages, just that he thinks TCO should possibly be explicit. Maybe there is something to that argument and maybe there isn't. I'm surprised that someone of his Math & CS background would not have more substantial arguments than these. Also, being a co-editor of the XML spec doesn't position someone well to criticize recursion/TCO.

<comment><USER15> How is his authorship of the XML spec in any way relevant to the specific line of argument in this post? For all we know he also kicks puppies every morning and prefer Sanka over your favorite coffee. If his argument is so insubstantial, you should just refute it without the ad-hominem BS.

</comment></comment><comment><USER16> I agree that recur is nice and explicit about what's happening, but what does "it just seems wrong when the semantics of two identical function invocations vary wildly as a function of whether there's an executable statement between the invocation and the function exit" even mean?

If there were additional statements after a recursive call, you couldn't do tail-call elimination, period, because you'd lose all stack information the earlier calls would need to complete. It's not like 'recur' can allow you to magically both keep the stack and perform tail-call elimination.

And how could you have 'two identical function invocations vary wildly'? The function is either tail recursive or it isn't; it either has extra statements after the recursive call or it doesn't. You can't ever invoke it both ways.

<comment><USER17> "The function is either tail recursive or it isn't; it either has extra statements after the recursive call or it doesn't. You can't ever invoke it both ways."

I think the thing here is that in, say, Scheme, the performance and actual execution semantics of your function vary wildly depending on how much you mangle your algorithm. If you twist it into a shape that ends with a recursive call, it does one thing; if you don't, it does another thing. This is why tail call is a leaky abstraction and why I generally look down on it (setting aside the fact that the most natural expression of many algorithms often involves other methods of implementation -- truly "naturally" recursive algorithms aren't all that common in my experience).

<comment><USER16> Okay, but you're still doing the twisting with recur. The only difference is that the compiler checks that recur is actually in a tail position. That's probably nice to a newcomer, sure, but once you do it a few times, it's pretty simple to tell whether you're making a tail call or not.

<comment><USER17> I addressed some of this in a comment on the reddit thread:

[http://www.reddit.com/r/programming/comments/9ye8o/tail_call...](http://www.reddit.com/r/programming/comments/9ye8o/tail_call_amputation/c0f0kcx)

<comment><USER16> You're changing the topic of conversation from 'recur' to 'tail-call elimination', but I'll bite.

I don't understand your argument. How is the decision to take advantage of tail-call elimination any less a part of an algorithm's implementation than the decision to, say, use a lazy iterator rather than read into an intermediate array? If it's not the best tool for what you're trying to do, certainly, don't use it, but there are plenty of legitimate places where it is needed, so why argue against it?

</comment></comment></comment></comment></comment><comment><USER18> He says, "I think the semantics of computer programs should be made explicit in their syntax" However, when the semantic definition specifies tail calls, when tail calls are performed is trivially lexically obvious. Either he doesn't understand the paper he cited or he was not being careful with his wording.

I don't think anyone will be able to have a constructive conversation with him about this until he both gets the paper or can precisely word his objections. I think that may be why people keep pointing him at the paper.

As an alternative to reading the paper, he could also just implement a basic ML compiler that does CPS and performs tail calls. It'd probably take him less time than it took to write that post and read all the comments he's going to get...

</comment><comment><USER19> loop-recur has its good points, but it has its limitations, too. To wit, recur is not allowed inside a catch or finally form. (At least in Clojure 1.0.0.) By extension, this precludes the use of for, dotimes, doseq, and any other macro which expands into loop-recur. Luckily, calling an external function does work, so exception recovery which happens to require a loop is possible.

</comment><comment><USER13> It's an optimization. Most optimizations don't require that the programmer annotate "I want this optimization" around the code that can be optimized. Obviously, he always wants the optimization. Tail call removal does this; it's a case that is easy for the compiler to identify and optimize. Requiring an explicit "hey, optimize this!" instruction is just confusing...

<comment><USER20> I don't think Clojure's "recur" or Scheme's tail-call elimination should really be called optimizations.

The point of optimizations, AIUI, is that the code will still run with the optimizations off--it will just run more slowly, but might be useful in other ways (easier debugging, faster compilation, a chance to confirm that there are no bugs in the compiler/interpreter itself, whatever).

But if I'm using "recur" or tail-call elimination to write loops in a recursive form, and I know that my code has to still work even if those features are turned off, then all of a sudden I have to worry about things like "how many times can I recurse in this function without exhausting the stack?"

<comment><USER13> Programming for a fixed amount of memory/stack is also an optimization.

</comment></comment></comment><comment><USER21> Common Lisp does this with labels, so it is not anything new in Clojure.</comment>


Facebook employee dies after apparent suicide at company's headquarters - <AUTHOR> https://techcrunch.com/2019/09/19/facebook-employee-dies-after-apparent-suicide-at-companys-menlo-park-headquarters/ <comment><USER2> Completely useless news article. How many people are working there? If one person has problems with their mental health that is tragic for the family, but not worth a news article.

If there were widespread issues with working climate at FB that might be worth an article. Like it was for Foxconn a couple of years ago. Given the fact that many higher educated / high income people (in my country) have left FB, I would not be too surprised if the working climate were not very positive there. But that would require a different article.</comment>


Copying objects in JavaScript - <AUTHOR> https://smalldata.tech/blog/2018/11/01/copying-objects-in-javascript <comment><USER2> I've been programming JS for a very long time and have learned to just stop trying to do a generic deep copy. Since JS is a dynamically typed language, it will always lead to issues down the road. Instead I write domain specific merge methods for whatever objects I'm merging.

        function mergeOptions(...options) {
          const result = {};

          for (const opt of options) {
            result = {
              ...result,
              ...opt
              arrayValue: [
                ...(result.arrayValue || []),
                ...(opt.arrayValue || [])
              ],
              deepObject: {
                ...result.deepObject,
                ...opt.deepObject
              }
            };
          }

          return result;
        }

Know the shape of your objects and merging deeply becomes painless and won't have edge-cases.

<comment><USER3> Another way of looking at it: if you are frequently doing complex copies, you probably want immutable types.

<comment><USER4> Im away from my usual PCs, and Im here just to say when I realized this exact same thing it all clicked for me on why to use immutable objects

</comment></comment></comment><comment> Null-Set As of version 8.0.0 node has exposed a serialization api which is compatible with structured clone. [https://nodejs.org/api/v8.html#v8_serialization_api](https://nodejs.org/api/v8.html#v8_serialization_api)

        const v8 = require('v8');
        const buf = v8.serialize({a: 'foo', b: new Date()});
        const cloned = v8.deserialize(buf);
        cloned.b.getMonth();

<comment><USER5> Have we learned nothing from Java's serialization fiasco?

<comment><USER6> I want to learn, can you elaborate?

<comment><USER7> Java's deserialization will instantiate any classes that the data tells it to, which in practice leads to myriad vulnerabilities as many classes have constructors that can be used to write files, execute shell commands, etc. Many programmers didn't realize this, and bad things happened.

This is a classic example: [https://www.cvedetails.com/cve/CVE-2015-7501/](https://www.cvedetails.com/cve/CVE-2015-7501/)

(Many more can be found under the CWE-502 "Deserialization of Untrusted Data" category)

</comment></comment></comment></comment><comment><USER8> Using structured cloning for deep copies is clever, but may or may not give you the behavior you want for SharedArrayBuffers. The copied value would be a new SAB with the same underlying data buffer, so that changes to one value will be visible to the other. That's good for most uses of structured cloning, but it's not what I would expect from a deep copy.

[https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Allocating_and_sharing_memory)

<comment><USER9> Programs that use SharedArrayBuffers are already defective, so it's no big deal.

<comment><USER10> Not true. Chrome has enabled SharedArrayBuffers again as of Chrome 68.

<comment><USER11> Desktop-only, not on Android, right?

Also, a program that only works in one browser, and only due to that browser being willing to open security holes other browsers are not willing to open, is arguably still defective. That said, that might describe a lot of things people are doing nowadays (e.g. anything that uses WebUSB).

</comment></comment></comment></comment><comment><USER9> Fundamentaly, deep-copy in Javascript is a typed operation and no "generic" deep-copy algorithm is possible--you have to know what meaning the value is supposed to have to copy it.

There's nothing inherently wrong with structured clone, but it's only for JSON-able objects with extensions for circular references and some built in value-like classes. It's also special-cased for safe transmission between Javascript domains so it has a bunch of undesirable behavior for local copies. (no dom, no functions, no symbols, no properties...)

Even primitive types can't be safely copied unless you know what they're going to be used for later, a nodejs file descriptor is just an integer but it's also a reference to an OS resource that can't be duplicated without a syscall.

<comment><USER12> > Fundamentaly, deep-copy in Javascript is a typed operation and no "generic" > deep-copy algorithm is possible--you have to know what meaning the value is > supposed to have to copy it.

Why? I see no problem if the deep-copy behaves exactly the same as the original, from the perspective of any operation in the Javascript API (except for the === operator).

<comment><USER9> Exactly the same as the original is a shallow copy.

Deep copy roughly means "If I do `dst = deepcopy(src)`, modifying anything in the world I can reach through a reference from dst should have no side effect visible through src" which is a reasonable thing to ask in some special cases (a tree of plain old javascript values, a DOM node) but not reasonable in others (a database connection object, a file descriptor, a user-id)

Like, what should a deep copy function do if it reaches a reference to the global object? or a function that closes over some references in the object being copied?

The answer is always "it depends on what the object will be used for later and what specific behavior you want"

</comment></comment></comment><comment> dan-robertson It is fundamentally very hard (impossible?) to deep copy everything in JavaScript. References cannot be escaped because they may be hidden in non- introspectable (cruicially, non cloneabel) places. Viz:

      function f(){var x = 0; return function(){return x++;};}
      var x = {foo:f()};
      print(x.foo());
      var y = {foo:f()};
      print(y.foo());
      var z = someDeepCopy(y);
      print(z.foo());
      print(x.foo());
      print(y.foo());
      print(z.foo());

If a copy were sufficiently deep then one could expect:

      0
      0
      1
      1
      1
      2

However if it were not deep one would get:

      0
      0
      1
      1
      2
      3

Even if one allows a deep copying of closures then this still might not work as an object which contains two (potentially different) functions closing over the same binding (ie particular instance of a particular variable) may be copied into two functions each closing over their own separate binding.

I think the only good solution to this is to either give up trying to do deep copies or give up immutability and stop caring about deep copies.

</comment><comment><USER13> The language really should have a true immutable type (without freezing, etc.) and deep copy method built in, with as many caveats and parameters as needed. Coroutines would be awesome as well. (Yes, I'm thinking, "How could JavaScript be more like Go or Erlang?")

And then it needs to stop adding new features for at least a couple years so the world can catch up.

<comment><USER14> I infer you don't mean to have both immutable data structures and deep copy as features to use together, since immutables don't need to be cloned.

</comment></comment><comment><USER15> var copy = JSON.parse(JSON.stringify(myObj));

Anything beyond this and you are begging for trouble because there's always context-specific gotchas.

<comment><USER16> This is presented in the linked document with the following context-specific gotchas:

> Unfortunately, this method only works when the source object contains > serializable value types and does not have any circular references. An > example of a non-serializable value type is the Date object - it is printed > in a non ISO-standard format and cannot be parsed back to its original value > :(.

<comment><USER17> That's false. If you use JSON.stringify on an object, it will call the method toJSON of each values recursively. The toJSON method of a Date returns the ISO string.

source: [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#Description) [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Date/toJSON)

<comment><USER18> But JSON.parse will leave it as a string instead of converting it back to a date, so this cloning approach doesn't work for objects containing dates.

<comment><USER17> I did not say that JSON.parse would parse the dates.

I'm saying that the article is wrong when it says that JSON.stringify does not transform Dates into ISO string.

Right after that, the article says "cannot be parsed back to its original value" when it definitely can be parsed back. JSON.parse does not do it by default but that was never his point.

<comment><USER19> > Right after that, the article says "cannot be parsed back to its original > value" when it definitely can be parsed back. JSON.parse does not do it by > default but that was never his point.

The broader point, which is entirely correct, is that you don't get back an exact copy of the object you want to clone, because the date fields don't end up being the same type.

</comment></comment></comment></comment></comment></comment><comment><USER20> Why? Why would people want to clone objects? When I have encountered this in the past it is from people who are new to the language.

My advise to any person who really believes they need a clone of an object: do some self-reflection on plan as to why you think you need a cloned object. Any other approach is more efficient and more simple in the code.

Objects are hash maps that store data.

</comment><comment><USER21> Yah that's why I use the serializable override:

someObj.toJSON = function() { return { foo: this.foo, bar: this.bar } }

It is an extra step but when using redux or something like that you have to serialize stuff anyway to store it and is especially useful for mobile react- native stuff in keeping state when phone restarts or connection fails.

</comment><comment><USER22> Another option if you can afford it is to just use immutablejs.

Or make your functions return new objects.

<comment><USER23> I would recommend immer ([https://github.com/mweststrate/immer](https://github.com/mweststrate/immer)) instead of ImmutableJS. You can work with regular JS objects, plus it plays much nicer with TypeScript.

<comment><USER24> I wrote a tiny library called fn-update for this that does composable functional updates ([https://github.com/benvan/fn- update](https://github.com/benvan/fn-update)).

Personally, I prefer not having to mutate data, even wrapped in a produce method

<comment><USER23> Having to specify the path using an array of strings would be an instant dealbreaker for me. It messes with all tooling and is bad for readability.

</comment></comment></comment></comment><comment><USER3> Granted, this is Python, but I wrote this a while back: [https://github.com/scooby/pyrsistent- mutable](https://github.com/scooby/pyrsistent-mutable)

Basically, it's an AST translator that lets you use imperative syntax against immutable types. That is, `x.a = b` becomes the clunky `x = x.set('a', b)`, and it really gets convenient when you have complex structures.

Would it be worth it to look into a babel plugin for Javascript and ImmutableJS?

</comment><comment><USER25> > objects in Javascript are simply references to a location in memory

No variables are simply references to objects. Objects aren't references - they're referents.

</comment><comment><USER26> I like the shallow copy, and never needed a deep copy. I am using JS for a few years tops, mostly React.

To me its exactly what native languages do with pointers. In some languages (like Delphi) its implicit (like JS) and some (like C) its explicit in syntax.

</comment><comment><USER27> Been using this for a while: [https://stackoverflow.com/a/44612374/663447](https://stackoverflow.com/a/44612374/663447) Best clone imo (for the correct usecases).

<comment><USER17> Don't use it with dates, it breaks them. You'll lose the data.

# var a = new Date();

# cloneDeep({ a }).a === { a }.a;

This returns false. Use JSON.stringify if you care about the content. cloneDeep might be useful if you don't care about data integrity.

<comment><USER28> JSON.stringify also breaks dates.

<comment><USER17> No it does not. It returns a ISO string. You don't lose any info. And you can parse it back with JSON.parse if you give it a reviver function. [1]

Do you want JSON.stringify to keep dates intact ? The whole point is to turn it to a string.

[1] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse#Parameters)

<comment><USER29> "It works if you provide your own additional code that loops over and fixes known problems" is not the same as "it works". It's useful, but at most it saves you a few lines of boilerplate code (and perhaps a few negligible cycles) to write your own recurser to do the same thing immediately after the transform.

> Do you want JSON.stringify to keep dates intact ? The whole point is to turn > it to a string.

There are ways to serialize data structures to strings. JSON doesn't generally do that, and it's been to its benefit as it helps keep it generic and easily usable from many languages.

That said, there are serialization tools which can correctly serialize and unserialize more complex structures, given the correct circumstances (only core constructs, or the objects in question have serialization helpers, or they are ensured to not have features that might cause problems such as references to outside data).

The point of this discussion is Javascript object cloning, not turning objects into a string. Offering up JSON and then responding to a criticism of it based on its methods as "the whole point is to turn it into a string" is somewhat ridiculous given many of the other options you're espousing JSON over don't use strings at all.

</comment></comment></comment></comment></comment><comment><USER30> Fun fact: Not even the whole of number type is safe to clone with the JSON method, because Infinity or NaN turn into null.

So one can't infer JSON-clonability from TypeScript/JavaScript types. Learned this the hard way.

</comment><comment><USER31> Premature optimizations is the root of all evil. That said, creating new objects do slow your code down, so do it only when you have a good reason to.

</comment><comment><USER32> Every single time I see a similar article on Javascript, I feel so lucky for being able to use Clojurescript instead. Seriously - Javascript platform is great. The language itself? Not so nice. Clojurescript makes so many things simply better.

</comment><comment><USER33> Never do any of this. It's not 1990 anymore, we don't copy code from random blog posts to solve problems.

</comment><comment><USER28> > x = 4

4

> y = new (x.constructor)(x)

[Number: 4]

> x.constructor

[Function: Number]

> y.constructor

[Function: Number]

> typeof x

'number'

> typeof y

'object'

> x

4

> y

[Number: 4]

Is y a clone of x?

<comment><USER34> no its boxed. take `y.valueOf()` and you've got a successful clone.

</comment></comment><comment><USER35> One of the weird, interesting parts of JS. Great article.

</comment><comment><USER36> 20 years on, and still no native object copy and merge in JS

<comment><USER37> Isn't Object.assign basically a merge?

<comment><USER38> I think the parent meant a _deep_ copy/merge—Object.assign only does a shallow merge, which is the point of the article.

<comment><USER39> What language does have a deep copy/merge operation built into the language?

<comment><USER22> Most(all?) functional programming languages.

<comment><USER38> Most functional programming languages don't make a distinction between values and references, so this is kind of a moot point since the copying/merging is never exposed to the developer.

</comment></comment></comment></comment></comment></comment><comment><USER17> That article is wrong. A date can definitely be serialized in JS. It is in fact converted to a ISO string when it is transformed into JSON, but the article says it does not. The author needs to learn about JSON.stringify and the toJSON method of built-ins.

<comment><USER40> Indeed it can, but I believe the point is that it's not round-tripable, meaning you can't parse the resulting serialized JSON back into its original form, the one that contained the Date objects.

If you could do so, JSON.stringify/parse would be a convenient way to do a deep clone.

<comment><USER41> It would be cool if there was a webpage for "Is your function ______?" with a list of things that functions can be:

\- Roundtrip-able (reversible?)

\- Pure

\- Effectful

\- Mutation-doing

\- Idempotent/Nullipotent

\- Algebraically closed over the set of its inputs

\- Et c.

Every time I hear about a new one I wish I had such a list

<comment><USER42> > \- Roundtrip-able (reversible?)

You mean injective</comment></comment></comment></comment>


Hackers say they broke Apple's Face ID. Here's why we're not convinced - <AUTHOR> https://arstechnica.com/information-technology/2017/11/hackers-say-they-broke-apples-face-id-heres-why-were-not-convinced/ <comment><USER2> _"According to a white paper Apple published earlier this month, Face ID takes additional captures over time and uses them to augment enrolled Face ID data"_

I would hope and expect that Apple only augments the training data if the face shown passes authentication => I don't think this is a valid argument.</comment>


How I became a pitchman for personal lube on Facebook - <AUTHOR> http://nbergus.com/2012/02/how-i-became-amazons-pitchman-for-a-55-gallon-drum-of-personal-lubricant-on-facebook/

<comment><USER2> this is both hilarious and terrifying</comment>


Google Acquires DoubleClick for $3.1 Billion in Cash - <AUTHOR> http://startupmeme.com/2007/04/13/google-acquires-doubleclick-for-31-billion-in-cash/ <comment><AUTHOR> I certainly don't believe that Microsoft couldn't have outbid Google, I think that DoubleClick made a lot of sense with Google because its largest client AOL is also one of the largest clients and partners of Google. Going with Microsoft would have resulted in a potential lose of AOL. So may be they used Microsoft to pump their valuation and then let Google do the rest. Poor ol Microsoft, the once powerful company, that used to erode market share and valuations of others is now being used to increase just that. May be Microsoft really is dead now.</comment>


Ask HN: Any tips for someone working from home for the first time? - <AUTHOR>

I've been working at a variety of companies over the past five years and I've always worked in-house. I've just started as the Director of Sales and Marketing for a small startup with seven employees spread across the USA; we are all freelancers.
Some stuff about me:
- I'm 26 and live in the Bay Area
- Just moved into a new apartment with lots of natural light
- I have a decent desk but my chair is not ideal. Suggestions for office chair solution would be awesome.
- I will be doing a lot of conference calls and demos with clients
- We use Asana and HipChat for internal company communication
Advice I'm looking for:
- Productivity tips
- Organizational tips
- How to separate work from real life (one of the first things I've done is set up VirtuaWin with two desktops: "Work" and "Play" to have a physical separation)
- Setting up a home office
- Tools/hacks/applications you guys use
- Taxes/deductions/how to handle being a 1099-MISC employee
And basically any other advice you guys can give out. Thanks in advance! <comment><USER2> * Define office hours for yourself. They don't have to be traditional ones, but knowing when you are 'on' and 'off' helps you stick to that. Enforcing 'not working' is as important as working.

* If you share your home, make sure that your cohabitors understand you really are working when at home. While that may sound obvious, it will help you draw a line in the sand should they ask you to be in for a delivery or repair person, etc - those things can be a real flow killer.

* Make your home office a separate room, if at all possible. If the door locks, so much the better: there will be times when a locked door will help you (either keeping others out or giving you that extra subtle indicator that stuff needs to get done).

* Have a clock on the wall - it's a cheap, simple, subtle way to increase the 'work' feel of the room you're in, plus it's a change in the depth of focus after hours of screen-distance reading.

* Take breaks, get out of the house.

* Participate in some kind of community chat (IRC, HipChat, Campfire whatever) to prevent going insane. Consider rationing your time on that chat, rather than having it as an open channel.

</comment><comment><USER3> My biggest tip was to have a "work computer" and a "personal computer". Resist the temptation to switch the work computer on when you're not working.

Otherwise you want to get a good routine; none of that making coffee for hours, or doing the laundry. During the working-day you're supposed to work.

Otherwise the single biggest thing I needed was to leave the house every day - Regardless of how much food I had at home I'd always go out to the sandwich store every day to make sure I had some away-time, and a little conversation. (Granted most evenings I'd see people, but working day-in, day-out at home "alone" contact is important.)

<comment><USER4> Rather than having two physically separate computers, just having a work "user account" on the single computer might be enough.

<comment><USER3> I worked from home for seven years, and am doing so again as a contractor after a brief stint in an office that didn't work out (less than a month).

Having two machines made sense for me, along with two phones, but as a compromise two logins would work. The appeal of two hosts is that you do have the chance to write one off, or have it be provided/maintained by your employer.

I always used a KVM so I could only physically control one host at a time, but I guess you get the same clean separation if you used different logins.

</comment></comment></comment><comment><USER5> I just started working from home in January.

My suggestions:

* A dedicated space is a nice to have. It helps separate the work/not-work relationship

* I have two computers for 3 reasons. First is work/not-work balance. Second is related but there's a clause in my employment contract that's basically "work done on company's computer is owned by work". Lastly, the company paid for the computer.

* I have a Herman Miller Embody chair though I've also used a Steelcase Leap (v1, v2) in my last job. Regardless of what anyone tells you, go sit in the chairs at a store. I found the Aeron to be uncomfortable for myself, even though everyone seems to love them.

* On setting up the office, make sure it's ergonomic. Get a monitor riser, laptop riser, footrest, or whatever else you need to avoid destroying your body while sitting all day.

* Make sure you take breaks. My last workplace used "Wellnomics" on Windows for break alerts, but it gets moderately annoying at times.

* I've been meaning to get a whiteboard for myself, just to get some doodling space. A notebook or similar would probably also be fine if you work with images or anything spacial.

</comment><comment><USER6> I've been working from my home office for the better of 12 years. Not until recently did I opt to get an actual office space elsewhere. The main problem I had was that office and home hours were blurring to much together. While I was up and working by 7:30am, my days didn't end at 5pm. And when they did, I found myself working late at night. It really began to affect my sleep and my personal life. As others mentioned, define your time at work and at home as strictly as possible. The most important thing I found was spending a considerable amount of money for the best chair you can afford. With little distractions around you, you'll find yourself sitting for longer stretches of time.

</comment><comment><USER7> It helps me to maintain a fairly inflexible work schedule along with a dedicated space free of outside distractions (ability to close door is a must). Since you don't mention having kids/spouse living with you, this will be easier. I've worked from home for the better part of almost 15 years now, both with and without kids, and I will say that kids change everything! I'm glad I learned how to work independently without kids because trying to do it with young ones around is a challenge.

I like the idea of just replicating "my desk" from my job at home and just "pretending" I'm actually at work.

</comment><comment><USER8> I actually have two boots on the same PC, one OS is for work, one OS for personal stuff. That way, all the things I install for work don't interfere after work hours (and visa versa). E-mails are loaded then separately too, so I don't get distracted. That way, I have a complete separation. I'm not sure virtual desktops would be enough for me.

</comment><comment><USER9> Here's a thread on tools from a few weeks ago: [https://news.ycombinator.com/item?id=6906979](https://news.ycombinator.com/item?id=6906979)

</comment><comment><USER10> Have a backup internet connection in mind (maybe walking to coffee shop) if possible. You'll probably be considered responsible when it goes down which will probably happen.

</comment><comment><USER11> Define you working hours and find a place where you work from.</comment>


Interview with the COO of Unity, iPhone game development platform - <AUTHOR> http://www.mobilecrunch.com/2009/08/14/interview-nicholas-francis-coo-of-unity-the-leading-iphone-game-development-platform/ <comment><USER2> I wonder what kind of ego you need to post a picture like that of yourself and keep a straight face.</comment>


iPhoneDevCamp Wraps Up (Heysan stands out) - <AUTHOR> http://www.macrumors.com/iphone/2007/07/09/iphonedevcamp-wraps-up/ <comment><USER2> I thought Heysan was the photo sharing/presentation app, no?

<comment><AUTHOR> Heysan's an IM app that used a slideshow to lure Myspace users.

<comment><USER2> Cool, I actually just tried it on my iPhone. I need to play around a bit more but this is good.

<comment><USER3> thanks! we're getting a lot of iphone users and want as much feedback as we can get. please forward your feedback to gustaf [at] heysan.com</comment></comment></comment></comment>


Refactoring – Not on the backlog - <AUTHOR> http://xprogramming.com/articles/refactoring-not-on-the-backlog/

<comment><USER2> Interesting visual analogy.</comment>


Comcast infects insecure pages with Javascipt for US customers - <AUTHOR> https://bugzilla.mozilla.org/show_bug.cgi?id=1205822 <comment><USER2> The title on the page is "Comcast is inserting Javascript into http web-pages with DPI". What's DPI stand for in that context? Assuming it's not Dots Per Inch.

<comment><USER3> My guess it is Deep Packet Inspection

</comment></comment><comment><USER4> If you look at the code, it appears to be for notifying the customer about alleged copyright infringements.

</comment><comment><USER5> This isn't new, unfortunately. I believe there were complaints about it a few months ago.</comment>


Google won't make search recommendations for "Islam is" - <AUTHOR> http://scienceblogs.com/pharyngula/2010/01/google_is_being_sensitive.php <comment><USER2> Everyone knows exactly why they don't make search recommendations, and is there really anything we can say about it that won't devolve into trolling, flaming, and deliberate misunderstanding?

<comment><USER3> I don't know what your theory is ("everyone knows exactly why"), but I'll put forth my thesis.

1) Autosuggestions are a sample of the most frequent phrases google users type in

2) This autosuggest list is analyzed statistically and a sentiment score established ranging from 0 (friendly) through 1 (hateful).

3) If the autosuggest list statistics reveal a certain characteristic (e.g. all hateful, or very controversial, etc.), then no suggestions get returned.

If I'm wrong that at least in principle this is an automatic, data-driven behavior, then I really feel sorry for the sod who is maintaining a list of what phrases aren't kosher.

<comment><AUTHOR> I think the counterexample to this theory is "Christianity is" which returns 7 negative suggestions, 1 ambiguous, 1 positive, and 1 t-shirt.

Another argument is that typing in "Islam i[letter]" where [letter] is some common consonant usually returns suggestions.

</comment></comment></comment><comment><USER4> This isn't new. They've been filtering it for years, ever since some screenshots of what happens when they don't made the rounds.

From November 2005:

[http://google.blognewschannel.com/archives/2005/11/30/does-g...](http://google.blognewschannel.com/archives/2005/11/30/does- google-suggest-racism/)

"Blacks are lazy"

"Blacks are stupid"

"Jews are evil"

"Jews are cheap"

<comment><AUTHOR> Interesting. One also can't get "whites are", "Hindus are", etc. But one can get "Christianity is", "Buddhism is", etc.

</comment></comment><comment><USER5> Interestingly, the same is not true for Islam was ("founded", "founded by", "spread by the sword") or Muhammad is ("a false prophet", "satan", "the antichrist") or was ("born and raised in", "born", "illiterate"), or Allah is ("satan", "great", "not obliged") or was (which, intriguingly, has just a single suggestion, "a moon god").

I'm actually having a hard time finding anything else that is similarly blocked. Makes you wonder what the completion list had been popping up before they blocked it, eh?

<comment><USER6> It's not that hard to find other blocked terms. Just try something that's socially sensitive or offensive. Such as 'n----rs are ' or even 'chinese are ' (note: 'swedish are ' works).

I wouldn't be very surprised if they had some sort of algorithm to generate the blacklisted terms as opposed to manually cherrypicking them. We're talking about Google here.

<comment><USER7> Google could learn a lot by analysing which suggestions are presented and how the user reacts [chooses one, presses enter as is, leaves site, types something else]. You might be able to correlate this with how useful / how hateful the suggestions are.

<comment><USER8> Except that in many of those searches, the person _is_ looking for something hateful.

</comment></comment></comment></comment><comment><USER9> I haven't seen it pointed out yet that it doesn't actually block searches for "Islam is". It only blocks recommendations. It's not like they're censoring actual results here.

What they're doing is simply disabling a minor feature for a small number of potentially inflammatory use cases at the expense of about 10 seconds of amusement for you. If this offends you, I would think it says more about you than Google.

<comment><AUTHOR> It doesn't exactly _offend_ me; I just find it interesting and potentially troubling. It's part of a trend of going out of the way to avoid offending Muslims specifically.

I fear that things like Ireland's new blasphemy law, which came into force a few days ago, are the result of this trend. (Of course, it applies to mockery of all religions; in the West at least one can hardly get a law passed outlawing just mockery of Islam.)

I just read a comment elsewhere that such a trend "incentivises outrage", which I think is exactly right.

<comment><USER10> If we only respect religions that cut off our heads, eventually those will be the religions that rule us.

<comment><USER11> My reaction to this is that people who are easily offended must have some insecurity. Where this insecurity is not justified, it reduces my respect.

<comment><AUTHOR> To be fair, religious affiliation seems unusually tightly bound to some people's sense of who they are. What's unclear to me is why certain religions have this worse than others, e.g. compare Muslim reaction to the Muhammad cartoons with Christian reaction to "Jerry Springer: The Opera".

<comment><USER12> I suspect if Jerry Springer: The Opera hd been written by a group or country that certain sects of Christianity want dead then the response would be the same.

It was groups of hardliners with their own agenda (aka not representing the religion) who, for the most part, provided the extreme reaction. The majority showed roughly the same response as to JS:TO.

</comment></comment></comment></comment></comment></comment><comment><USER13> So much for letting the algorithms rule their results. They could at least be somewhat equal about it and do the same thing about christianity and judaism, but then again, they know that nobody is going to chop someone's head off when they see that the first result for "christianity is" is "christianity is _bullshit_ ".

How long is the civilized world going submit to this insanity? When is enough, enough?

<comment><USER14> Let's hope someone at Google is reading this and gets this fixed PRONTO. It is grounds for boycotting the service IMHO.

<comment><USER6> Huh? Since when common sense, avoiding trouble and trying not to offend socially sensitive groups count as 'grounds for boycotting'?

<comment><USER14> There's apparent favoritism here, or bias against, depending how you want to look at it. If there were no filtering going on either way, I'd have no complaint.

</comment></comment></comment></comment><comment><USER15> Another reason why I Google with the Bing

[http://img.skitch.com/20100105-f2xhs1pm1bmi1wt24cng2hddyw.jp...](http://img.skitch.com/20100105-f2xhs1pm1bmi1wt24cng2hddyw.jpg)

Cause everyone knows "Islam is the light baby doll"

<comment><USER16> I would assume they put things in the list on a trial basis otherwise they wouldn't be able to respond quickly to current events.

</comment></comment><comment><USER17> This is rather disturbing. I didn't live through a dictatorial government in my country, but 30 years or so one that was ruling for about 50 years was put down. The worst thing about a dictatorship is not the censorship itself that will cut the parts that they don't want to be read from a text or a poem, it is when the author himself limits its expressiveness and freewill to the walls built by the fear of the censorship, and will instead write the version of his feelings that he thinks it will not get cut.

Google is doing the same... actively self-censoring, the worst form of censorship.

<comment><USER3> Aren't they simply withholding phrase suggestions which they deem wrong? I.e. you can still search for anything ranging from the angelic to the vile, and they probably don't censor (but of course, there's no way for an outsider to _ever_ know).

What I do wonder is whether Google, for example, actually filters out from its search results websites that are blacklisted by the Australian government, when people down under google.

<comment><USER18> If that is the case, why are they not being consistent? Why withhold suggestions only in the case of "Islam"?

<comment><USER19> They don't. They also withhold suggestions in the case of "jews are" and "white people are" and "hot teens".

</comment></comment></comment></comment><comment><USER20> If you search for "muhummad is " you get the results you are looking for.

<comment><USER21> "islam should" is decidedly accurate as well.

<comment><USER20> True.

But I would think that people at google would be thorough. Most perplexing.

</comment></comment></comment><comment><USER22> There's been a popular trend of posting screenshots from Google search recommendations over the past few months; I wouldn't be surprised if one of those shots made it to Google Headquarters (though I'm certainly surprised they didn't notice it sooner!).

Also shame on PZ Meyers for yoinking that article from atheists.org.

<comment><USER23> There's actually an entire site devoted to it, in the style of FML/IMMD/etc.: <http://autocompleteme.com/>

(Sorry if I just wasted anyone's evening!)

</comment></comment><comment><USER7> I don't think a blacklist is plausible. There are similar phrases that yield negative results such as "is Islam"

Perhaps there simply are not enough queries for "Islam is" in your region.

</comment><comment><USER24> I submit something that may be potentially useful, a guy who is going to open source out something that might be real interesting -><http://news.ycombinator.com/item?id=1032278> and I get no love and this ahem "sensationalist" blog with no proof whatsoever for the claims gets so many points - wow!

<comment><AUTHOR> It doesn't make any claims (aside from claims about the behaviour of the Google search field, which are easily verified). It asks a question. But don't feel bad - whether your submission gets voted up is half luck: either a couple of people spot it and vote it up so it becomes visible to everyone, or not.

</comment></comment><comment><USER25> "Engineers are:"

<http://dl.dropbox.com/u/147719/Picture%206.png>

</comment><comment><AUTHOR> [http://searchengineland.com/islam-is-blocked-by-google- sugge...](http://searchengineland.com/islam-is-blocked-by-google-suggest- bug-32921)

 _A [Google] spokesperson tells us: "This is a bug and we're working to fix it as quickly as we can."_

</comment><comment><USER26> I wondered if its because one word is the prefix of the other. My first attempt, "ishmael is " also suggested nothing!

Then I tried a few others; "isaac is " and "israel is " which did come up with suggestions.

Oh well.

</comment><comment><USER27> I found this pretty interesting, not sure if it still works:

<http://emerging-patterns.com/tmp/CrimsonJihad.png>

</comment><comment><USER28> Maybe it's just a bug? Haven't you found phrases which you thought were very popular and yet couldn't find Google recommendations for them?

</comment><comment><USER29> Well, try _muslim is_ for that matter.

<comment><AUTHOR> Which is grammatically questionable.

<comment><USER29> ok ok, even _muslism is_ then.

<comment><AUTHOR> Eh? My point was that you wouldn't necessarily expect them to have thought of it. They certainly won't have thought of this bizarre misspelling.

<comment><USER29> Fair enough, I am unfamiliar with the misspellings. Musli(s)m sounds perfectly normal to me as a non-native speaker of the English language, and for a bunch of other people on the internet for that matter hence the suggestions of google.

<comment><USER3> I just tried to say that out loud and find it quite a tongue twister.

</comment></comment></comment></comment></comment></comment><comment><USER30> Search engines should avoid being in the business of egging people on. That has to be one messy program/algorithm/filter. We put one together for a retail company emails and stopped 20% of the incoming mail. It was pretty funny what combos you can get.

</comment><comment><AUTHOR> Note: to replicate the stated behaviour, you might need to type in the space, e.g. "Judaism is " rather than "Judaism is".

</comment><comment><USER31> try out "Obama is"

<comment><USER32> Interesting... It's fairly difficult to find male celebrity names that do _not_ come up with "___ is an idiot".

<comment><USER33> chuck norris ...

</comment></comment></comment><comment><USER34> Top results from "Islam is *":

"Islam is both a religion and a complete way of life"

"Islam is Subverting America without Guns or Bombs"

"Islam is violent"

"Islam is spreading among Thousands black South Africans"

"Islam is spreading across Europe among descendants of Muslim immigrants" (The preceding word is "Radical")

"Islam is intolerant, militant, supports terrorism" (This is from a site discussing contrasting viewpoints of Islam)

"Islam is your birthright"

"Islam is not a barrier to democracy as is often perceived by Western nations"

<comment><USER35> Not for me. I see the behavior mentioned in the article.

<comment><USER34> No, I mean I typed it in, hit search, and copied the bolded bits.

</comment></comment></comment><comment><USER36> so, all of you who think they have algorithm to restrict suggestions...

what is the algorithm?</comment>


Study: Washing dishes mindfully can relieve stress - <AUTHOR> http://time.com/4056280/washing-dishes-stress-relief-mindfulness <comment><USER2> The mindfulness excerpt is from Zen Master Thich Nhat Hahn's _The Miracle of Mindfulness_

 _> While washing the dishes one should only be washing the dishes. This means that while washing the dishes one should be completely aware of the fact that one is washing the dishes. At first glance, that might seem a little silly. Why put so much stress on a simple thing? But that's precisely the point. The fact that I am standing there and washing is a wondrous reality. I'm being completely myself, following my breath, conscious of my presence, and conscious of my thoughts and actions. There's no way I can be tossed around mindlessly like a bottle slapped here and there on the waves._

</comment><comment><USER3> I vouch for this, this is true. Washing dishes is relaxing and calming if and only if washing dishes is not the source of your anxieties. But the act of moving rhythmically, the sensation and sound of water and seeing a dirty dishes turn shiny and clean is uplifting.

The thing is, any single task that forces a cognitive unburdening is relaxing and calming and good for you. My list:

1\. Driving long distance on open road. With or without company or music. Just love it.

2\. Watching nature programs (BBC Earth). The voice of the great David Attenborough is simply a force on its own.

3\. Doodling fonts type faces. This has been an old part time affectation of a brief affair with amateur DTP in my teens.

4\. Sitting on a playground swing (yeah you first have to fight those crazy little blighters for your turn!)

</comment><comment><USER4> There is a story of a Buddhist student (probably Zen) who asked his master what he should do since he had finished eating. The master replied "Wash your bowl." It is the simple things that make up life and have provided meaning for people for millennia. It's not surprising that these are the things we should be doing mindfully.

</comment><comment><USER5> I use it as a precursor to mindfulness. Before setting to a difficult task, I'll do the dishes and clean the kitchen really well.

</comment><comment><USER6> Really not about washing dishes but about mindfulness.</comment>


Hacking Yelp with Chrome DevTools to Find a Better Dinner Reservation - <AUTHOR> https://medium.com/@theroccob/hacking-yelp-w-chrome-devtools-to-find-a-better-dinner-reservation-2f7d8e1ecab5 <comment><USER2> Intercepting _and modifying_ packet requests in lieu of the API is likely against Yelp ToS.</comment>