Hacker News new | past | comments | ask | show | jobs | submit login
How to Learn JavaScript (sivers.org)
157 points by victor106 on June 27, 2020 | hide | past | favorite | 70 comments



I’ve developed with JS for a few years, toying with vanilla JS (and doing some small bootcamp assignments/projects with it) but for actual projects I’ve used jQuery, Ember, React, etc. I feel like I was productive and there was little I “couldn’t” do without going too far off the rails.

I know how to do an AJAX request, delegate an event listener, and update the DOM, all with vanilla JS. I guess it’s useful knowledge if you’re going to build a library/framework or hand-tune a critical part of your app, but honestly I have no desire to get too comfortable with low-level JavaScript. There’s too much weird syntax and too many gotchas, although ES6+ has improved things a little.

Personal preferences aside, I have some experience as a programming tutor and think pushing people to learn plain JavaScript from the start is setting them up for frustration to the point that many will quit before ever becoming proficient.

Also, I learned Python before I learned JavaScript, but actually started toying with Django before I understood even a decent chunk of Python syntax. Being able to build something less trivial than “Hello World” almost right away gives positive reinforcement and encourages people to keep learning.

My advice for people starting out with any language is to ask around and see if there is a framework that is 1) popular and well-supported; 2) easy to learn; 3) will get you a lot of mileage and grow with you. In the case of JavaScript, that’s React. In the case of Python, that’s Django. I’m still fairly new to Swift, but SwiftUI seems like a great way to start out with the language.

Before people can become programmers, you have to get them interested in programming.


While I really support starting up with a framework, I wouldn't recommend React for someone starting out with JavaScript. React strongly recommends JSX for starters (from my limited experience with it) and also has a build system, that even if neatly abstracted away introduces a small delay and another additional thing to do before you're up and learning.

Personally, I feel starting out with jQuery as a perfect introduction. There are no build tools, just a simple refresh and you see all your changes.


A few years ago, jQuery would have been an excellent choice, but it’s pretty dormant now, and frameworks are moving away from imperative code towards declarative code. For learning how to build very basic apps it could work, so I suppose a person could spend a few weeks with it, but I don’t think it’s a good long-term investment.

If someone understands HTML they should be fine using JSX after a tutorial or two. The build system adds some friction, but with create-react-app you can get pretty far without having to understand much about build systems (and you even get auto-refresh).


In case someone is clicking this with hopes of learning JavaScript, I mostly agree with the author in that it's better to learn core JavaScript before you delve into any fancy libraries, or even the DOM API (although you probably should have a grasp of HTML & CSS if you intend to do front-end development).

I haven't looked into any of the resources the author has posted, but I've been compiling a list of free web books[1] for myself and friends. I highly recommend checking out either Eloquent JavaScript if you're new to programming, or MDN's Reintroduction to JavaScript or the Modern JavaScript Tutorial if you already have programming experience.

[1]https://keb.now.sh/books/#javascript


Agreed. I've worked with quiete a bunch of frontend developers on react applications (with serverside rendering) who didn't realise that in the end all it does is render HTML pages. And didn't have any or much experience with old school HTML and vanilla javascript. This only became a real problem when there were edge cases or external scripts needed to be integrated that didn't fit in the framework.


I see these kinds of comments all the time here on HN “X developer colleague of mine was really clueless about Y technology they were using” and they are so unfathomable to me. I’ve worked with bad colleagues & people who made foolish comments but usually the worst colleagues I’ve had err on the side of immensely increasing complexity. And generally everyone I’ve worked with had a basic understanding of the tech we were using or was a junior with some curiosity.

Who are these completely clueless developers? How do they get hired?


Some of them were indeed clueless. But also a bunch of them were great developers. I remember one who came from Flash and easily adopted the react.js SPA mindset without really understanding HTML/dom. For him almost never was it a practical problem, but it was interesting to see sometimes and he would have a completely different approach to the web. He for instance didn't understand at first why I wanted URL's to stay the same and meta title's to be correctly set. I don't have a principle problem with it. It's just an interesting development.


came from... Flash? so he was doing FLASH right until now?


> And didn't have any or much experience with old school HTML

