Ask HN: What you wish you'd known before getting into JavaScript? | Hacker News Reader

Ask HN: What you wish you'd known before getting into JavaScript?

79 pointscryptography106 comments

I want to learn JavaScript as my next language. I have been observing JS community for some time and it seems like there is too much noise out there with dozens of frameworks and language variations (e.g. CoffeeScript, TypeScript, JSX, etc). I plan to go through Mozilla's JS docs and Vue tutorial, but not sure if it is enough to get up to speed with the modern JS ecosystem. Which resources would you recommend? Which framework should I stick with? What are some things that you wish you had known before getting into JS? Note: I am comfortable with Python (including Flask/Django), Java, HTML and CSS, so picking up JS as a language won't be a problem. Interested in your thoughts.

View on HN

I'm a senior web developer now, started with other languages. This is a bit embarrassing but here goes:

1. I wish I had known how asynchronous stuff worked before I got into JS. OR studied it in JS a bit more formally. I had a couple of months where I was confused as hell, because I didn't really understand how to do async, promises weren't really a thing you could use if you had to do older browser support back then.

2. I really wish I had studied JavaScript. I didn't, at all. I was like "Yeah front end is easy anyway, lets roll" and just got started developing. I did so many stupid things, suffered so much, and really resented the language at so many different points exclusively out of my own ignorance. Once I got my head out of my ass, and actually studied the language in depth I felt like so many things started making sense.

To conclude with 2, I remember having a distinct realization that it wasn't JavaScript that was shitty. I had been a shitty developer for having not studied it.

Anyway, if I can give some advice those two would be it, understand how asynchronous flows work, and learn the language.

Completely agree. Aside from learning the basics of the language (which if you already know any other "C like" language isn't difficult), gaining a good understanding of async flows (Promises then async/await) is absolutely key in JS and is probably the biggest hangup I see people run into.

Where I work I'm considered the JS "expert", my coworkers consist of a few older seniors that mostly do backend work that think JS is bad/confusing language, and a few juniors that really only have experience with languages they learned in school (which probably doesn't include JS). And 90% of the issues I help them with are caused by a lack of understanding of async JS -- "why is this value undefined?" or "how do I get the data out of a Promise" and for the latter telling them "well, you don't get the data out of a Promise, you would chain it with .then(data => data) to operate/use the data" is usually met with even more confused looks. Though async/await helps a ton with how they use the data from a resolved async operation, you still need to understand promises (at least a little) since it's built on top of them (e.g. in a try/catch async block the lines after the await are essentially the function that gets passed to promise.then() and the lines in the catch block being the function that gets passed to promise.catch()).

Two other things I'd like to mention (which could be under "learning the language") that I think really help with really understanding JS and being able to use it well are:

1. Understand the Event Loop[1]. Learning this will make a lot of JS's oddities make sense, and is something you should learn even before learning about async JS as it will explain how your async function actually works under the hood (i.e. the non-blocking nature of JS).

2. Closures/Scoping

[1] https://www.youtube.com/watch?v=8aGhZQkoFbQ

>2. I really wish I had studied JavaScript. I didn't, at all. I was like "Yeah front end is easy anyway, lets roll" and just got started developing. I did so many stupid things, suffered so much, and really resented the language at so many different points exclusively out of my own ignorance. Once I got my head out of my ass, and actually studied the language in depth I felt like so many things started making sense.

Based on my experience interviewing candidates with years of alleged "experience", I marvel at how many so-called professionals don't bother to learn Javascript in any depth. I've had more than a few candidates that couldn't demonstrate how to iterate through the elements of an array, for example. Or correctly give the truth value of expressions like:

  "  ";
  "";
  undefined === null;

and on and on. These, to me, are dealbreakers. If someone can't rattle them off, I'm not going to pay them the six-figure salary they claim they're worth.

I'm surprised at the amount of resentment this sentiment of mine generates here on HN, of all places, but it does.

The fact that you even need to ask those questions (about the truthiness of those variables), means the language is a dealbreaker, to me.

What absurdity.

>The fact that you even need to ask those questions (about the truthiness of those variables), means the language is a dealbreaker, to me.

What absurdity.

By "dealbreaker", do you mean that you will not take a job that requires you to write Javascript at a professional level? If so, kudos for walking your talk.

Is your comment sarcasm? I seriously can't tell.

It was not sarcasm.

If I need to test on such things does that mean I can write code like the following?

    var a = [];
    a[0] = (a[0]+"")[1];
    a[1] = (a[1]+"")[2];
    `${a[0]}${(!"" + "")[3]}${(!"" + "")[1]}${a[1]}`;

Anyone who couldn't easily read it deserves to be fired on the spot.

Nadya, I don't understand the vitriol in your reply. If you think I'm being unreasonable not hiring someone who doesn't understand those basic aspects of the Javascript language, I would be interested in hearing your reasoning. Please share it if you don't mind.

I think he is being sarcastic. That code is a nightmare and if a company has code with that cognitive overhead then they better get cleaning that mess.

I was being very heavily tongue in cheek. Your knowledge tests that people understand implicit conversions in Javascript to be able to find the equivalent boolean values.

    !!( "  ")
    !!("")
    !!(undefined === null)

You probably want to test for any falsey value though. So the interviewee understanding the ToBoolean spec [0] would be what you actually want to be testing for.

    if (!x) {
        // interviewee should be able to answer for which values of `x` this condition would run
        // this shows they understand which values are falsey and which values are truthy
    }

