Live data from Hacker News

How to Become a Great JavaScript Developer

blog.ustunozgur.com

71–80 of 171 posts

Re: How to Become a Great JavaScript Developer

#71
post #60

Earlier quoted context omitted.

For the decent developers picking up Javascript, http://learnxinyminutes.com/docs/javascript/ is hard to beat. All the basic syntax and language features in one page without trying to explain to you what a while loop does.

This made me gag, years ago: // Statements can be terminated by ; doStuff(); // ... but they don't have to be, as semicolons are automatically inserted // wherever there's a newline, except in certain cases. doStuff() // Because those cases can cause unexpected results, we'll keep on using // semicolons in this guide.

Ah, the "minify" bug: forcing people to put statement separators into a line oriented language.

Think of semicolons in JS like colons in BASIC: they let you stack multiple statements on a line. Then, go learn what the language REALLY thinks is the end of a statement, which is not "I put in a semicolon".

Too bad JS doesn't use (an explicit) backslash for line continuation, rather than guessing when a line/statement was done :-(

Re: How to Become a Great JavaScript Developer

#72
post #57

Just adding my two cents. Wanna be a good JS dev? Go play around with a lisp. Like Clojure for a month or two. Get comfortable with functional programming. Then come back to JS. So many people come from a OOP to JS and they have a bad time with it. JS is more like a lisp with C syntax than it is a traditional OO language. Learning Clojure, not only improved my JS abilities, but just my over all programming maturity.…

Indeed. Personally I'm used to think in functional ways: map, fold, function composition, immutability... I'd like to be good at Haskell but I'm always having lots of pain dealing with it, because I never see the end of the learning curve. I've found JS to be a nice middle land where I can get productive functionally without too much hassle. It's like a good friend who understands my way of thinking without being in…

If you want to make that even less verbose, try myArray.map(...).filter(...) (those methods don't have to come from underscore, they exist on the Array prototype as of ES5).

Re: How to Become a Great JavaScript Developer

#73

Missing advice: learn to program well in a few well designed programming language. JavaScript was designed in 10 days and the main reason it still exists today is incredibly strong path dependence. There's nothing wrong with wanting to become a great JavaScript developer, but one needs to become a great developer first, and JavaScript just isn't conducive to that.

I personally am so over this argument. Sure, that is roughly a fact about the time in which it was designed... but that was 20 years ago. Since then there has been a team of some of the best programmers in the world maintaining and advancing the language.

That's irrelevant; advancing the language isn't an exercise in programming language design, it's an exercise in getting everyone to support the extension and in avoiding breaking legacy code. It has almost nothing to do with the maintainer's talent as programmers or PL experts.

If you doubt this argument, consider the fact that the horrible scoping, the weak typing, the insane casting rules are still here to this day; empirically you're wrong.

Re: How to Become a Great JavaScript Developer

#75
I mentioned this elsewhere, but I thought it would make a nice "top level" comment: Learn to use (and use) JSDoc in your JS code. Having comments that generate a standardized index of your code, as well as being used by an IDE, greatly helps the comprehension of the code when you come back to it a day or two later.

Re: How to Become a Great JavaScript Developer

#76
In addition to these great points, I find it extremely helpful to spend some time reviewing the source of various open source JS frameworks.

You can learn so much from patterns and techniques others are using, but that may have not been documented in the other listed resources.

Re: How to Become a Great JavaScript Developer

#77
post #60

Earlier quoted context omitted.

This made me gag, years ago: // Statements can be terminated by ; doStuff(); // ... but they don't have to be, as semicolons are automatically inserted // wherever there's a newline, except in certain cases. doStuff() // Because those cases can cause unexpected results, we'll keep on using // semicolons in this guide.

I haven't gotten much into Javascript yet, but is there any reason I would not terminate with semicolons? Without understanding which "certain cases" won't have them inserted automatically, relying on that feels like asking for trouble.

My understanding is that the original decision was to make life easier for the programmer: if you forget, we'll put one in there for you. Myself, I'd rather be told that I made a mistake, then have it ignored, because how does the compiler know what I really wanted?

Here's a good one: http://stackoverflow.com/questions/18986144/javascript-compi...

Instead of being told there's some problem with the code, it inserts a semi-colon into an arguably ludicrous location, and then gives you a differen error.

Would probably make compiler writers' jobs easier if they just spit out errors.

Re: How to Become a Great JavaScript Developer

#78

Missing advice: learn to program well in a few well designed programming language. JavaScript was designed in 10 days and the main reason it still exists today is incredibly strong path dependence. There's nothing wrong with wanting to become a great JavaScript developer, but one needs to become a great developer first, and JavaScript just isn't conducive to that.

I personally am so over this argument. Sure, that is roughly a fact about the time in which it was designed... but that was 20 years ago. Since then there has been a team of some of the best programmers in the world maintaining and advancing the language.

Since then there has been a team of some of the best programmers in the world maintaining and advancing the language.

JavaScript engines have seen a lot of effort from some of the best compiler and JIT experts in the industry, including former Self VM architects, yes.

The language itself? I honestly can't say that. Lua is a way better ECMAScript than ECMAScript itself, and the focus should have been on trimming it down to a smaller but easily extensible core, as opposed to the feature piling that's going on.

Post reply on HN