
Ask HN: What is the best JavaScript stack for a beginner to learn? - nielmalhotra
I&#x27;m an experienced Rails developer, and I&#x27;m helping a friend learn about javascript frameworks so he can eventually get a job (we&#x27;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&#x27;t think it would be a good use of time to learn angular.<p>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&#x27;m thinking a MEEN stack (using ember instead of angular) or even using react and flux. Meteor is another choice, but I&#x27;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.<p>It&#x27;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?
======
otto_sf
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.

~~~
simpixelated
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.

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

~~~
reverius42
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).

------
ricardobeat
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.

~~~
sillysaurus3
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.

~~~
Daiz
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...

------
neilk
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.

------
eagsalazar2
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.

~~~
eagsalazar2
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.

~~~
megalodon
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.

------
oneplusone
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.

------
danabramov
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.

------
danaw
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](https://github.com/builtbybig/starter)

------
nathanallen
I've enjoyed working with riot.js
([https://muut.com/riotjs/](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/](http://youmightnotneedjquery.com/)). Take
what you need, leave the bloat behind!

~~~
CHsurfer
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.

------
mamcx
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 ;)

------
Bahamut
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/](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/](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.

------
integraton
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.

------
kristiandupont
I've written about Meteor a few times, recently not too positively
([https://news.ycombinator.com/item?id=8230631](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/](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](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.

------
giaour
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.

------
danso
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.

~~~
joedavison
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::???

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

[http://backbonejs.org/docs/backbone.html](http://backbonejs.org/docs/backbone.html)

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

------
bcardarella
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

------
nickporter
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.

------
annise
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.

------
boucher
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.

------
zachrose
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](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.

------
kaustavha
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](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

------
thunderbong
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](http://www.sencha.com/products/extjs)

[2] [http://www.sencha.com/blog/4-questions-to-ask-before-
choosin...](http://www.sencha.com/blog/4-questions-to-ask-before-choosing-a-
javascript-framework/)

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

------
kyllo
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.

~~~
ochoseis
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.

~~~
kyllo
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.

------
eagsalazar2
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.

------
yoshuaw
lebron is the only stack --
[http://lebron.technology/](http://lebron.technology/)

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

------
davelnewton
Angular 1 has a 2-year lifespan minimum.

------
2mur
vanilla.js

------
TylerH
Just JavaScript is enough.

------
untilHellbanned
jquery

------
antichaos
Why not AngularJS?

~~~
Bahamut
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.