The knowledge being tested would be "the same" but in a different, and I feel more direct, way. I felt your test was testing their knowledge of implicit conversion and not truthy/falsey values, so I wrote purposefully confusing code that uses implicit conversion.

"If everyone can easily understand what's going on, there's no harm writing code like that!" /s

[0] http://www.ecma-international.org/ecma-262/6.0/index.html#se...

Nadya, whether or not that's the best thing to test for is beside the point. All I'm saying is that, in my view, a professional Javascript developer should know those things. And apparently, a lot of people on HN disagree with me.

>Nadya, whether or not that's the best thing to test for is beside the point.

What you test on is almost as important as how you test on it. Interviews go both ways after all. I think a majority of people aren't disagreeing that a professional should know these things - but asking them to "rattle off an answer to [question]" is looked down on. It reeks of the "reverse a binary tree" or "implement [some sorting algorithm]" type of questions.

I consider myself a Javascript professional (in so much that I am paid primarily for the Javascript work I do) and I had no issue knowing the answer to the three items listed. If I was asked to rattle them off the top of my head as some sort of Fizzbuzz Filter equivalent - I'd thank you for your time and leave the interview.

I agree people should know the answers - which (as you've pointed out) is the point you're trying to get across. But how you share that point, much like which questions you ask, is important.

I think you're reading too much into the phrase "rattle off". By that I simply meant that the interviewee should know those things well enough to answer correctly and confidently.

And it still amazes me that this position seems to be controversial here on HN. There are people who have expressed unequivocal agreement, to be sure, but a significant number seem to see that stuff as obscure arcana that a developer would not typically need to know.

I like your forward thinking! Is the following also allowed?

   `${Array(5).join("pi" * 3.14)}, ${atob("QmF0bWFu")}`

Just ran into ing atob the other day. The creator of the language admitted that it was basically a late night for him and he copied python or something.

I'd much prefer a length check than truthiness check if I wanted to test for empty strings - that way if any nulls or undefineds come through, they would show up as errors.

>I'd much prefer a length check than truthiness check if I wanted to test for empty strings - that way if any nulls or undefineds come through, they would show up as errors.

That may well be the best approach in some circumstances. But do you think I'm being unreasonable wanting to hire only someone who knows those very fundamental aspects of the Javascript language?

I don't think it is unreasonable at all. Also the code evaluates to 'nerd' that person was probably just being cheeky.

Hey, I can answer them all and even say how 3rd is different from

undefined == null;

Does that mean I am hired? :-)

>Does that mean I am hired? :-)

Not necessarily, but it puts you ahead of about 80% of all the other candidates in consideration.

You are the reason I keep a few pieces of esoteric code in my interview notebook. I'll gladly answer yours as long as you can answer mine.

> You are the reason I keep a few pieces of esoteric code in my interview notebook. I'll gladly answer yours as long as you can answer mine.

I don't see those examples as esoteric at all. Ignorance of those basic things can result in all sorts of bugs. If I'm paying someone a six-figure salary, I want them to know those things. But that's just me.

Not GP, but "esoteric" might be a less useful term than "not a great idea". I agree with what you've posted elsewhere with "knowing what you don't know" in order to check your assumptions, but that's very different than knowing the exact answers to factoids which--while useful to know about--may not be feasible to memorize in their entirety. That doesn't mean they're esoteric, just that there are a lot of them.

For example, if a candidate responded to a question like those you ask with "My hunch is that they would evaluate to $answer, but I'm not 100% sure of that: I can never remember the whole JS boolean-equivalence table, so I'd look that up to be sure. May I do so now? Also, if faced with that situation at work, I would, within reason and with testing, try to remove code that relies on rules like that--which I recognize are common, but still consider a very high-risk bug surface--in the area in which I was making changes", would you consider that an unqualified candidate? Or someone with perspective?

The rules for implicit coercion in JavaScript are rather unintuitive. When people post funny examples of JavaScript "WTF's" it is almost always surprising consequences of coercion rules. {}+[]==0 and so on.

Of course you could memorize all those rules and then use them in your in your codebase to save a few keystrokes - requiring all other developers to also memorize them of course. Alternatively, you could just avoid the mess altogether and use explicit conversions, which is also what JavaScript linters recommend. But then you will easily forget the rules since you never use them.

Therefore the questions say a lot about what forms of knowledge the workplace prioritize, so it is a valuable signal to the applicant. Knowing that the interviewer requires applicants to be able to rattle off these rules say a lot about what kind of colleagues you will get and how the company approach code.

> The rules for implicit coercion in JavaScript are rather unintuitive.

Yes. And a lot of self-described Javascript developers don't even know that. Because they've never read a book or any other document that explains those rules. And that's why they struggle, like the person in this thread to whom I originally replied, and they can't produce correct code quickly and efficiently, and they create bugs that they don't understand and can't fix, and they can't correctly understand code written by someone who actually understands those aspects of the language.

I agree that you can't memorize everything there is to know about Javascript. But if you don't know something, you have to at least know that you don't know it, so you can look up the correct information when you need it. But a lot of self-described Javascript developers don't even know what they don't know.

