3 ms·

I disliked JavaScript, but then I read JavaScript: The Good Parts, and I saw that with a bit of discipline* there's something quite pleasant underneath. It's a

I disliked JavaScript, but then I read JavaScript: The Good Parts, and I saw that with a bit of discipline* there's something quite pleasant underneath. It's a book that, rather than being focussed on telling you what not to use, instead shows you various approaches to programming with what you should use. If nothing else it'll give you food for thought and unlearn you of your worst beginner habits. Mind you, it's a dated book and ES6 added a lot to the language. *don't listen to every suggestion of Crockford though; e.g. having to hoist your variable declarations is as obnoxious an idea in JavaScript as it is in C

dmitri1981 9y ago
How is hoisting your variables obnoxious?
- TazeTSchnitzel 9y ago
  Definition and initialisation/usage get separated, which impairs code readability.
- pluma 9y ago
  It mixes implementation concerns with functional concerns. He recommends hoisting the declarations because that's how `var` scope works in JavaScript. Normally you'd want to introduce variables where they're actually used to provide context for them. A variable definition at the beginning of a function implies the variable is important to understand the general flow of the function. This can be especially misleading for temporary variables like counters which only matter within a particular loop. Additionally assigning values halfway into the function implies they had different values before, leading you to go back and check whether they were assigned anything else (and used for anything else) or just declared without a value. Of course these problems can be avoided by simply using the new let/const variables which are block scoped, but even here Crockford would likely advocated for hoisting within the same block because of the Temporal Dead Zone (i.e. a block scoped variable exists from the start of the block but referencing it before it was declared is an error).
  - cerved 9y ago
    This is in line with his philosophy to eliminate things that produce little or insignificant value but is a potential source of bugs. In this case variable hoisting. Of course you don't have to follow all his rules of what are good/bad parts, some of which feel a bit Byzantine at times, but he has a point and usually for a very good reason. Check out the JsLint Google+ page for his views on more recent additions
mattacular 9y ago
Hoisting variables is a nice practice and an easy way to enforce that variables aren't being defined in conditionals or loops and otherwise strewn about the function.
gkya 9y ago
JavaScript in and of itself is just another little DSL, if you want to do sane things it rows your boat. What creates all the trouble is what people are trying to extract out of it and the usually inexpert community around the language (little amount of actual CS people). It would've been way easier if around 2007-2010 we added a new language to the browser, and had some standards for the average JS programmer. I haven't tried Dart at all, but if Google actually shipped it in Chrome, then others would have to follow. We'd all call them evil for that, but at the end we'd have all others follow and end up with (probably) a proper language to code in for the browser (well my actual thoughts about running that sort of code is rather unpopular and negative, but I'll keep it to myself here to not annoy anybody).
epicide 9y ago
Bingo. I usually find the people that complain the loudest about JS have been burned by their own ignorance. I'll admit the learning curve for basic JS syntax can be a little high, but reading through and understanding most of Crockford's book will get you 80-90% of the way there. The rest is either ES2015 or framework-specific -- both of which build off of basic JS. A good software developer learns constantly.

dmitri1981 9y ago

How is hoisting your variables obnoxious?

TazeTSchnitzel 9y ago
Definition and initialisation/usage get separated, which impairs code readability.
pluma 9y ago
It mixes implementation concerns with functional concerns. He recommends hoisting the declarations because that's how `var` scope works in JavaScript. Normally you'd want to introduce variables where they're actually used to provide context for them. A variable definition at the beginning of a function implies the variable is important to understand the general flow of the function. This can be especially misleading for temporary variables like counters which only matter within a particular loop. Additionally assigning values halfway into the function implies they had different values before, leading you to go back and check whether they were assigned anything else (and used for anything else) or just declared without a value. Of course these problems can be avoided by simply using the new let/const variables which are block scoped, but even here Crockford would likely advocated for hoisting within the same block because of the Temporal Dead Zone (i.e. a block scoped variable exists from the start of the block but referencing it before it was declared is an error).
- cerved 9y ago
  This is in line with his philosophy to eliminate things that produce little or insignificant value but is a potential source of bugs. In this case variable hoisting. Of course you don't have to follow all his rules of what are good/bad parts, some of which feel a bit Byzantine at times, but he has a point and usually for a very good reason. Check out the JsLint Google+ page for his views on more recent additions

mattacular 9y ago

Hoisting variables is a nice practice and an easy way to enforce that variables aren't being defined in conditionals or loops and otherwise strewn about the function.

gkya 9y ago

JavaScript in and of itself is just another little DSL, if you want to do sane things it rows your boat. What creates all the trouble is what people are trying to extract out of it and the usually inexpert community around the language (little amount of actual CS people). It would've been way easier if around 2007-2010 we added a new language to the browser, and had some standards for the average JS programmer. I haven't tried Dart at all, but if Google actually shipped it in Chrome, then others would have to follow. We'd all call them evil for that, but at the end we'd have all others follow and end up with (probably) a proper language to code in for the browser (well my actual thoughts about running that sort of code is rather unpopular and negative, but I'll keep it to myself here to not annoy anybody).

epicide 9y ago

Bingo. I usually find the people that complain the loudest about JS have been burned by their own ignorance. I'll admit the learning curve for basic JS syntax can be a little high, but reading through and understanding most of Crockford's book will get you 80-90% of the way there. The rest is either ES2015 or framework-specific -- both of which build off of basic JS. A good software developer learns constantly.