Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A book series on JavaScript

github.com

Post reply on HN
Print view View original

61–70 of 111 posts

Re: A book series on JavaScript

#61

Post by mathgeek »

at-fates-hands wrote: post #52
sethetter wrote: post #34

Earlier quoted context omitted.

I think there is still a lingering mentality that you don't have to be an expert with JS to do front end work, and that's just not the case anymore.

This is such a true statement. I still remember being at a conference about 6 years ago. We were on lunch and talking shop with several other front-end developers. Of course jQuery comes up and people start asking if they should learn "vanilla" JS first before using jQuery. Still remember one developer blurting out, "Yeah, jQuery is so easy to use, you just cop/paste the code, you don't even really have to know JS. I…

> Today? No way can get away without knowing the language.

Maybe not in the word of startups and Silicon Valley, but there are tons of jobs for web developers across the world where simple jQuery knowledge will make you the best front end developer at your company.

That's not to say it's a good things. It's just a fact of life for many companies. Anyone better than that will leave before long for the greener pastures that you're referring to.

Re: A book series on JavaScript

#62

Post by callumlocke »

dang wrote: post #53

I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…

I used to have that mindset and it felt like a strength at the time, but now I see it as something that held me back from being better. Obviously it's best to stick to a high quality subset of the language in your code. But the brain doesn't run out of storage space, and having a deeper knowledge of the whole language brings context and confidence that makes you better at developing. These books have a refreshing, academic willingness to deep-dive into obscure language quirks out of pure curiosity, and the result is a fascination with the language and an understanding of why things are how they are. This means my whole approach to writing JS is now positive and creative, not resistant and resentful. Honestly, buy all of these books and read them, they're short and manageable and geeky and fascinating.

Re: A book series on JavaScript

#63

Post by [deleted] »

dang wrote: post #53

I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…

[deleted]

Re: A book series on JavaScript

#64

Post by d13 »

lacker wrote: post #47
frik wrote: post #40

Earlier quoted context omitted.

That's why I would recommend to read also "JavaScript: The Good Parts" (book, 2008) by Douglas Crockford. It covers (what is nowadays known as Javascript 1.5) and highlights the good parts of the language.

I think "JavaScript: The Good Parts" is outdated now, in particular the way it advocates handling object-oriented programming and inheritance with a "roll your own" method. It was great for its time, but especially with the advent of ES2015, modern JavaScript is going in a different direction.

Sadly, I think JS is at its best with most of ES3, a little of ES5, and drop of ES6. There's still a tiny, good (Ok... adequate) language underneath all the cruft. But unfortunately there's a lot of extra unnecessary complexity in JS that makes it easy for us to write unneccesarily complex and unreliable code.

And unfortunately, I think that because that complexity is there, programmers may feel they have to understand and use that complexity. Instead they should be actively preventing it from entering their brains and their codebase.

Re: A book series on JavaScript

#65

Post by ontouchstart »

dang wrote: post #53

I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…

Quote Alan Perils

> A language that doesn’t affect the way you think about programming is not worth knowing.

There are many different motivations behind studying a language. You can study it for a job interview, for a job requirement, or for personal enlightment.

I had my enjoyment of reading some well written JavaScript books such as the "Rhino book" (https://www.amazon.com/JavaScript-Definitive-Guide-Activate-...) and Pro JavaScript Techniques by John Resig (https://www.amazon.com/Pro-JavaScript-Techniques-John-Paxton...). They really help you think in JavaScript just like K&R helps you think in C.

Re: A book series on JavaScript

#66

Post by amasad »

dang wrote: post #53

I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…

As someone who interviewed a lot of engineers, for product engineers I prefer someone with this mindset. Not to say that deep knowledge in the language is bad, it's just the user and product-focused mindset makes them more effective. They will spend less time bikeshedding on semicolons on pull requests and generally view everything from the lens of "how is this good for the product/user?".

Now for tooling, infrastructure, and PL-focused engineers I think caring about the intricacies is important. First, because they'll be doing a lot of meta-programming to build frameworks and libraries. Second, is because to design good languages and frameworks you need to understand the ergonomics of the language and to pick the most intuitive and easy to use features.

Finally -- and this may sound like a contradiction to everything I said before -- I think that the best engineers are people who are able to jump between these two mindsets. Be able to bikeshed on the intricacies of frameworks one day and the next day -- when working on product -- to be focused on shipping while ignoring details that they have strong opinions on. A big part of this is dealing with cognitive dissonance. I can have a strong opinion on semicolons in JS but I can jump into a codebase without them and start cranking.

Re: A book series on JavaScript

#67

Post by trgn »

Secretmapper wrote: post #54
dang wrote: post #53

I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…

Funny. JS is my main language, and I personally also don't know most of the intricacies of JS, and we seem to share the same mindset. I mean, I do know common pitfalls and I can use `this`, etc., it's just that I find it's easier to avoid them entirely and leads to more readable code IMHO. In a way my JS tends to just be very scheme-like.

I find JS works well as an OO-language, and falls short as a functional one. Not only when writing it, but also when it's executing. Dumb-as-rocks object oriented JS-code tends to have a smaller memory footprint, is less crufty, and is easier to debug. Functional JS-code tends to spam the heap, difficult for the JIT to optimize, and when writing it you have none of the compile-time safety of a true functional language.

Crockford succeeded in popularizing JS, partly by stressing the Scheme-like features of the language, but I'm not convinced that's where the strengths of the language lay.

Re: A book series on JavaScript

#68

Post by dang »

ontouchstart wrote: post #65
dang wrote: post #53

I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…

Quote Alan Perils > A language that doesn’t affect the way you think about programming is not worth knowing. There are many different motivations behind studying a language. You can study it for a job interview, for a job requirement, or for personal enlightment. I had my enjoyment of reading some well written JavaScript books such as the "Rhino book" ( https://www.amazon.com/JavaScript-Definitive-Guide-Activate-...…

I agree with Perlis, but he was championing languages like APL, which offer truly different ways of thinking about programming. The arbitrary ins-and-outs of extrinsically complicated designs are another matter; learning those doesn't necessarily affect one's thinking about programming for the better. I realize that what I'm saying sounds trollish, but it's something it took me many years to figure out.

Re: A book series on JavaScript

#70

Post by spraak »

dang wrote: post #53

I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…

Glad to hear at least someone else shares my strategy
Post reply on HN