A good heuristic for how good a web developer is is getting them to list every HTML element they know, including the deprecated ones like <marquee>. You would be surprised just how little elements they know, and more importantly, the semantic value of the elements. For example, knowing when to use <span> instead of <div>


Is encyclopedic knowledge of something that can be searched online a good heuristic for skill? I thought the community agreed this was not a good thing when it came to fizz-buzz type software interviews.

IMO in frontend world there are two important things: knowing how to search, and knowing how to determine which search results are useful as opposed to some Medium/blogpost fluff piece that is varying degrees of misinformed.


If you have experience with a framework, you should naturally be able to list things you commonly use.

I was recently at an interview where they just asked me to name a list of CloudFormation functions I’ve used and what did I use them for. If I listed that on my resume as something I knew, it was fair game.


@bobthepanda

It is not a good heuristic if the person has two days to prepare in that it is very gameable.

It is important to be able to develop things _quickly_ in order to keep a job. For that, knowing how to search is indeed useful. But there are certain things that it is worth keeping in L1 cache.


> But there are certain things that it is worth keeping in L1 cache.

I doubt that the laundry list of things that have gotten tossed out of W3C's HTML standards is one of them, as the grandfather comment implied.


Thanks a lot for the list of books on your site. I didn’t know about allaboutcircuits.com before. Now I do.