For example, I know that the methods String.prototype.substr and String.prototype.substring both exist and they're both used to extract substrings from a string. But I still, for some reason, unless I've used one or the other within the last day or so, I have to check the API docs to determine which one I want to use and what its parameters are. I know that I don't know what I need to know. What I will never do, is write a loop that extracts the characters I need one at a time and builds the substring from them. But I have seen where people have done that, in production code and in technical interviews. I am of the opinion (not universally shared here on HN, apparently) that that is not acceptable from a highly paid professional software developer.

And certain basic things about JS, like the ones I originally described, I think you should just know. But again, that's just me.

A huge reply after being so damningly called out? Please do keep asking those gotcha questions.

It's like the flip-side of foobar, avoid like the plague any place where all the tech questions are gotchas or obscure language features. The lead developer is probably someone you do not want to work with.

>A huge reply after being so damningly called out?

Serious question: what the hell are you talking about?

>It's like the flip-side of foobar...

WTF does that even mean?

>avoid like the plague any place where all the tech questions are gotchas or obscure language features. The lead developer is probably someone you do not want to work with.

If you consider those questions "gotchas" or "obscure language features" you don't stand a chance of working with those lead developers. Their process is designed to weed people like you out.

I think, for the book I'm writing, I can build an entire chapter around this subthread. Can I quote you by name, mattmanser?

>It's like the flip-side of foobar...

I suspect they meant FizzBuzz, but am not sure.

> If you consider those questions "gotchas" or "obscure language features" you don't stand a chance of working with those lead developers. Their process is designed to weed people like you out.

> I think, for the book I'm writing, I can build an entire chapter around this subthread. Can I quote you by name, mattmanser?

I recognize that this may not be how you meant it, but that comes off as condescending and rude. Please be polite--for our sakes on HN, and in order to attract good interview candidates! I and many of my colleagues have left offers on the table before, even without other open offers, due to impressions of similar (much worse, but on the same axis) condescension and hostility during interviews.

RTFM hits me all the time.

I was struggling with something recently. Gave up and went to eat. I was standing in line and googling around a bit and blammo in the documentation ... right there, as if it was written for me was a paragraph saying how to do the thing I kept dorking up word for word.

If I had just taken the time to read that software's instructions past page 3... but nope I didn't.

I am with you on the asynchronous part. Dev wise, I am an amateur for 30 years (this is not false modesty, I code for fun only and do not follow the correct practices), coming from a C, Perl and now Python world. A world of code which is executed line by line.

I tried JS via Vue. Oh man, it was hard initially judt because I did not realize that there is a niw concept I now call "things will happen when they happen and my code is a bunch of blocks of such stuff".

This is particularly visible in Vue where you know that your code starts with mounted() and then everything happens when something triggers it. Specifically methods and data change.

Once I realized that, JS is nice.

OTOH I never, ever managed to understand asynch code in Python (which I know much better than JS)

> What you wish you'd known before getting into JavaScript?

JavaScript is fundamentally different than Python or Java.

Learn plain JavaScript alongside learning a framework - it won't bore you too much with theory and you start right away building things

> too much noise out there with dozens of frameworks

Really, for the most part, it all boils down to React, Vue and Angular. Those are the mainstream ones, then you have hundreds or thousands of alternatives, but as a beginner, you'd better stick to the most popular ones, easier to find help and libraries.

> (e.g. CoffeeScript, TypeScript, JSX, etc)

CoffeeScript is no longer widely used. As I see it, it was mostly a good introduction to JavaScript for Ruby developers, but I haven't seen lots of CoffeeScript projects after the recent ECMAScript releases (ES6-7-8)

Watch out for outdated tutorials: after 2015 JavaScript changed a lot.

JSX is not a language variation, but rather a different way to write templates.

Avoid getting too picky with the tooling: if using Vue, just use Vue CLI. With React, just use create-react-app

Rely on a code formatter: Prettier. Also, use ESLint to make sure you start with the right foot on code best practices

Don't fall in the dogma and cargo cult traps: listen, learn, but pick your choices

Use Typescript. Use async/await. Use ES6 classes, don’t do the other class-like patterns. Oh and use ES6 features in general, like fat arrows. And don’t write “var”.

Don’t use unnecessary compile-to-js syntaxes like Coffeescript since they will just be a burden in the long run. TS and JSX is an exception, those are worth it.

Don’t write “undefined” in your code, just write “null”, and treat those values the same. Some programmers will assign different meanings to “undefined” versus “null” but usually these meanings are arbitrary and silly. In most situations you don’t even need one kind of null, let alone two.

I advise the opposite of these points. Start with es5, at least for a few days. Go through the old tutorials, especially for promises.

Make sure you understand these, in order:

1. callbacks

2. promises

3. async await

And in the mean time :

1. prototype chain

2. classes

Understand them in their old school form, first. The reason being: this fancy new async await and classes stuff is just syntactic sugar, which hides the implementation and will confuse the hell out of you. You will not in a million years understand why you can

    return someAsyncFunc();

Instead of:

    return await someAsyncFunc();

... from within an async func, unless it’s within a try { } !

But if you understand promises, and how async await is just the same stuff different smell, you’ll immediately grok it.

And god have mercy on your soul if you try to debug code with classes and methods, without knowing about the prototype chain.

JavaScript is, at its core, an incredibly simple language. But es6 introduced a lot of smoke and mirrors, which only really makes sense once you understand precisely the things they’re trying to hide. You can get by , ignoring it, but there lies endless frustration.

It shouldn’t take long to get the basics. Invest the week, and proceed to use the more powerful tools with open eyes.

