"He has Douglas Crockford and Brendan Eich on the pro-trailing-semicolon side"
Brendan Eich, the conceiver of the language. The best placed person in understanding why the JavaScript language does what it does, and what problem a feature was trying to solve.
Douglas Crockford, the developer who took all of JavaScript and found within a clean elegant language. And then he pulled together what he considered the best bits of the language and used that subset as a starting point. http://anongallery.org/220/javascript-the-good-parts
@fat - no idea who he is, apart from being an employee of Twitter and works on Twitter Bootcamp, which is a framework for other people to use to build websites.
@izs - I think you overreach by grouping him as anti-semi-colon. Isaac is a pragmatist, he uses what suits the group of people he works with. NPM is a standalone app, a non-expert JavaScript developer doesn't need to delve into npm for it's standard usecases. So he choses a syntax he believes suits the group of people working with him. And yet, he is now the lead developer of Node.js, and he's already on record saying he won't be spending time changing Node.js into his preferred comma prefixed approach - because the existing team is already used to post fixed commas. That's what I like about Isaac - he listens to a wide range of opinions, and uses what works best for the environment he's in.
Thomas Fuchs - heard of him, he's done lots of stuff JavaScript and PHP wise. I'll give you that one. He gave us Scriptaculous, and some decent PHP resources (like PHPatterns, IIRC). He's active in Rails.
The main reason the quality of JavaScript has increased dramatically in the last 6 or 7 years has been because of a coalescing towards a JavaScript best practice. This has mainly been led by Douglas Crockford and JavaScript developers at Yahoo.
JavaScript is too flexible and too bastardised a language, leaving lots of weird and broken features. Plus, well written code isn't about being clever, it's about writing code that can be supported and maintained. Douglas has taken the best bits of JavaScript and found that to be quite an effective and useful language. With that subset he, along with the people who later became the YUI library developers wrote code in that subset.
The reason for that subset is that the language is clearer, less ambiguous, and less likely to catch a developer out. Turns out using just a subset of JavaScript's syntactic capabilities improves the quality, reliability and maintainability of code.
JS Lint was build to help developers bring their code into line with this subset of usage, and disallow perfectly valid but potentially flawed code. It favours code that is readable and quickly understandable by the non-expert developer.
JS Lint is the starting point for this improved use of JavaScript. JS Min is built, as far as I understand, with the assumption that JSLint rules are in place, so yes, it works on a subset of the language. Actually the documentation http://www.crockford.com/javascript/jsmin.html is more specific: "It is suggested that JSLint be used before using JSMin."
And I guess that's the real problem here. Not using JSLint before using JSMin. And then this argument boils down to @fat saying something along the lines of not wanting to be constrained to JSLint's subset of JavaScript. That's a call he can make, and the users of Twitter Bootcamp can then choose accordingly whether to use the toolkit (since if you are in a JSLint / JSMin using environment, it's probably best to stay away from Twitter Bootcamp.)
Perhaps what would be worthwhile is a JSLint equivalent for whatever syntax and idioms the Rails-induced subset of JavaScript uses (not just a watered down version of JSLint that JSHint is, but something that encourages what they consider to be best practice rather than merely allow it), and a minified that respects those idioms. And something in plain English for those unfortunate developers who stumble into these idioms.
What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?
I'm one of those weird npm style guys, the thing that breaks my brain is this isn't about writing clever code. it is about treating the (literally) single broken case (in the browser) as a broken case. It is about writing safe and maintainable code, by making it obvious that you are dealing with that one special case. I have written js both ways, and I find comma first/semi colon first I am hit by less syntax bugs. Thats why I do it, any other reason would be dumb.
As for crockford leading the way to sanity, the biggest problem I have with him is that instead of warning and educating he flat out forbids, and then heckles people who disagree. "with" is considered a "bad part", but it is used by literally every js template framework. He recommends closure based object construction, but in a big app that is a memory nightmare. And then there is stuff that basically treats js devs as mindless idiots. Like the "new" operator is discouraged, just in case someone forgets to use it when they want to instantiate something or the function keyword is discouraged, because it hoists.
All of those are opinions, and some are demonstrably terrible. But for some reason The Good Parts is still held up as gospel, while the community just chooses to ignore the parts of the book it doesn't like.
As for minifiers, JSMin is pretty obsolete at this point. If you are using it, as an incredibly easy win you can decrease your page load times by using uglify js, google closure compiler, or yui compressor. All of these support asi fully, but that is probably the least important reason to use them.
> @izs - I think you overreach by grouping him as anti-semi-colon [sic].
Those are your words, not mine. The "other side", as I put it, isn't necessarily anti-semicolon. To be on the other side of this particular argument, they merely have to disagree with the assertion that a semicolon at the end of the statement is a must, and not a style choice. And izs did choose that style for npm.
> Thomas Fuchs - heard of him, he's done lots of stuff JavaScript and PHP wise. I'll give you that one. He gave us Scriptaculous, and some decent PHP resources (like PHPatterns, IIRC). He's active in Rails.
There's Zepto.js too, and he was a longtime core member on the Prototype JavaScript framework. He's influential.
> The main reason the quality of JavaScript has increased dramatically in the last 6 or 7 years has been because of a coalescing towards a JavaScript best practice. This has mainly been led by Douglas Crockford and JavaScript developers at Yahoo.
I strongly disagree. The driving force was the increase in importance of the JavaScript language. He was part of that trend. He helped speed it up, but it would have happened regardless.
> JS Lint is the starting point for this improved use of JavaScript.
JS Lint is a starting point. There are other valid starting points.
> And I guess that's the real problem here. Not using JSLint before using JSMin.
But @fat isn't using jsmin. And there are great alternatives, so this is a valid choice!
> What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?
"> What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?
It would look like this: http://pragprog.com/book/tbcoffee/coffeescript
Err, that's CoffeeScript, not JavaScript. CoffeeScript gets cross-compiled into JavaScript. It isn't JavaScript in itself.
Brendan Eich, the conceiver of the language. The best placed person in understanding why the JavaScript language does what it does, and what problem a feature was trying to solve.
Douglas Crockford, the developer who took all of JavaScript and found within a clean elegant language. And then he pulled together what he considered the best bits of the language and used that subset as a starting point. http://anongallery.org/220/javascript-the-good-parts
@fat - no idea who he is, apart from being an employee of Twitter and works on Twitter Bootcamp, which is a framework for other people to use to build websites.
@izs - I think you overreach by grouping him as anti-semi-colon. Isaac is a pragmatist, he uses what suits the group of people he works with. NPM is a standalone app, a non-expert JavaScript developer doesn't need to delve into npm for it's standard usecases. So he choses a syntax he believes suits the group of people working with him. And yet, he is now the lead developer of Node.js, and he's already on record saying he won't be spending time changing Node.js into his preferred comma prefixed approach - because the existing team is already used to post fixed commas. That's what I like about Isaac - he listens to a wide range of opinions, and uses what works best for the environment he's in.
Thomas Fuchs - heard of him, he's done lots of stuff JavaScript and PHP wise. I'll give you that one. He gave us Scriptaculous, and some decent PHP resources (like PHPatterns, IIRC). He's active in Rails.
The main reason the quality of JavaScript has increased dramatically in the last 6 or 7 years has been because of a coalescing towards a JavaScript best practice. This has mainly been led by Douglas Crockford and JavaScript developers at Yahoo.
JavaScript is too flexible and too bastardised a language, leaving lots of weird and broken features. Plus, well written code isn't about being clever, it's about writing code that can be supported and maintained. Douglas has taken the best bits of JavaScript and found that to be quite an effective and useful language. With that subset he, along with the people who later became the YUI library developers wrote code in that subset.
The reason for that subset is that the language is clearer, less ambiguous, and less likely to catch a developer out. Turns out using just a subset of JavaScript's syntactic capabilities improves the quality, reliability and maintainability of code.
JS Lint was build to help developers bring their code into line with this subset of usage, and disallow perfectly valid but potentially flawed code. It favours code that is readable and quickly understandable by the non-expert developer.
JS Lint is the starting point for this improved use of JavaScript. JS Min is built, as far as I understand, with the assumption that JSLint rules are in place, so yes, it works on a subset of the language. Actually the documentation http://www.crockford.com/javascript/jsmin.html is more specific: "It is suggested that JSLint be used before using JSMin."
And I guess that's the real problem here. Not using JSLint before using JSMin. And then this argument boils down to @fat saying something along the lines of not wanting to be constrained to JSLint's subset of JavaScript. That's a call he can make, and the users of Twitter Bootcamp can then choose accordingly whether to use the toolkit (since if you are in a JSLint / JSMin using environment, it's probably best to stay away from Twitter Bootcamp.)
Perhaps what would be worthwhile is a JSLint equivalent for whatever syntax and idioms the Rails-induced subset of JavaScript uses (not just a watered down version of JSLint that JSHint is, but something that encourages what they consider to be best practice rather than merely allow it), and a minified that respects those idioms. And something in plain English for those unfortunate developers who stumble into these idioms.
What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?