Effective JavaScript

What Hacker News says

1. jkapturNov 2022
   Funny - I’m in almost the exact opposite predicament! I’ll spare you a copypasta-like reiteration of your post and just ask you for a few book recommendations on how to learn modern backend development. I also need no recommendations for data structures and such, and I’ve already read “Designing Data-Intensive Applications”. The last time I did much professional backend work, SOAP and WSDLs were all the rage, except for the cool tattooed devs who used Perl.

   To your question, I strongly believe “JavaScript the Good Parts” is of historical interest only (say, if you want to take over an application written before ~2010). I recommend “Effective JavaScript” instead.

   Show morethread
2. jkapturNov 2022
   The point I was (perhaps passive-aggressively...) making is that I disagree with your premise that frontend is small/easy and backend is large/difficult. It's a common bias, but I honestly find it pretty insulting.

   Like, I could just as easily say that on the backend there isn't a dominant language, just a lot of churn for some reason. People keep reinventing new ways to take a request, make some backend calls, wait for the results, and compose a response. It seems like best practices should have evolved by now...

   I'm reminded of the relevant Spolsky article: https://www.joelonsoftware.com/2002/12/11/lord-palmerston-on...

   "Leaky abstractions mean that we live with a hockey stick learning curve: you can learn 90% of what you use day by day with a week of learning. But the other 10% might take you a couple of years catching up. That’s where the really experienced programmers will shine over the people who say “whatever you want me to do, I can just pick up the book and learn how to do it.” If you’re building a team, it’s OK to have a lot of less experienced programmers cranking out big blocks of code using the abstract tools, but the team is not going to work if you don’t have some really experienced members to do the really hard stuff."

   Anyway, the argument's been done to death and I doubt we'll convince each other.

   That said, "the 90% day-to-day" of JS/React/Chrome devtools really is as easy as everyone says for an experienced programmer. You can use almost any resources to grok the basics.

   I'm genuinely very surprised that there's not a new edition of Effective JavaScript - it should really exist. I haven't read Effective TypeScript, but I've heard good things. I also enjoyed "CSS - The Definitive Guide" from O'Reilly, but I haven't read the latest editions.

   Show morethread
3. scandoxApr 2018
   I think if you leap straight from old JS to ES6 it might leave you with some weird gaps, especially with regard to why some things got to be the way they are. A book I found very good on this score was:

   Effective Javascript http://effectivejs.com/

   Also understanding Promises properly I think is quite important (even if you don't choose to employ them yourself) and I found this book also very useful:

   http://shop.oreilly.com/product/0636920032151.do

   Show morethread
4. ben336Jul 2017
   Mostly pre-es6, but this is my favorite "intermediate -> advanced" JavaScript book: https://www.amazon.com/Effective-JavaScript-Specific-Softwar...

   There are gaps/things that have changed since the book came out, but this is a really great resource for understanding the core JS language.

   thread
5. dagwSep 2015
   Effective JavaScript by David Herman
   thread
6. scandoxSep 2015
   Hi, my name is __________ and I'm a mediocre programmer.

   I've just kicked off the first 2 weeks of a significant project using only Javascript. This was entirely my own choice. I knew I'd have to write a lot of JS in the browser. So it made sense for me to bite the bullet and try to become as good as I could at JS. Equally I had to make a choice that I believed would work for my client in the medium-term, especially if I was not able to continue with the project at a future date.

   This is my perspective (from the intellectual gutter): Javascript is hard to read and hard to reason about. It's also hard to achieve a style that I am entirely comfortable with. It's changing very fast. You learn things on the backend that are years from being universally useable on the frontend. Also: I seem to write so many lines of code.

   That said I think I made the right choice. Ultimately the isomorphism argument is correct: at least I'm reasoning about the same kinds of things every day. I just came off 6 months of programming only Elixir and I could have used Phoenix for the backend, but I think I would have found the constant shifts in perspective very disruptive.

   Which leads me to my main point: It isn't about the language.

   After all, multi-threaded programs in a more conventional language are also very hard to reason about. Shared data is hard to reason about. Immutable data is also hard to reason about (or rather its consequences are hard to reason about). Message passing can also become hard to reason about. Pointers are hard to reason about. Functional composition starts out simple and then...you guessed it: it gets hard to reason about. Once things get to a certain level of complexity, once you get using anything to its full potential you find the place in which it's going to make your head hurt.

   And for the plodders among us the answer is: libraries and patterns. Specifically, other people's libraries and other people's patterns.

   So my recommendation to anyone that doesn't like Javascript: if you don't have to JS, don't. If you do, at least enjoy the good things:

   * Promises: One of those things you only appreciate by trying to do it the other way: http://callbackhell.com/ * ES6: a lot of great features here. Makes an Elixirite feel almost at home: destructuring(pattern matching), arrow functions, generators and iterators * Libraries: Amazing number of libraries. I have barely had to code one really smart thing myself. * JSON: Think in JSON all day - now that's nice. Serializing things to Lists, Maps, Tuples and what have you gets old.

   And also read books:

   * David Herman: Effective Javascript * Marijn Haverbeke: Eloquent Javascript * Daniel Parker: Javascript with Promises * Douglas Crockford: Javascript, The Good Parts (well actually I found this one hard to reason about :) )...

   Show morethread