(And typescript and jsx will also confuse the hell out of you if you don’t get JavaScript yet. It’s so confusing and layered; make sure you start at the bottom!)

That’d be my advice. But I’m a very “depth first search” kind of guy :)

Fully agree. Start with the old school basics.

And just a reminder. JavaScript isn't a subset of React. If you want to learn JavaScript start by writing JavaScript. Then when you get that down, layer on a framework or two.

If you want to learn JavaScript start by writing JavaScript.

This should really be like the first point of every javascript tutorial ever. Honestly.

Yeah, I agree there’s value to learning and using Promises before async/await, since you often need to think in terms of promise vales when using async.

I don’t think there’s value in teaching a beginner about the prototype chain. It’s kind of obsolete knowledge at this point. ES6 classes work great, and will be very familiar to people coming from other languages.

I mean.. if someone was a beginner in Python would you first teach them about the metaclass system? (I wouldn’t)

Except that ES6 "classes" don't have class attributes, because... they're really prototypes.

Unless you're very much supporting very legacy stuff, don't bother learning about prototypes, at least beyond "well it makes objects but unlike classes its actually a function itself" stuff.

Thank you for reply which is clear and actionable!

Isnt it too early for going ES6 only?

For learning sure, but for production I still think best to go ES5 ...

I answered this specific question with this post a few years ago, and mostly the advice holds true today.

http://fourlightyears.blogspot.com/2015/05/an-incredibly-bri...

If I could offer one single piece of advice that would save you hours, weeks and months of pain, it would be to use "create-react-app" which neatly sidesteps ALL of the pain arising from using the JavaScript toolchain. This is presuming you are going to use ReactJS.

create-react-app is a hundredfold more valuable than any other single thing to the JavaScript beginner. Maybe 200 fold.

Without create-react-app you'll rapidly sink to the 9th level of hell where the King Demon of JavaScript toolchains will torture you so unrelentingly that you'll beg for mercy and return to the safety of Python and leave your JavaScript goal to some other year.

Also, as a Python programmer, you'll want to use "lodash.get" which is the equivalent of Python's dictionary.get() function which is incredibly useful. To install it you do "yarn add lodash.get".

There's lots of ways to get variables from objects/dicts in JavaScript, and I almost always use:

  let foo = {"kingName": "edward"}
  get(foo, "kingName", null)

Thus you get a nice predictable null if there is no kingName.

Python does falesy well, JavaScript does not. In Python you rely on None alot, in JavaScript there are lots of inconsistent falsey values. Thus in Python I can do lots of code that is quite terse because it assumes a nice predictable falsey value, in JavaScript I tend to verbosely type out all my comparisons even if they are as simple as (variable === true) or (variable === false). By always consistently doing explicit comparisons (i.e. stating what I expect on both sides of the comparison) I can avoid alot of bugs arising from JavaScript's weird falsely behaviour. That's just my personal taste.

Broadly speaking I try to return null in JavaScript where I would have returned None in Python, and generally I'd rather be using lodash.get to force a null return. I prefer to avoid programming around "undefined" in JavaScript.

In Python you do alot of iterating dicts and lists. In JavaScript the equivalent is map/filter and find.

To answer the question of which framework to go with, it's a personal choice of course. I choose ReactJS over Vuejs. It strikes me that VueJS is easy to start with but that is because it lacks an overall architecture. Thus the tradeoff is that you learned it fast but maybe you'll pay for the lack of application architecture later. If you go with ReactJS you might find it harder up front to grasp the architecture, but you'll be in a good position when your application gets to the point of needing an architecture. If you are an experienced programmer then you should not be afraid to learn ReactJS. The other key difference IMO to VueJS and ReactJS is that ReactJS points in the direction of immutability with its one way data flow which I think is important. I must say my advice can be taken with a grain of salt though because I have not programmed VueJS so I'm biased.

As a Python programmer, you'll generally feel pain as you learn JavaScript because asynchronous programming pervades everything. At first I hated this but after many years of async programming I'm glad I understand it. Python is magnificently synchronous. For the Python programmer learning JavaScript I'd suggest making a real effort over time to learn all the JavaScript asynch programming techniques including callback, promises and async/await. Your head will spin but when it falls into place you'll realise the power of JavaScript's inherent async nature.

> Broadly speaking I try to return null in JavaScript where I would have returned None in Python, and generally I'd rather be using lodash.get to force a null return. I prefer to avoid programming around "undefined" in JavaScript.

Why not var kingName = foo["kingName"] || null ?

> var foo = { kingName: '' };

undefined

> foo['kingName'] || null

null

'' defaults to null is a better default than '' been different than null (so you would have 2 different nulls).

Or in other words, if you're just learning React (or JavaScript in general), do not start with Webpack. You will most likely regret it, and spend weeks trying to configure the thing.

Avoid "full stack" frameworks with JavaScript -- they are all gimmicks. This is something I wish I knew at first. Start with Node.js, because you will eventually end up using npm, Webpack and Babel if you are doing serious web development. I used learnyounode[0] to get familiar with the basics of async-first programming. Even though you have tools like async+await and Promises, I would recommend being comfortable with callbacks.

Avoid CoffeeScript and jQuery, they are obsolete. Make sure you are comfortable with Webpack (build tool) and Babel (transpiler), since they are essential in web programming today. I would go with React + JSX over Vue, because I find it to be more elegant and intuitive.

