Ask HN: What you wish you'd known before getting into JavaScript?
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.
108 comments
[ 4.1 ms ] story [ 181 ms ] threadThere is also a free book called Eloquent Javascript which everyone loves, but I only skimmed.
There is nothing that jumps out - native Javascript is a lot better than it used to be, so you won't find yourself absolutely needing frameworks except for Angular/React for line-of-business apps.
Don't get too hung up on prototypal inheritance either, I will get downvoted to hell for this, but no one cares. It's only asked about in interviews.
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.
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
The simpl.info site "provides simplest possible examples of HTML, CSS and JavaScript" to help get started. Good Luck!
https://simpl.info/
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.
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#
> 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.
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.
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.
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.
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.
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!
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
My personal preference is React + JSX as well. You'll be pleasantly surprised by how small the React api is.
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 can't imagine not...
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
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.
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
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:
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.
What absurdity.
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.
"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...
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.
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.
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?
undefined == null;
Does that mean I am hired? :-)
Not necessarily, but it puts you ahead of about 80% of all the other candidates in consideration.
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.
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?
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.
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.
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.
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?
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.
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 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)
Javascript Languages:
- Javascript
- Coffeescript
- Typescript
- (basically) Dart
Popular Javascript Language Additions:
- JSX
- Flow
E.g. lodash is a pure abstraction over JS, but React/Vue/Angular are much, much more.
- 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!
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.
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.
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.