Dmitry Baranovskiy: Zen of JavaScript | JSConf EU 2015 

+Hendrik W You do have a point that Javascript's more openness means it makes debugging hard. But Javascript was designed for browser and it can be disastrous user experience if we start throwing ugly exceptions on the screen. I think strong unit test coverage can amplify "fail fast" productivity

+FredJoidstersberg (Adobe) Source Code Pro i think?

+Felix Leupold Do you know how to make this old vintage styled effect? This effect of font looking washed from its ink.

+Rishav Rastogi You missed the whole point. As a javascript developer, your job is make the consumer of your api( or function or whatever you want to call it) 'care less'. Again look at the example of 'charAt' function. I don't care if I am going to run 'chartAt' function on String or NaN or Boolean or whatever. I trust that the function will not blow up on my face and will do the right thing in a given scenario. So on the contrary, to make the consumer 'care less', you have to be extra careful because now your function must handle every possible scenario. Throwing an ugly exception when input doesn't match your assumption is not acceptable anymore.

Well, I said the same thing, I get the whole point of Javascript way and charAt is only one example, rest are pretty jumbled up. I am still thinking about the "ugly" exception based on input thing but its something I can reluctantly get behind, but thats pretty much it. My broader point is that the talk is the right vein but it doesn't tell you the benefits of the using the "Javascript way" or how it is more beneficial way except for the fact that it may be consistent but that itself is so very misunderstood or defined on project to project basis that its hard to see a "standard" here.

+Rishav Rastogi John Resig had similar thoughts when working on jQuery. I can't remember where I heard/read it, but he said that he was trying to make things "just work" without errors as often as he possibly could. Nothing strange should appear in normal usage. If it's supposed to return a string no matter if the input is a number, or boolean it will convert into a string. You can see a similar thing in the jQuery constructor that accepts an array, dom element, html string, selector, or another jQuery object. It just works. So there in jQuery it might be a benefit, but the talk was about the Zen of it. You're supposed to contemplate it. :)

+spacedoohicky I am still contemplating it. May be the deeper meaning will reveal itself surely.

Rishav Rastogi Haha. Who knows. I do prefer trying to minimize errors. Sometimes it can't be done especially when calling out to some external thing like ajax, or data bases. Even those can work without errors, but that might cause some issues. Imagine if an ajax lib just returned an empty string when a resource isn't found. That would be preposterous.