[0] https://www.npmjs.com/package/learnyounode

I like this comment. It's good to not use jQuery, but I would still recommend looking at it for a historical perspective. Browser apis take care of jQuery nowadays, but it's good to see the library because a lot of sites still run on it.

My personal preference is React + JSX as well. You'll be pleasantly surprised by how small the React api is.

Another thing I'd like to add is that if you learn JS from the ground-up, methods in jQuery and lodash can be picked up on-the-fly in a matter of minutes; they are basically just sets of util functions for javascript.

Glad I read this because my impression was that JQuery Was still popular. Doing a lot of optimizing websites and jquery is a big source of bottlenecks. Seems like most plugins and themes for WordPress call a different version of JS which I believe causes the majority of conflicts.

You can actually use Vuejs instead of jQuery for simple cases (you can't use React). https://medium.com/js-dojo/vue-js-is-easier-to-learn-than-jq...

I'm confused. Why can't you use React?

Be sure to understand the event loop. Javascript as an asynchronous language often comes back to bite beginners. Here are two great talks to help you:

https://www.youtube.com/watch?v=cCOL7MC4Pl0

https://www.youtube.com/watch?v=8aGhZQkoFbQ

Your life will be easier if you learn to use Chrome Dev tools (or the Firefox equivalent) early.

In the beginning, you don't have to worry about browser compatibility - embrace modern JS (ES6+)!

I second learning the event loop. One of the most important parts of the JS engines, though somehow missed by most commenters.

> use Chrome Dev tools

I can't imagine not...

I just want to preface this saying that most of the JavaScript I do is on the backend.

> What you wish you'd known before getting into JavaScript?

1. Start with plain JS. Before jumping picking and learning frameworks, helper libraries (like lodash) make sure you understand what the language in it's current form can do.

2. Make sure your resources are current. Like @flaviocopes says, JavaScript has changed a lot since 2015. If something seems ugly or messy check to see if a cleaner syntax has been introduced in ES6+

3. Pick a style and stick with it. JS is quite flexible in its syntax, I'd recommend using a linter from the beginning. I personally enjoy using Standard, but anything that is widely adopted will do.

I'm gonna go with a bit more unconventional advice: start small. React, Vue, Angular are massive projects with a ton of underlying libraries, patterns and concepts that you will be discouraged to learn initially.

Start using a simple framework, reading the source code, maybe even writing your own to understand how everything works. Suggestions:

https://github.com/hyperapp/hyperapp

https://github.com/choojs/choo

Also check out this redux + vanilla js exercise by a friend: http://ramonvictor.github.io/tic-tac-toe-js/

Learn ES6: https://egghead.io/courses/learn-es6-ecmascript-2015

Once you get a good grip of the language, and are comfortable writing code, you can jump into JSX, React, Vue, and later TypeScript. Enjoy!

Since ES6 JS has been attempting to satisfy two radically different models for software development: the classic Object Oriented Programming (OOP) style and a Functional Programming (FP) approach. Some frameworks are better suited to an OOP approach and others clearly expect you to use FP. Neither approach is inherently wrong -- although you will certainly find passionate folks making arguments to the contrary -- but if you mix and match approaches you will end up with an unmaintainable mess.

I dont think this has only been the case since ES6. There have been plenty of OOP approaches over the years. The 'Prototype' method alone has caused serious confusion for me for as long as I had to work with it.

I agree with you but I do think the problem has become significantly worse since ES6.

Worth noting there are still a number of ES5 projects out there and some of the ES6 changes can be more deeply understood as sugar around now-legacy ES5 concepts (async/await vs. fluent Promises and the class/object model in particular).

While I agree with the advice to be very conscious of how modern a given tutorial is, there's some value in knowing what the legacy code would look like as well. Even projects that transpile ES6 to ES5 can have gotchas that knowing ES5 helps avoid.

Re: TypeScript, etc., I'd recommend thinking of those as entirely different languages for now, and learn a little vanilla JS--same with any of the major application frameworks. JS is a great language to write more structured or domain-specific languages in, and that's what most of these frameworks effectively do.

I've been developing 3 years with JS almost exclusively. The best book out there to start is 'Secrets of the JavaScript Ninja 2nd Edition' by John Resig and Bear Bibeault.

I'd recommend you grasp the fundamental concepts of vanilla JS before jumping between React, Vue or Angular.

Vue is a complete framework, great documentation and I'd prefer it over React since is less verbose, not a big fan of JSX (the internal language to write components of React) and I'd consider it less intuitive than Vue.

This doesn't apply to newbies who don't know other languages, but since you know python and java, there are two things that got tricky for me with JS as a language.

1. Learn about execution contexts early, and how returning functions is a trick.

2. The history of JS is the history of trying to get around single threaded nature. So there are callbacks and promises and other constructs. Learn about them.

Re: 2: The history of language in general has included a lot of detours dealing with asynchronous programming. Python, which the OP mentions as familiar, has an almost even more convoluted history of asynchronous programming patterns than JS.

Both languages have settled on the async/await keywords for the most part these days, and the underlying components are relatively similar, though Python's coroutines are a little more complicated/hands-on than JS Promises.

On this subject, I highly recommend finding an environment that lets you use async/await patterns today. It makes working with Promises a lot easier/cleaner, and also makes you aware of why Promises are so great and the remaining other options such as callbacks should be wrapped with Promises then otherwise forgotten. Babel has transpilation options for it, but personally I'm strongly in favor of Typescript.

Focus on mastering the DOM and Web APIs as you learn. You could even try building a minimal, single page web application every day for the remaining 6 weeks left this summer ;)