Eloquent JavaScript (https://eloquentjavascript.net/) is free, up-to-date and really good too


Although Eloquent JS is a great resource, I think it's best for intermediate beginners and not "beginner" beginners. It ramps up pretty quickly and can really confuse people who are just starting out.


I'm not 100% sure who's the target audience of this book, frankly. I had the opportunity to read it some time ago and, for someone new to the language/programming, it is clearly difficult to learn from after the first few chapters.


Yeah, I moderate on a forum aimed at beginner programmers undertaking a curriculum that uses JS, and they tend to find the book hard going if they attempt to work through it. I had a look at it when I was already very familiar with the language, and it definitely wasn't aimed at me. It's very nicely written (prose-wise) for a technical book (the introduction in particular is lovely), but the pacing and subject matter chosen don't really work for most people afaics


I found it confusing from the perspective of a beginner and had a feeling of discontentment as an intermediate. Though some topics were elaborately expounded but some were vague or confusing.


I'm an oldskool dev who shys away from 'the new shiny' because I've learned the basics of JS and you can get pretty far with the fundamentals, despite the allure of these rather expressive frameworks that get released every week now.

Frankly I get more joy out of writing bookmarklets, Tampermonkey/Greasemonkey scripts and customizing websites with various CSS 'userstyles'.

I also prefer SFTP and still enjoy uploading PHP scripts with SFTP and then building out some barebones CRUD app in my free time. Again, I shy away from the new shiny like GraphQL and things like Docker or Kubernetes etc.


I'm also "oldchool" in a similar vein. But. Docker, dude. Docker.

For instance, yesterday a PHP tool made the HN frontpage [1] that seemed rather interesting. Problem is, it needs PHP 7.2+ and my app runs on 5.6.* What to do? (Bear in mind, 3 weeks ago I moved from Virtual Box to Docker for local dev, and my files are now in a regular folder in my machine).

In this case, I just need to tell Docker to fetch the image and run it pointing to the same folder where my app is. Just a 1 line command.

After that, I just need to remove the Docker image and my system is as pristine as before.

I think I have itches very similar to yours (Like, I'm learning Python and all things Data Science and Machine learning related, instead of virtualenv or even *conda, I'm separating my projects using Docker), and nowadays I'm using Docker for all of'em.

[1]https://news.ycombinator.com/item?id=23654973


Keep in mind you should still use a venv with docker, this removes the need for sudo and won't conflict with the image system python if it has one.


For the longest time I thought the standard was to install stuff on Docker as root and not worry about typical permission/user idioms you'd practice on a classic box.

But now I am seeing more of this. Do you have any good links to read more about why using venv/non-root makes sense for Docker?


In my case, I think Docker voids the need for virtualenv. But a quick google search returns interesting results [1]

I do know setting up a proper user in Docker is just a couple lines away in a Dockerfile (As a matter of fact, I did that for the main app I develop).

For my other use cases, I just don't care. I'm using Docker to quickly bootstrap a Jupyter Labs environment, and I do that by sharing some confs (Like the Pip cache folder).

The caveat to this is that files I create are owned by root, but that again is just a command away for fixing (If I need it, that haven't yet).

[1] https://stackoverflow.com/questions/27017715/does-virtualenv...


Don't have a link at hand, but main reasons out of my head:

- exploits for breaking out of the container are easier to pull off if you have root access

- if the image has a system python, installing with sudo will install things in the system site-packages directory, which can cause a lot of troubles


I understand the attitude, especially because most of the new shiny things tend to put a lot of polish and either no doc or overwhelming doc, instead of allowing smooth integration with a respectable learning curve.

The only item in your list I'm not sure fits is Docker. It's not a framework or a language, it's a complex-but-not-complicated tool that makes a lot of life fairly convenient, especially at small scale. Things like Kubernetes (and Terraform and so on) only should come into the conversation when you start having bigger questions about the scale of your project and your infrastructure, and even then aren't a given. But at a single-user local scale, Docker can be incredibly convenient to do local dev, have reliable behaviour, and avoid a lot of pitfalls of your own machine's configuration. Often in just a handful of lines (a few for the dockerfile and a one-liner to start or stop the whole thing). The docs are also fairly well-written as they offer basic options and allow for a lot of granularity when it becomes needed.

Docker isn't the only tool in the world to do what it does, but it's a very user-friendly tool that offers a lot of convenience with little overhead (at least at a non-"devops team" scale).


While I admire your forward thinking in not mentioning scp, I will fault you with sftp, as it requires an OS account on every supported platform.

This is overkill for moving files.

I have leaned both towards rfc-1867 transfers when I have a web server available, and stunnel configured to launch tar xf when I don't.

I'm also about to go to production with a tftp server as a bridge to smb3. The tftp client is so elderly that it is constrained to 512-byte UDP packets - a true museum piece (running VMS).


What these discussions miss is context. Every learner comes from a different background, and background effects the learning path.

For example, my path for learning Typescript was:

- read the Typescript documentation

- read up on relatively new JS features (let, const, modules, spread operator, etc.)

- recall C-style syntax and historical baggage (return, things that are statements not expressions)

This took maybe a day or two, spread over some evenings.

This works for me because I'm a bit of a programming language nerd, so I have a very good framework on which to hang knowledge of a new language. I also teach programming and I would never use this approach with a student who is relatively new to the field. I also wouldn't use this approach for myself if I was learning a field I'm relatively new to.


For beginners, JavaScript.info is surprisingly amazing resource. I found it better than Eloquent JS.


Same here. I'm new-ish to JS and have JavaScript.info tab pinned for occasional reference. Fantastic resource.


The mind blowing resource for me was the "You don't know JS" series


JavaScript: The Definitive Guide 7th edition (2020) by David Flanagan is well worth a look for a thorough understanding of the language that includes fundamentals. Not sure if a total beginner should look at it (I got started with 5th edition and it was really useful, but I was already comfortable coding), but it does seem quite suitable for a deep dive once some basics are known.


Do you have a recommendation for learning HTML/CSS (and how it interfaces with JS) as well? JavaScript has never been a particularly hard language for me to grasp, it’s all the finicky bits of working with an actual browser that act as a deterrent for me to want to do much with browser UI. (Preferably the way to learn this would be based on standards that are generally implemented or have carve outs for how engines might behave slightly differently. I’ve wanted to do some things with Electron so I only have a single target to care about, but that barrier is still there to even begin to understand how to lay stuff out even with something like FlexBox)

EDIT: Also if you know any resources for writing high performance JS, that would be appreciate too. Not necessarily just number crunching optimizations, but also working with (potentially large) strings/Unicode. I’ve worked on something that might need to parse tens of megabytes of a simple plain text format including dates and likely (complex) Unicode characters, so making that as fast as possible is important to me. (I got it down to like 500ms for 30-40MB I’d text but I think I managed faster with a version on the JVM, with both being single threaded)


>Not necessarily just number crunching optimizations

JavaScript is not the language for that objective anyway. So, No!

It's all about I/O.


This is for a client application that is storing a bunch of plain text in a specific format, where the parsing would happen on a separate worker. If you have any advice for how to make faster JS or for how to learn HTML/CSS/JS interop with those things I’d appreciate it. Otherwise it’s not very helpful to just tell someone “JS is not for performance! No!”. As much as people dunk on JS, you CAN write performant code in it. Like there’s been some decades of work put into making it run faster or be able to make games or something in it...


This is going to be platform-specific to a degree. I'd expect there to be profiling tools around V8 and Spidermonkey that can help you figure out what the interpreter makes of your code, and potentially guides on what patterns to avoid. With JITed interpreters, these things can surprisingly specific.


I guess that sentence got a bit too imperative.

Regarding games, it uses subset of OpenGL API. You can use that to crunch numbers actually.

Anyways you'll have to use some external API/FFI for your job.


Seconded! After years of ignoring Javascript, I'm relieved at how this book brings it all together - explains the whole language, modules, and puts the ugly/avoidable bits of language history in context.

I agree it's only a book you'd want to learn from if you already know another language - it's a terse, conceptual ground-up description.


I'd like to add a couple of resources that I've found useful -

1. All courses by Will Sentance on Frontend Masters

2. Eloquent JavaScript


I would suggest considering many other books in addition to “the” book recommended by the author, such as Eloquent JavaScript. In fact, reading multiple books will offer multiple perspectives on the language, and result in a richer understanding.

I would also suggest having an actual project in mind while learning. It can be something very simple to start, such as creating the game Tic Tac Toe. But that will force you to apply what you are learning. In other words, try writing and maybe even rewriting the project based on what you learn.


They don't justify any of this advice that goes against the prevailing wisdom of "just build something". Beyond some book recommendations this isn't very useful.


If your goal is to learn something deeply and not just get something out the door, I don’t believe “just build something” is not the prevailing wisdom.

Building something is a part of how you reinforce what you've learned from actual material like books, documentation and others research. You still need to know some of the basic building blocks to get started.


Agreed. There's not much that will bake freshly learned theory into your brain more than realising just how far it could have taken you in hindsight. Over time, this starts to develop into foresight.


Just build something is not prevailing wisdom and most people don't learn that way.

It is non answer we give when we have no idea how to answer.


I personally prefer learning programming languages by making a project/program with it, it's a far more practical and interesting way of learning new programming language.

I realize it's probably not the best way to learn, there's the chance of not learning a simpler or better method. But I personally just don't have the attention span to read through books or take online courses.


I think it is perfectly fine when it works for you. Also advice for programmer is different then one for newbie.

One big issue with "just do something" is that people are unable to come up with suitable "something". So they don't even start. Building "something" is motivating for some people, but definitely not for all or majority.

Also, people who never coded are pretty much guaranteed to drown in own mess if they attempt to do "something". They will end up with tangled spaghetti they will be unable to make work and they will not know what their issue is.


I agree with the advice to read a few books and solve problems using core language and avoiding non-standard libraries and especially frameworks. This is important. But what much more important to me (and is often missing in this "how to learn language X") is fitting the advice to whether this is a first programming language to learn or not.

If it is the first, a lot of hand-holding makes sense; reviews of good code, exercises to solve a simple problem three different ways, etc. This also helps avoid learning really bad patterns that take years to unlearn. In fact, if JS is the first language I would recommend stopping and doing something else first. Python, C, Go or Kotlin are all better in my view as a standard tools to learn the basics of statements, flow control and data types.

Those already comfortable with programming will pick the basics of JS in a couple of sittings. What they need is a set of problems, both simple and more complex, that highlight the language strengths: wowing the reader with what the language makes possible with a few pages of code. Add some hints and let experienced developer explore.

Everyone is different, but this works best for me. My 2c.


I'm quite impressed with Haxe in that regard: a manual[1] that goes through the language and explains how it works and [at least some of] the reasoning behind why it works that way. Rest of the tutorials/docs on the Haxe site are maybe a bit ho him, but that was excellent: aimed at an experienced audience, very readable and informative. Many languages have something similar, but none I can think of have anything quite as useful.

1. https://haxe.org/manual/introduction.html


Do you happen to have pointers so a set of such problems?


I do not have a well-organized one, especially specific to JS. I have my favorite set that I personally like over the years. I think at least a couple are from "The Practice of Programming" by Kernighan and Pike; I especially like the Markov-style text generator -- their well-written solution for the same problem in Java, C++, Perl and Awk provides a good perspective, too. Since my background is in math I like prime decompositions, Lissajous curves, drawing fractals, building mazes. But those are just personal preferences suitable to many general-purpose languages.


Not OP but I found his sentiments to match mine when I worked through Learn Rust With Entirely Too Many Linked Lists (https://rust-unofficial.github.io/too-many-lists/).


1. Learn to read MDN and when you have a problem, don’t tell me you searched Google and searched StackOverflow And still can’t find the answer.


For the most advanced (well explained) Javascript and all the way to Typescript and beyond, get a FrontEnd Masters subscription for a few months. Top notch teachers in all manner of content and Kyle Simpson will lay it out well in his many videos (among other great teachers like Will Sentance). The SessionStack.com and Logrocket.com blogs cover some important concepts with modern ECMAscript standards. Surma and Jake at Google are great and have a lot of YouTube resources to bite into. Maybe start with 'What the heck is the event loop anyway?' by Philip Roberts and then Jake Archibald's: 'In The Loop' to get a foundational understanding of what is happening. Javascript.info also a great text resource. You don't know Javascript also should be on your list. Honestly there are so many resources these days including specific YouTube creators but really it's more about your learning style and what works best for you.


> When solving a problem, everyone will point you to some pre-made solution. > But no! Not yet! Do it the hard way.

This. That is why I'm a big fan of Zed Shaw's 'learn X the hard way' method of learning


> First, it’s important to learn plain JavaScript.

> Don’t depend on a library of shortcuts. JavaScript will be around for many years, while libraries and frameworks come and go every year.

I agree with the last part but this is not necessarily a sufficent reason to not learn via a framework or library. I'd say it depends on the circumstances, what you want to achieve by learning JS and also what type of a learner you are.


> Start with the book: “Head First JavaScript Programming”.

Please don't. 6yo book doesn't worth it. Even one year is a lot for modern tech.

> Do Free Code Camp.

Agree. Crazy good chunk of exercises, also useful for React & Node.

I always recommend to get any basic video course if you learning something from zero, it helps to start fast. Avoid crazy 60+ hours all-in-one courses. Then do exercises and grab advanced books & blogs & manuals.


JavaScript is not particularly modern. Even all the supposedly new features are copied from even older languages that are more consistent and have supported those features for decades.


> > Start with the book: “Head First JavaScript Programming”.

> Please don't. 6yo book doesn't worth it. Even one year is a lot for modern tech.

I'm sorry, I know you're parroting conventional wisdom here, but have you read a book? Did you look at the table-of-contents? It looks like a great introduction to me, covering the basics that I think would be a prerequisite to learning any of the more recent language features. "Don't judge a book by its cover", as they say!


I don’t think we should share authoritative seeming advice when the first instruction is to read a 700 page book “in a couple days”. How many non JavaScript programmers could keep up or absorb anything from that pace?


is the picture at the end bait?


Yeah, I think so too. It was weird to see it there as it is associated with something else entirely different.


Don’t


Unless we want a web completely devoid of interactivity client-side, that’s not great advice.


2013


Not 2013 as it references books published in 2018. This is an update to an older article. The first comment (dated 2013) cites a reference to "Javascript: The Good Parts," which isn't even mentioned in the article. I'm not sure how many times it has been updated, but the most recent update is five days ago, according to the date stamp at the top of the article.


Some of the book recommendations seem outdated, such as Effective JavaScript, which was published in 2015, no use of any of ES6+ features. They help a lot. For modern JavaScript I'm really liking Manning Book's The Joy of JavaScript, a MEAP.


The author apparently saw comments that the article is dated 2013 and updated the date at the top of the page to 2020-06-22.


"So here’s my experience and best advice for 2020"


Which is an interesting way to start a post with dozens of comments from 2013.


I blame google




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: