Ask HN: What is the best JavaScript stack for a beginner to learn? | Hacker News Reader

Ask HN: What is the best JavaScript stack for a beginner to learn?

49 pointsnielmalhotra59 comments

I'm an experienced Rails developer, and I'm helping a friend learn about javascript frameworks so he can eventually get a job (we're kinda learning together). He was considering the MEAN stack, but with the announcement of all the breaking changes in angular 2.0, I don't think it would be a good use of time to learn angular.

It would be nice if there was a Rails of javascript, but there seems to be a lot of competing technologies. Obviously, you can learn new things at a new job, but it would still be better to learn something with a lot of adoption. I'm thinking a MEEN stack (using ember instead of angular) or even using react and flux. Meteor is another choice, but I'm not sure how widely adopted it is. I think it would be best for him to pick one stack and master it well before moving on.

It's annoying because, when it comes to Rails, I know exactly what skills a beginner needs to learn. Does anyone know what the more successful js bootcamps like hack reactor teach? Or do you have any advice on a good stack for a prospective full stack js developer to learn?

View on HN

Familiarity with frameworks is useful, but knowing plain JavaScript inside out is way more valuable than being able to recite various APIs. But if your friend hasn't found the job yet, and therefore doesn't know what framework he will spend his days learning to loathe, I'd say put together a few small projects with a smattering of libraries to get a better sense of their strengths and weaknesses, what problems get solved, etc.

This is the right answer. The best stack for a JS beginner to learn is JS, HTML, and CSS. Throw in some localStorage if you need persistence. The OP is definitely coming at this from the wrong perspective (the need to pick a framework). Instead, learn the core fundamentals and perhaps the nuances of a few different libraries, before you have to pick a stack. Otherwise, you won't even know the pros/cons of the stack you've chosen.

The word "framework" should always raise flags, because it implies a coding universe that is unfriendly to external software, thus hampering composability.

Totally agree. I would go so far as to say one shouldn't use (or even pick) a framework, before having the skills to write such a framework. The benefit of a framework should be time savings; it cannot make up for lack of understanding of what the framework is doing and why. Continued use of the framework should always be weighed against the cost (unfriendliness to external software and composability).

I agree - I definitely think its worth exploring a few. A good first framework to try is Backbone.. Backbone would not be my choice if I were starting a serious new project today, but because it is small, simple, and has very approachable and well annotated source code it is an easy framework to pick up and understand deeply. I would recommend reading through and then implementing a simple example like a to-do list, and then taking an hour to read through the annotated source.

After doing a small project with backbone, other frameworks like react + flux / angular or ember will be easier to pick up, and the tradeoffs they make will be easier to understand.

Agree with learning plain JavaScript.

Then I would suggest building a project with jQuery. It has been around for years. Any seasoned JavaScript programmer will have encountered a project that was based on jQuery. It will also help you understand the motivations behind the creation of the more recent frameworks: React, Angular, etc.

My 2c: stay away from any complex framework until you have a really good understanding of the language itself. Learn the DOM APIs with all it's drawbacks and bugs, DOM events, standalone browser APIs like Canvas, Audio, etc. Write simple node apps with express and modules whose sources you can read. Start using lightweight libraries like underscore / Backbone - you'll come to understand many of the issues that plague evented architectures and DOM manipulation; then you can approach Angular / React / Ember and actually understand how each one is solving those problems.

That sounds like the most boring possible way to learn webdev. Unless they're already a programmer, those things just aren't entertaining for most people. Making sure a beginner stays entertained is probably the most important goal, because people who get bored will give up before realizing their full potential.

So if anyone's reading this and feeling bad that they don't feel like doing that, just dive in and do something fun. The longer you spend learning, the more likely you are to pick up all of those important details anyway.

I'd say there are ways to combine both approaches - develop userscripts. While you can do tricks to use other libraries, simpler userscript development is easiest with just vanilla JS. It's how I got into JS myself - I first fixed up an userscript I was using that no longer worked, and then I used that userscript as a base to start building a more complex thing. Eventually I ended up completely rewriting the thing from scratch (and I did the same for the original userscript I fixed that started it all). I've been actually thinking of giving it another rewrite one of these days, this time opting to build the thing with Browserify...

It's still [one of] the best way to acquire solid knowledge of a language (and then its frameworks). I agree that this might not be the funniest nor the quickest way, though.

But it's not that bad when you have someone behind you, helping you when really needed, and showing you what you can achieve afterwards.

Jumping into JQuery, copy/pasting snippets from google and such won't (well, not often anyway) bring novices very far. Plus, they'll have a hard time learning other frameworks if needed (new job, etc.).

That was just a suggestion for the technical path. Motivation is a different exercise, I agree that the best way to learn is to try and build something you find fun/interesting.

I teach web development and find this statement to be most true. If you cant hold people's attention they wont learn a thing.

Yep. The grandparent is good advice. This, though, is effective advice.

There should be a project euler for web devs. What better way to learn js than to do 1-day (1-hour?) projects with a clear and specific focus on one concept or one browser API?

Example of first week complexity: make a choose-your-own-adventure player from a list of {id="sec01", text:"..", links:[{'Continue':'sec02'}, ]}s.

Second week: Wrap the chrome speech API[1] to produce a "game editor" for the above format.

Third week: make a youtube playlist editor that plays a list of time intervals from youtube videos: [{'tStart':0, 'tStop':451.3, 'url':'utube/URL'}, {..}, {..}, ... ]

It's just "toys," but they're immediately useful. In general I think ''file://localhost'' development of .js is a good place to start because of the immediate feedback---it either works or it doesn't.

@nielmalhotra One thing you can tell ur friend is that everyone is a beginner with the most of the modern APIs. So by reading the docs and trying things out he's already a "research level" web dev ;)

[1] http://www.google.com/intl/en/chrome/demos/speech.html

There are some good learning resources that take the guided approach:

- http://codecombat.com

- http://www.codecademy.com/en/tracks/javascript

- http://nodeschool.io

(I haven't used any of them, but these are the ones that I've heard about)

I just went through a few of the nodeschool.io courses. They're a good starting point, but don't stand alone in my mind. You'll end up supplementing the lesson "hints" with info online, but that's also a good way to familiarize yourself with various packages.

I just wrapped up the one for Hapi.js which was slightly out of date in NPM (the source on Github does seem up-to-date).

Great advice! And I think it applies usually for every language; learn the language itself first, then start digging into frameworks when you have a good understanding.

Definitely good advice.

I'd like to add also that a simpler approach is often the best choice for experts as well. The big complex frameworks simply are not the right tool for many (perhaps even most) projects.

I've never done that because I always used a framework. Sorry, but learning the DOM is just not something I want to do and I'll never do it even though I'm a professional developer. That's why there are people who write this code for me.

Absolutely agree with you, @ricardobeat. Stay away from frameworks and simply go over a Node tutorial and build simple web apps with Express.

Ember is the Rails of JavaScript. People who like Rails tend to also like Ember -- same approach to problems, and they integrate well together.

Personally I am into React/Flux lately but that's because I like doing things at a bit lower level, with more control. Note, lower level doesn't mean better.

I have to strongly disagree with people proposing Ember. Several teams I work with, teams with very strong js and rails background, have tried it out and uniformly rejected it as being too restrictive, pointlessly baroque, monolithic, unstable, and with immature tooling (ember-cli in particular). I know a lot of people may disagree with that list but that is my experience and that of several people I respect.

I'm not saying this is the "ideal" front end stack (because that has yet to be created) but a good simple starting point IMO would be backbone + react. Very simple, flexible introduction to concepts like router, functional reactive, and components.

Also, while I get where people are coming from who recommend plain js, really learning how to do good front end development is only in part about knowing js itself. The OP would also benefit a lot from learning some high level concepts you won't get from doing vanilla js - routing and components in particular - so keep that tradeoff in mind when deciding.

The high level concepts you refer to are implemented in plain javascript. The general purpose of frameworks is to increase productivity for those who already master the language. You will have a harder time learning if you begin by using abstractions you don't understand.

Backbone and react.js is indeed an awesome combination for single-page web applications. React makes for an awesome templating layer, and makes the performance of rendering dramatically faster than using more complex Backbone views in the traditional manner. Throw in backbone-react-component to get react views that automatically update when the underlying model or collection changes and you have a damn good stack.

IMO when already learning React it's no use learning Backbone at all. Better start with Flux.

Backbone is not needed with React and although it is possible for them to be together (hell, we lived React+Backbone for almost a year), everything gets so much nicer when you can finally drop Backbone baggage.

It might be possible though that in order to see where Flux shines, one has to sweat through limitations of Backbone. That may be valuable experience.

This has not been my experience at all. Ember-cli post 0.1.0 release has been very easy to work with and has helped me and my team get started using the Ember very quickly. We now have two Ember apps and have not looked back since!

I would learn Ember. The documentation is really good and it has the same philosophy as Rails (convention over configuration). It is as close to Rails for JS as you are going to get. Ember-cli is also amazing.

For the backend I would stick with Rails. I see no benefit of moving to Node for a general application when you already know Rails.

Ember, Ember Data and Rails works incredibly well together.

What worked for me (two years in webdev):

1. Start with vanilla JavaScript/DOM and try to make a small app with that. You'll learn encapsulating DOM into some kind of DIY views, and browser APIs such as pushstate, requestAnimationFrame, etc. This is an essential step.

2. (Optional) Try a classic MVC framework, simpler is better. Backbone is very basic and might be a good idea as middle step. Refactor your simple app to use Backbone views and models. Learn the hard way about their shortcomings.

3. Learn React and Flux (any flavor). Throw Backbone away. Ditch imperative DOM updates, learn top-down data flow. Even if you don't stick with React, other frameworks (e.g. Ember) are starting to embrace top-down data flow, and it's an essential concept that simplifies webdev so much.

4. (If you really feel like it) Try some Angular. This will help you see why one-way bindings, no templates, no direct DOM manipulation and minimal API surface rock over other approaches.

5. (If you want to stay on the edge) Try exotic stuff like Cycle.js or Om (or Omniscient.JS if you don't want to leave JS land). These build up on ideas React pioneered, but one uses Observables as primitive and other uses Cursors.

I'd agree with most everyone here that plain javascript should be your first step. However, once you get past that stage I'd recommend the following:

- React: by far the most enjoyable UI tool I've used in a long time. Single-direction data flow is easy to reason about and requires very few new concepts to learn.

- Reflux: have your react components trigger events that update your data store. I find flux to be a little too complicated for my tastes. Reflux removes the need for a dispatcher and just has events and stores.

- Browserify: makes writing modular JavaScript much much easier by using node-style CommonJS imports.

- react-router: react style routes makes structuring your apps routes intuitive.

I've included these tools and more in a starter project I have on github: https://github.com/builtbybig/starter

I've enjoyed working with riot.js (https://muut.com/riotjs/). It's a "minimalist" front end framework, written in vanilla javascript. It's easy to pick up, and it's not super opinionated. You can read/absorb the library in one sitting -- so you'll have a good sense of what's going on under the hood.

Another great resource is You Might Not Need jQuery (http://youmightnotneedjquery.com/). Take what you need, leave the bloat behind!

I picked riot.js to learn javascript as it seemed to rely most heavily on solid javascript program paradigms rather than abstractions introduced by the framework. So far I'm happy, with this choice.

Javascript is more "messy" because front-end is harder (on web) than backend.

The advice of learn "vanilla javascript" break if your targets (=browsers) are older than, lets say, THIS YEAR.

So, is the interest to do only "modern javascript" aka "this year release of browsers implementation of JS"? or "javascript as understood by, please not! internet explorer 6?".

So "vanilla javascript" is different depending in how much "modern" we are talking about. With truly recent JS, is possible to avoid jquery. If you are only in the server-side, Javascript IS == NODE.

So? No universal version (that could be retrofit to older devices) of JS exist on this earth (and the same apply to CSS3).

Think is like C/C++: The same bloat, pain as experience by the first users at the dawn of it, plus half-baked new shinny things, that are not universally used, and never equally across the board.

So, is very likely you need to learn "real vanilla javascript = as understood in the IE6 era, perhaps some versions up (if lucky) plus "jquery".

You can avoid jquery if use some kind of niche stack, but, jquery IS javascript as "everyone" use it. Think no only in raw use, but, interfacing with libraries and stuff. So, jquery is the "rails" of js, could be argued.

IF you actually have total control on the deployment environment, and on the use of external dependencies, you can SKIP JS and use coffescript, elm, typescript, etc. But you need to be very lucky to be in this position ;)

I'm not sure how hands on you are being teachinging your friend, but I tried going the full JS stack route with another friend with only 2-3 courses of programming under his belt, and he clearly was struggling due to the complexity of tooling, setting up environments, and generally having a difficult time figuring out the problems & coming up with solutions to them - I am not inexperienced with teaching either, having done it in various capacities (as a paid & unpaid tutor, a lecturer, and discussion section leader).

FWIW, we were working with Sails.js (http://sailsjs.org/), with the intent to getting to use Socket.io, Angular.js, and MongoDB - the setting up of Sails and understanding what things did in Sails ended up being the problem spot.

Instead, I changed my approach to act more like a mentor and have my friend go along the excellent Ruby on Rails Tutorial (https://www.railstutorial.org/). Things have been much better, although my friend has fallen on his face a few times with Git & SSH in general. I now believe a good intro text is worth far more than picking the right framework(s) to learn.

To provide a counterpoint to many of the responses here, I find that the best way to ramp up quickly in a language is to build a few small things using one or two of the main frameworks or libraries, rather than trying to just learn the language or specifically working only with microframeworks.

There are a lot of benefits that come from using mainstream existing frameworks and libraries from the beginning. You learn conventions pretty quickly, and immediately learn to write idiomatic code for that language. When you use a major framework or library there are typically a lot of blog posts and stackoverflow answers, more so than just for a language itself. When you track down errors you'll end up learning about how the frameworks and libraries work, and thereby learning about how to implement things you wouldn't have considered independently.

As a result, what I'd recommend is coming up with two extremely simple ideas for tools that he'd find useful for himself and implement one each with Ember and React.

Personally, I've been following this approach for many years (I'm currently simultaneously working on three new projects in multiple new-to-me languages like this) and it works extremely well in my experience.

I've written about Meteor a few times, recently not too positively (https://news.ycombinator.com/item?id=8230631), but I still think it's the easiest way to get started with full stack JS development. It gives you a bunch of quick wins which is really good for morale, and from there you can slowly start looking at "raw" node if you want to.

An essential that might be obvious but in case he missed is that learning JS is much easier in the developer console. If you want to experiment with underscore, go to http://underscorejs.org/, hit cmd-i/f12 and type in _.map([1, 2, 3], function (x) { return x * 2; }); or if you want to understand moment, go to http://momentjs.com and type moment().fromNow(); in the console -- the library objects are available there and this makes it really fast to try things out.

Assuming your friend already knows javascript, Backbone would be a solid choice. You can add it to an existing codebase as a model layer and then if you really truly need a framework you can tack marionette or chaplin on top of it.

If your friend's a total beginner, though, then it's better to just learn vanilla js for now.

The phrase "Rails of javascript" doesn't make sense to me. What exactly is Rails...er...the "Rails of"? I'm assuming you mean something analogous to, "Rails is to full stack web-development as X is to JavaScript"...but that doesn't make any sense. Web development is a profession. JavaScript is a language. Maybe you're thinking that Rails is to back-end development as Something is to front-end development? But that doesn't make a lot of sense either, as modern Rails is pretty entwined into modern front-end development.

So I don't really know what to tell you, except that you probably have the wrong idea about JavaScript, and so the best recommendation is, as others have said, to work without a framework (other than jQuery, of course) until you understand what JS's role is in web development.

Rails is the "Rails of" Ruby. Rails is a framework. Ruby is a language.

In analogy form, I think his question is:

Ruby::Rails

Javascript::???

As most people have said learn Backbone. This is really worth reading as a starting point:

http://backbonejs.org/docs/backbone.html

If you don't understand all of that, probably learn more javascript.

I would go with Ember. The router will feel familiar as well as some of the concepts in ember-cli. The documentation is great. Ember Data is very stable (has been for the past 6+ months) and shouldn't be too difficult to grasp from ActiveRecord

I would start with implementing some backend in Node and Express, and with LevelUp for the database. Since you're familiar with Rails and backend development, it should be easy to build something quickly. Just make a simple API. That should show you the basics of JS!

After that, you should have enough JS knowledge to start building a client-side app that consumes your API. I honestly prefer AngularJS, but React+Flux seems like a fine choice.

If this is about getting a job, forget about stacks and just start hacking on the first thing that seems interesting. If you're comfortable, you're doing it wrong.

Whatever you're working with will most likely be out of touch with what the job requires and outdated in a year, but the ability to pick up new things is an indefinitely transferable skill.

In addition to not bothering with stacks, I would also advise you not to limit yourself to JS.

I'd say its extremely difficult to give you a good answer without knowing what you are trying to build. Is the goal to be able to add some interactivity to otherwise relatively static or content driven websites? Do you want to long running client side apps? Is using JavaScript on both the client and server a goal? The JS community is pretty diverse, largely because there are a lot of wildly different use cases.

If you're interested in the fun and pointless, I'd like to plug my own library for working with and playing timed event sequences: https://github.com/zachrose/barrel.

Using it to make something stupid definitely won't get you a job, but it's easy to using it will encourage you to use/learn about the cool parts of JavaScript.

I'd say check out sails.js, it mimics the mvc pattern of rails, and coffeescript instead of js since the syntax is cleaner and would be more familiar. (https://www.npmjs.com/package/sails-generate-new-coffee) <- may be helpful. Additionally, check out yeoman, which mimics the generate commands provided by thor and yeoman generators help you scaffold out apps. Theres the learn from scratch approach if you have a lot of time and want to appear smart, and then theres the ;i need to build something working right away approach', which i like more. Programming is all about abstraction, why bother with the low level apis when you can just use the shiny wrappers and save time. I used the MEAN stack for a long time, enjoyed it, relatively easy to use, and has come a long way since then(we did actually have to fix bugs in the framework in the start).

When youre more familiar you can roll your own cutting edge framework, maybe use koa, write a yeoman generator, fancy non-relational databases like couchDB. Learning to recite APIs as one comment pointed out will actually help you understand good api design, and give you a working idea of how theyre wired usually, allowing you to ramp up faster on a new framework than if you jut knew vanlla js and individual components. IMO. Sorry for any spelling errors, temporarily on a samsung v1 chromebook, things appear a few seconds after i type and the internet is hard to use while listening to music

My suggestion would be to learn Sencha ExtJs [1]. It has a proper MVC framework and is very mature compared to the others mentioned here.

It's not something that can be learnt over the weekend and takes time to master.

Just like Rails, it seems to be able to a lot of things by magic and needs some dedicated effort to understand. This article from their blog [2] and this video [3] gives a very good comparison of what Sencha ExtJs covers with respect to other Javascript frameworks.

[1] http://www.sencha.com/products/extjs

[2] http://www.sencha.com/blog/4-questions-to-ask-before-choosin...

[3] http://vimeo.com/108127206

For a single page app framework that encourages modularity and eschews unnecessary complexity, I highly recommend Mithril. It's pretty trivial to hook it up to a REST API which you can build in Rails or whatever.

I've seen Mithril around and it looks interesting, but the thing I'm wrestling with is whether it's better to check out this niche framework or start with something more popular like React (plus whatever for the M_C part of MVC), or Angular.

I think that Angular is the worst choice because developing an app in Angular is so radically different than developing an app in vanilla JS. For a beginning developer I think it's best to first do vanilla JS, then JQuery, then try a lightweight framework like Backbone or React or Mithril. Angular is just a bad decision, it's like patterns just for the sake of patterns.

Focusing on learning frameworks seems like a good idea for resume-building purposes, but they come and go like fashion. Learn Javascript the language very well first, and then learning the framework du jour will be trivial.

I'm really surprised by the people comparing Ember to Rails. Rails is modular, is opinionated but has affordances for and encourages other ways of doing things, is flexible. Ember is none of those things.

lebron is the only stack -- http://lebron.technology/

DART + Polymer? I know it`s not Javascript per say, but seems at least to be a step up.

Angular 1 has a 2-year lifespan minimum.

vanilla.js

Just JavaScript is enough.

jquery

Why not AngularJS?

Not sure why you got downvoted - when I was a junior developer, I got tasked with investigating building a simple app with Backbone, Ember, and Angular in order to determine what to use going forward for the non-profit I was working at (I didn't make the call what framework to use, I was just the test monkey for how to implement a simple app in all three frameworks). Angular turned out to the easiest by far to get work done with exposure to some advanced concepts - Backbone's documentation was very confusing since everything was in a flat list with high level details buried in there & not enough explanation, and Ember's templating system was very rigid and highly dependent on build processes for someone who had no experience working with tools such as grunt or gulp at the time.

React is probably the best candidate to achieve that simplicity along with Angular, although I would give Angular the edge, simply because it does not rely on tooling to build a small app and still benefits just as well from it when it is present. The documentation, even two years ago, was better than Backbone's at the time (and as far as I can tell from a recent study of Backbone, still is) - Ember's might have been a little better, but it also threw more stuff at you upfront.

The expert can probably work with all of these frameworks just fine - in the end, finding what framework (or no framework) jives with you is the best for your long term development. Become an expert with one, then experiment with others to draw good ideas from them and incorporate it into your code style, that is what separates the good developers from the rest.

Reply on news.ycombinator.com