The simpl.info site "provides simplest possible examples of HTML, CSS and JavaScript" to help get started. Good Luck!

https://simpl.info/

I would avoid frameworks but embrace transpiling and popular libraries.

es6katas.org is a nice starting point for newish es6 to look up in MDN.

After a couple years any es you are transpiling now will be usable directly on websites so you then have more of a choice in direction.

Frameworks might not be any more stable in another 2 years but adapting with them is much easier as you know more modern js.

First, you really have to use some kind of a wrapper for the DOM. Very few web development is done directly against the DOM, due to design flaws and browser incompatibilities. (Unlike Windows / Mac / ios / Android where you just use the API that the OS vendor provides, and it's usually decent.)

But, those various wrappers get outdated very fast. The UI APIs on Windows, Mac, Android, ios, ect, change very slowly.

In Javascript, whatever framework / library / pattern / ect that you use to manipulate the DOM seems to change every few years.

I think you should completely wrap your head around JavaScript's prototype chain before learning anything else. Since you are coming from Python the Javascript objects will be a bit of a shock. and regardless of the framework you choose you will have encounters with this strange Javascript inheritance (like angular 1 $scopes used it).

Personally I would recommend Vue once you're ready because you can get started with it right away. Also like others said learning webpack, npm will be really beneficial.

If I were in your shoes, I would start with vanilla ES 5 (no package manager or framework) and build a simple project. In the beginning, you want to figure out big concepts like the event loop and all the ansynchronous stuff. When you first get started, all sorts of shit is going to be undefined, so log everything to the console and pay attention to how variables go from undefined to defined.

If you can't think of an idea, try building an accurate HIIT timer with vanilla JavaScript. Have a simple backend where you can save/retrieve/edit results and build an interface for that. But, don't get bogged down in package management, Webpack, libraries or any of the other shit.

Once you're finished that, ideally, you'll be in a position where you feel in control of your variables. You'll have some understanding of how JavaScript chains together, and a sense of how things will happen under the hood. Hopefully, you'll also be good with your chosen browser and its developer tools, especially the JavaScript console. And, with some luck, you'll have enough exposure to the 'interesting' parts of JavaScript that moving to ES 6 will seem like an actual upgrade.

At that point, you should be ready to start learning slightly more modern JavaScript. Then, it would be wise to move into a framework. Currently, your three big choices are Vue, React and Angular. I have little experience with Vue, so I'll let more experienced people weigh in there. Angular seems to be getting a little less popular, though it could just be because, since they started using semver, they've seemingly released a new version every eleven minutes.

Surprised that no one has mentioned Douglas Crockford.

I would recommend his book JavaScript: The Good Parts https://books.google.com/books/about/JavaScript.html?id=PXa2...

And his Google Talk,

https://youtu.be/hQVTIJBZook

This is for plain JS.

after all the change the language specification and the various implementations have experienced, you'd still recommend a beginner to read a 10+ year old book?

One might also consider Eloquent JavaScript: http://eloquentjavascript.net/3rd_edition/

Yes, because it's a great book. Everything in the book is still relevant, closures, currying, object binding.

If you use the syntax he suggests all your code will still work.

Just because let and const mean you can avoid some problems doesn't mean you shouldn't know why we have them.

The Monads and Gonads talk [0] he gave is also great.

[0]: https://m.youtube.com/watch?v=dkZFtimgAcM#

Angular and React are two different beasts that do pretty much the exact same thing. The learning curve of React is much easier then Angular. Versions matter much more then you imagine at first. As in versions of Node, Angular, etc. Never underestimate the power of jQuery still. Sometimes you just need a short cut.

If you're coming from backend languages, perhaps you'd find it easier learning node first, then going into the front. This way you won't have to learn both the concepts of front end development and the new language all at once, you can do language first then front end paradigms

0) If you want to "get into JavaScript", don't even think about frameworks yet.

1) Read JavaScript: The Good Parts first. First.

2) Build things, don't just read. A complete industry wants to teach you only React with infinite materials.

3) If you want to read, read the official documentation on MDN, not 3rd party materials. Those become outdated quickly, also most of them are crap by default.

4) Choose a framework with low barrier (yeah, it is Vue, not React, sorry), and build something. Finish it. With the tools you chose first.

5) Stick with the framework you learnt. Always will be a better one.

6) Subscribe to related Cooperpress newsletters, and go through interesting links regularly to stay up to date.

A lot of your (my problems) would be solved if you understand what is async (as Zyst has already mentioned). This was a very very big problem for me coming off PHP (which is sequential, statement 2 gets executed after statement 1). So when I started with ajax requests, I used to put in timeouts, for loops which will wait for 1 second and see if operation completed or not and what not.

That and not declaring variables in global scope unless completely required.

Also I wish I had known to start with Vanilla JS and stick to it unless completely familiar then jump to frameworks. I started with jquery and the withdrawal was awful but heavy learning experience IMO.

Most of the confusion and frustration rises from lack of understanding of the runtime execution and not the language; in case of JS:

- execution flow and temporality of the code excecution(async, promises, etc...)

- interoperability and boundaries of JS with the DOM, styling and HTTP(WS)

This hold true for most languages; concurrency, parallelism, etc... The devil and mastery is in the learning execution environment.

The static nature of writing code to represent dynamic, living state machines presents a gap and confusion.

My advice is to learn core technologies really well; JS, DOM, HTML, CSS, HTTP(S)/WS(S). Once you do this, you’ll quickly understand and debug tomorrow’s frameworks.

If I could pick one thing that I wish I would have known, it would be the understanding of functional programming techniques. Adhering to FP principles like functional purity and composition has made my applications infinitely cleaner, more maintainable, and easier to test. My work mostly involves React, which is very well suited to functional-style programming, so if you're doing something with heavy graphics or some other application, YMMV. However for react apps or anything that returns virtual DOM nodes as a response to state change, FP is the way to go IMO.

Before? How an event loop works under the hood (select) so you understand the single threaded nature (the benefits and pitfalls). Most resources cover the effects of this pretty well, but it's always nice to understand how it works by implementing a toy project with the syscalls directly

JS is a fun, but sometimes frustrating language to learn. The async-first, functional model is eye-opening and interesting (depending on where you're coming from!). I also find it more fun to program in than most other languages for some reason. Enjoy.

> Which framework should I stick with?

When starting out it's best just using vanilla JS, otherwise you are dependent on frameworks to do the grunt work, and you will often wish a framework had a certain feature (you are best cooking up your own methods in vanilla JS). As for what frameworks to 'stick' with, I would go with something like Vue or jQuery, but more often than not you will not need them (Using Vue as an early entry to learning JS is like bringing a gun to a knife fight).

That doing your backend in JavaScript means you never get a break from JavaScript.

I didn’t know that was an issue until I had been using Node for two years. On previous projects I’d jump on a story outside my usual wheelhouse every so often for the variety. Even three or four weeks a year seemed to be enough. But now I can’t get away from it, ever. I suspect this will end up being in the calculus when I am explaining why I took a new job in a new vertical.

Make sure most of your tutorials are around the language and not specific to some frameworks.

Being able to understand the underlying language has been key to finally get a grasp on what happens under the hood with Modern Magical Frameworks.

Also, being able to understand the event-loop and how JS manages memory etc is worth getting into once you have the basics clear. I recommend understanding the internals of V8 at some-point down the line.

1) Watch this: https://www.youtube.com/watch?v=8aGhZQkoFbQ&t=1s 2) Understand how `this` binding works. 3) Understand async/promises. 4) Learn debugging tools (`debugger;`, `$0`, how to turn on/off source maps etc.) 5) You will have to learn compiltion tools (babel and webpack)

As an exercise I recommend implementing most of utility functions from lodash library according to spec. https://lodash.com/docs/ (lodash is popular utility library)

I believe every language has something to teach us so I'm not dismissing JavaScript, but why are you learning a language? The answer to that question will promote some answers to your questions. If you are just learning JavaScript to learn it you'll have a hard time getting the information you find to stick with you. Having a project to implement will give everything else you do purpose.

I wish I had known all of the objects on `console` besides `log()`. There is a way to show data in a table, timers, nesting logs, and more.

I think the original question is pretty good one. Wish more time had been spent answering it directly instead of having to wade through all the replies to prove who's is bigger (brains) and who is more right.

The message is clear to invest the time upfront to learn it. What resources do people recommend and does it make sense to focus on specific framework?

"What are some things that you wish you had known before getting into JS?"

You won't be able to program your hardware:

1. No SIMD. SIMD is becoming important for anything fast.

2. No instructions like `__builtin_ctzl` for counting the number of leading zeroes (essential if you're working with bitmasks).

3. No fast uint32_t. 32-bit integers in Javascript are much slower than 31-bit integers in Javascript because of boxing.

4. No fast uint64_t. It's nearly here, but whether (and when) it will be optimized remains to be seen. Say goodbye to fast hash functions for the next few years.

5. You won't be able to do Daniel Lemire's fast mod alternative: https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-...

6. Slow bridge to C, you can expect 20-25ns per call. This means that for things like implementing a fast hash table, you could try compensate for the lack of the above by using a native addon written in C. But even then, the calling back and forth will cancel any gains.

Basically, the hardware is moving ahead, and languages like Javascript are not keeping up.

You're going to be able to do a lot of these things in newer languages, however.

Apart from that, Javascript is a fantastic language.

Decide what you're going to do about importing and exporting code before diving in. It's a whole can of worms.

I think it is helpful to have some deeper programming language theory when learning JavaScript, so you can recognize what it is really doing behind some syntactic sugar. Specifically, first class and anonymous functions, closures, the whole event driven model.

It's actually not that bad if you stick to the basics. I'd recommend just using Webpack + Babel to start so you can use the latest JS features and get a feel for what vanilla JS is. After that pick whatever big frontend framework clicks with you.

TDD. i wish i had a clear understanding of how much easier a dynamic not-typed code became when you write your tests ( at all ) first !

( it was around 1998-2000... i guess there was no unit-testing library for JS by then )

This is easy: check out D3's architecture. It is "near functional" and tosses all the overly-complex (i.e. dangerous) parts.

And definitely read the still important "Javascript, the Good Parts".

Javascript is not just a language anymore. It's the world's most complex and complete ecosystem comprised of several languages and dozens of specialized frameworks for multiple platforms.

Javascript Languages:

- Javascript

- Coffeescript

- Typescript

- (basically) Dart

Popular Javascript Language Additions:

- JSX

- Flow

it's important to note that these specialized frameworks often are abstractions over the web API, the DOM and JS.

E.g. lodash is a pure abstraction over JS, but React/Vue/Angular are much, much more.

That I should have not spend time at all on the "ecosystem" (npm, typescript, transpilers...). It works well out-of-the-box.

I wish I'd known more about functional programming. The great bits of JavaScript are the functional bits.

If you’re reading something which suggests you use CoffeeScript, it’s probably terribly outdated.

I wish I had taken js more seriously. Read something like "you don't know js".

> I want to learn JavaScript as my next language.

Welcome!

> I have been observing JS community for some time and it seems like there is too much noise out there with dozens of frameworks and language variations (e.g. CoffeeScript, TypeScript, JSX, etc).

Yeah, this is a double edged sword. People are always looking to build the next best solution, which is great for you as a consumer, but it's also terrible for you, because decision fatigue sucks and your decisions can feel like they're outdated in months, not years. Just make an informed decision when you go out to pick something and stick to it as long as it works for you.

One thing to know is that a lot of this is caused by the challenges of trying to hit the moving target that is web browsers. My biggest piece of advice for cutting through the bullshit is to find your root problem, then pick the handful of tools that actually solve it. Don't just use something because everyone else is using it; no need for cargo cult mentality.

> I plan to go through Mozilla's JS docs and Vue tutorial, but not sure if it is enough to get up to speed with the modern JS ecosystem.

Go through the MDN JS docs, build fundamentals. Read through some library code like jQuery or a utility library like lodash to get a flavor of some interesting things that come up when building a frontend library.

> Which resources would you recommend?

Roadmapy resources:

- https://github.com/FrontendMasters/front-end-handbook-2018

- Ponyfoo has some great es6 resources as well

> Which framework should I stick with?

Find what works for you. Just try to avoid things that have so much tooling you get paralyzed looking at how it works instead of doing something interesting to you. If you start with react use create-react-app to figure out the fundamentals. I'm sure there are equivalents to create-react-app that correspond to create-<library>-app nowadays.

> What are some things that you wish you had known before getting into JS? Note: I am comfortable with Python (including Flask/Django), Java, HTML and CSS, so picking up JS as a language won't be a problem. Interested in your thoughts.

- Learn about the different environments that js is run in and how this can impact certain things like module definitions, e.g. why is there amd, umd and commonjs?

- Learn about functional programming in the context of js. It's a nice mixture between the two. Learn when to use one with the other.

- Understand the inheritance model, prototypical inheritance isn't that bad, just get it out of the way.

- Understand the runtime and event loop. This will inform you why you'll see things like callbacks, promises, generators and now async/await. Here's a fundamental breakdown of the event loop: https://2014.jsconf.eu/speakers/philip-roberts-what-the-heck...

- Learn about the browser lifecycle

- Invest in learning the chrome dev tools or ff dev tools, they're both wonderful and will save you hours

I don't see the benefit of studying the jQuery source. I'm grateful for every $-littered line of code I get to carve out of our projects

Regardless of how you feel about $-lines, we can all learn from reading project code.

For context:

- 2003, I needed to learn JS to move into a professional web developer position (from systems eng). I started with mootools/dojo/yui and jquery, when it came out in 2006.

- 2009, apps started to get very complex and hard to maintain. Or I got experienced enough to figure there'd be a better way so I started working with backbone, (some) emberjs, and (a little) angular.

- During this time, I also built a number of native javascript apps because frameworks and tooling were eating up a lot of my time. I also wanted to understand the language.

- Eventually, I found elm because I started getting interested in type systems. I _really_ liked elm but it was a hard business case to make for a team. I settled into redux/react these last few years because it gets pretty close.

- The first project I 'did in' redux/react' was actually just plain javascript. I naively implemented the react and redux api and patterns. This was _incredibly_ helpful. Not only did I quickly gain a fuller understanding of the tools I was about to use, I started to understand the muddier parts of JS: the event loop, async, hoisting, scoping, etc. I was aware of them before this, but I kinda just fiddled til things work. Afterwards, I knew what the computer was doing.

So, to answer you question 'what do I wish I'd known':

I wish I knew how much of JS is choosing a platform/toolset. I also wish I knew that that tool choice is just the start and doesn't guarentee anything. You can write a clear and easy to work codebase with JQuery. You can also make a hard as heck piece of junk in react.

I would suggest not too get hung up on it. It can be hard/impossible to choose the right tool if you don't have experience with the tooling or the problem.

So, get ready to jump around. I would get ready to pick a tool for a few months, then move onto another one. In my experience, there is not a great answer for questions like 'what is better, vue or react?' The answer is subjective, a choice that reflects personal and team preferences. You can be productive in both, so it's more about sticking to one.

JS, like every other software project, still benefits from core engineering principles: - team dynamic and trust are !important! a framework will not help if a team member feels they are not trusted/growing/learning/producing - prioritize readability, code is read more than it is written, - prioritize simplicity, break complicated stuff into small, composable pieces - with all due respect to the thousand of work hours put into webpack, it is still a pain in the butt ;)

Good luck!

Create-React-App, RxJS, Styled-Components, and Rebass are my go-to helpers.

I would reccommend [Quokka](https://quokkajs.com/) and [VSCode](https://code.visualstudio.com/) for the fastest time-to-grok

Reply on news.ycombinator.com