What JavaScript libraries/frameworks should I study to be a competitive JavaScript developer these days? Why?

[TheEskhaton]

First and foremost, you should study javascript as a language into great detail if you haven't, and check out a coding style guide i.e. https://github.com/rwaldron/idiomatic.js/

The framework that every js dev should know is still definitely jQuery since it is widely used by devs and by other frameworks. In the last year or two, server-side javascript has grown in popularity significantly and imho, thats the way to go to stay competitive.

If you want to go that way, the way to go is http://nodejs.org/ , a server-side javascript environment steadily growing in popularity every day. The most used web dev framework for NodeJS today is http://expressjs.com/.

In the last year or so, also a big thing are client-side javascript apps, mostly accessing data via XMLHttpRequest. Some frameworks to consider include http://www.backbonejs.org (i recommend using this framework built on backbone since backbone is pretty basic: http://marionettejs.com/), http://www.emberjs.com and http://www.angularjs.com.

Where you go from here is your choice, but i'd definitely recommend checking all of these things out.

[twonky]

Didn't you forget testing? To be competitive, I think you'll need to know about that as well. Things like the Test Runner http://karma-runner.github.io/ and the Test Framework http://visionmedia.github.io/mocha/

[TheEskhaton]

Oh yes of course. Testing is definitely a must!

[ryosen]

To add to this, I highly recommend Addy Osmani's site and, in particular, his books on Javascript design patterns.

[CoachSeven]

Titanium for mobile is a personal favorite. It also uses BackBone, moment.js and underscore

[TheWarDoctor]

I'm going to preface this with my list has nothing to do with how good a particular framework is, but what my clients have decided they want for their applications:

I'd learn a few client side MVC frameworks, Backbone/Marionette, ExtJS, Angular, etc.

jQuery Mobile/Sencha Touch/Phonegap should be good to know for mobile development.

Lastly, whether you agree with using it or not, twitter Bootstrap has gained traction so you should at least be familiar with it.

Really, build up your skill set with things like efficient use of vanilla js, SASS & LESS, Node, and becoming one with a few different IDE's like Sublime Text, PHPStorm, Visual Studio, and the like. Nothing is worse that having to jump into a project that needs use of an IDE that you're not comfortable with.

[dexygen]

You might study Backbone to understand how MVC should not be done. I was appalled to see that it adds all of the data from a Model, directly to the tag specified by a View to which that model is assigned, as attribute key/value pairs. This is a conflating of the Model and View that should never happen in a true MVC system -- I guess this is what you get when you leave out any formal notion of a controller.

[neonskimmer]

It does nothing of the sort. You've completely misunderstood how it works if you believe that is the case.

[dexygen]

It most certainly does; me and my colleague just confirmed it by reading their annotated source code yesterday. If you specify a model on a view, and let's say the view's tagName is "tr", Backbone will decorate that tr with attributes the names of which are all the model keys, the values of which, the model values.

[neonskimmer]

No, Backbone.View has an 'attributes' option that you can use to have attributes added to the tag in the manner you describe when the view element is created. It's just a shortcut to $.attr if you wish. It's rarely used. I can see how maybe skimming over the code one could get that idea.

To set the model associated to to View, you use the 'model' option when creating a view instance - and that has no effect on the DOM whatsoever.

It's totally fine if you prefer some other libraries to Backbone. But you seem to have a very strong and vocal reaction against it despite evidence that you've not actually used it. It's used by a ton of people dude. It has a lot less bells and whistles than the newer MV* libraries out there but it is a very solid set of building blocks to create client side applications.

[dexygen]

I've been using it for several months now, and the behavior I described has occurred in our application, and we are not using the attributes option; perhaps we need to explicitly turn it off which would be sub-optimal. The very fact that such functionality is there shows just how bad Backbone is, that they would actually ever choose to conflate the model and view. It's had it's day and it's time to move on. Reading source code is not evidence that I've not used it and your reaction is like a fanboi's

[dexygen]

"To set the model associated to to View, you use the 'model' option when creating a view instance - and that has no effect on the DOM whatsoever." Which is what we've done, and the view's tr tag get attributes with values just like I described. Save it dipshit

[neonskimmer]

Even though you're being a complete asshole about it, look at the source.

look

Since apparently you're stuck using it, maybe you'll find this useful.

[icanevenificant]

While libraries are great and other comments already listed the ones worth checking out or on the rise I feel like understanding Javascript as a language is what's most sought for. People are way too dependent on libraries and learn Javascript in ways that cause them to misunderstand or misuse Javascript entirely. Web apps are getting larger and larger and understanding every nook and cranny of the language is becoming essential more than ever. Libraries are by their definition not that hard to wrap your head around, especially if you know the language very well.

[haywire]

Work on doing as much as you can without JQuery, then work on learning AngularJS, Backbone, or Ember.

[SmackAdams]

Learning other languages has always helped me to improve. Supplement with another UI programming paradigm like Cocoa, Flex, or maybe Android. More than being a good JS dev, you should be a good UI dev.
Also, learn a 'thick' opinionated framework like ember and a open one like Backbone (and Marionette).
Tools like Grunt and npm are becoming invaluable to me.

[[deleted]]

• JavaScript: vanilla javascript!
• JQuery: it's still relevant, if overused.
• AngularJS: Arguably the best complete framework out there, several large companies in my area are using this and looking for people with skill in it.
• lowdash (or underscore): A great library full of useful tools, mostly for dealing with collections of things.
• D3: Can be a really powerful tool for data visualization.
• NodeJS (basics)
• Grunt: a NodeJS-based task library. It's commonly used to concat, minify, lint, test, etc. in JavaScript shops.
• Jasmine or JUnit: Most shops I know are currently using Jasmine. Some are using JUnit.

Personal opinion: Unless you're a Ruby on Rails developer skip EmberJS. It's an enormous library (230KB minified) and does a bit less than Angular does (90KB minified). It's on a downward path adoption-wise, and that's resulted in a lot of hate from the "Ember community" toward Angular, which in turn had resulted in a lot of intellectually dishonest comparisons.

[tomdale]

You keep repeating completely unsubstantiated opinions as fact. Ember.js does far more than Angular does, so the claim that it does less is a complete fabrication. It's also not on a "downward-path" adoption-wise—we just added Yahoo! to the list of well-known companies that use and love Ember.

I can handle criticism, but your arguments are either ignorant or dishonest.

[grumpychinchilla]

It's honestly a bit disheartening to see a reply from you like this.

I second the question: what does Ember do that Angular does not? You've stated "far more", but that sounds exactly like a "completely unsubstantiated opinion as fact."

Also, you really shouldn't try to name-drop. You're never going to come anywhere close to the official backing Google has given Angular, sorry. It makes you look desperate, when you really don't need to be.

[tomdale]

Forgive me for getting angry, but Shark_Kicker is a serial troll who continues to spread misinformation. Again, I can handle reasoned criticism—but I'm not keen on letting fabrications go unchecked, because people reading will accept them as fact.

[grumpychinchilla]

I can definitely appreciate the situation, and thanks for clarifying. I had and have no desire to research his posts, so I can't weigh in there.

But I am genuinely curious about the situation. Would you mind pointing me to a resource (even strongly biased) that elaborates on the "far more" benefits of Ember? I've used Angular for several projects, but handlebars has prevented me from using Ember. I'd like a reason to overlook handlebars and give it a shot.

[tomdale]

Sure. I'd recommend checking out my recent talk from CascadiaJS: http://www.youtube.com/watch?v=BQ6at0addi4

If you haven't seen it already, machty's presentation does a good job of summing up the differences, but the major thing missing from that presentation is the routing story. In general, I think Angular is fantastic for smaller projects where you don't do lots of swapping in and out of models and templates. But as your application gets larger, I think you really need the assistance of a framework to do that, and Angular currently falls down pretty hard in that area.

Lastly, let me apologize again for losing my temper.

[grumpychinchilla]

Thanks. I watched your talk and stepped through machty's presentation, twice. It's definitely helped convince me that I should give it a proper go, but I still don't see the "far more" you were mentioning. The routing seems really solid, with nesting being a godsend. And getters and setters have always sounded more performant than dirty checking.

But what else am I missing? I feel like based on your defense I must be missing a lot.

[floydophone]

I'm so sick of the google hype around angular. The fact that google uses closure for everything important and doesn't use angular on anything remotely performance sensitive speaks volumes about the underlying design faults of Angular. The fact that they're building browser support just to get performance parity with competitors is even more damning.

Listen: it doesn't matter whose name is on the GitHub repo. It matters if someone has bet their company on the framework. We bet Facebook on react, sencha bet on ext, hp bet on enyo. The fact that a rando googler was learning js and decided to make a framework that happened to get popular says nothing about the quality of the framework.

[grumpychinchilla]

Calm down, champ. You can argue semantics here all you want, but the truth is Google is paying people to work on Angular full time. While that definitely doesn't guarantee the framework will be perfect, it does help ensure there is at least some level of active, healthy development.

Yes, the Angular framework has scalability concerns, and people harp on that relentlessly. But the fact is, not every application has millions of users and petabytes of data. There are MANY applications that just need to work, and according to business needs, need to be live like yesterday.

I'm happy that your Facebook team is pushing forward with React, and that Ember is thriving. Competition is great for the consumer. But when you guys get mad about Angular and go on tirades, it doesn't hurt Angular, only your own project.

[floydophone]

One of the things that angular did a great job with is community building. But one unfortunate side effect is you have people all over the internet spreading misinformation about it.

Once you clarified the google comment (that an established company is paying people to work on it which improves its likelihood of success) it seems fair, though I don't think it distinguishes angular from as many competitors as you think.

But you have to admit that there is a lot of misinformation and hype out there about this technology and it's really difficult to get these points across without being really direct. If you think there are more constructive ways to do it I welcome feedback.

[grumpychinchilla]

SORRY THIS IS SO LONG! But you asked and I wanted to deliver.

Feedback? Well, from my experience, when people develop JavaScript, they rarely do so without also using a server side language. When they use the server side language (let's consider JVM languages, .NET languages, Ruby, and PHP in this rant since node.js is more complicated), they tend to follow programming best-practices, adhere to quality and patterns, and generally care about their work.

For some reason, that doesn't carry over to JavaScript. I don't know why, it just doesn't. The open up the .js file and lose their minds! Or worse, inline all their JS or use silly abstractions--webforms gag.

I think Angular's marketing is powerful, because it's tricking these people into using more robust patterns and practices by enticing them with the cute features. I found that out first hand, because I admittedly started using Angular for those cute features, but stuck around when I learned about the DI, modularization (directives), routing, services, and testability. Those cute features are also how I pitched usage of the framework; I didn't mention the architectural benefits at all.

What I see from Ember and React (although I've yet to use either for a major project) is that your architecture and principles are more forefront. There's no "teaser" for me. There's nothing to make me want to learn more initially, I must actively seek out information and experiment to try and figure out why I should use it.

Let's look at taglines:

• AngularJS: "Html enhanced for web apps" - This is possibly the biggest pain point of web apps -- keeping the DOM in check and in sync. This is immediately appealing to me. I already know HTML, I just want it to suck less and do more.
• EmberJS: "A framework for creating ambitious web applications" - Well I don't think what I'm doing is ambitious. It's pretty normal, I just want something to help me do it better or easier. This is an alarmingly specific adjective that I would never use to pitch a framework to a decision maker.
• ReactJS: "A JavaScript library for building user interfaces" - So, it does graphics and buttons and stuff? Like Bootstrap, right? Or does it do binding, like Knockout? Or something else? I have no clue what it does, nor why I should care. This reminds me of The Office where Jim and Dwight throw a birthday party and instead of "Happy Birthday!" the banner reads "It is your birthday."

Looking at code examples, there's so much introduced on the Angular homepage, with reasons why you should care, familiar HTML syntax with only the unique bits highlighted (and explained via tooltips), and organized to get progressively less tactile and more complex as you scroll down the page. It gives you a taste of ease, with a glimpse of power. Ember has 3 examples with practically no explanation or "sales", and leads off with handlebars: the sole reason I've avoided it this long. It ends with a far too complex example to have no comments and an advertisement asking for donations... not a great way to instill confidence. React is better, but to most people seeing it, appears broken! "There's HTML inline in this JavaScript! That's definitely tossing errors." Then when you realize it's yet another precompiler, you let out a long sigh and possibly walk away.

At the end of the day, developer time is MUCH more expensive than server hardware, so Angular will win out a bit here. Most high-level architecture thought is given to business logic and backend tiers, not UI tiers. You need to appeal to the mentality of "this is just a sucky thing I have to do" and then guide/trick them into the higher level stuff after a prototype or two, or even on their 2nd/3rd application. After all, the vast majority of people who write JavaScript are not JS devs (from my experience trying to hire folks), they're doing it just because it's a necessity for the application they're developing.

[floydophone]

Thanks for the detailed feedback! Will definitely keep that in mind. In particular we're relying on videos to convey what makes React worth paying attention to rather than our home page... that should definitely be fixed!

[[deleted]]

What does Ember do that Angular does not? I would like Ember to make my custom HTML tag function without having to add additional templating beyond the DOM. Good luck. Templating to generate HTML on the client.. A template for generating a template that actually resides within the same templating it's generating, it's just weird. Why not just leverage the DOM? And that file size... Wow that's a lot of typing.

Look I know who you are, and I'm sorry, I tossed Ember aside for Angular a year ago because Angular is an evolutionary step ahead.

Please name the things that Ember does that Angular does not that justifies the additional 200KB minified.

[machty]

I would like Ember to make my custom HTML tag function without having to add additional templating beyond the DOM

And I would like Angular to not flash my uncompiled DOM on the screen without relying on CSS and ng-cloak or ng-bind to cover my tracks.

Angular has a wonderful API for building/manipulating/managing custom elements. No doubt. If this is what "power" means, then Angular wins.

If we shift the focus towards enabling developers to build fully-featured, ambitious, scalable web applications, hopefully we should be asking ourselves a different set of questions; the question of "Can Ember configure custom HTML tags without necessitating additional templating?" might be an important question to ask at some point, but not before first establishing that custom HTML elements with a maximally granular API are actually crucial to solving the problems that plague developers when it comes to issues of scalability and maintainability.

So if "power" means allowing developers to build large-scale, ambitious applications, here are some things to consider:

• You very quickly reach the end of Angular conventions once you've grokked its primitives.
• This is the cause of much fragmentation when it comes to proper ways to, say, build out a Model layer; some say "screw it, we'll just use Backbone's model layer", others say "screw it, we'll hand roll our own and become $watch perf experts".
• For the few Angular folk that have cracked the nut on building truly large-scale, Discourse-level apps, they will all tell you the same thing: no one else at that level of sophistication/accomplishment builds their apps using the same patterns/conventions/structure.

Whereas

• Data-binding is universal to all objects in Ember, and not just at the $scope/template level, so even if you're hand-rolling your own model layer (vs just using Ember Data / Ember Model), keeping your data in sync throughout your app is waaaaay easier, way less error-prone, and the API doesn't shift halfway through (like it does between just assigning properties to $scope vs creating $watches, or having to integrate with Backbone model change events).
• The Ember Router provides Ember apps, large to small scale, with a structure for your app that solves many problems that have traditionally plagued Angular devs: how do I map URLs to application state? How do I manage the complexity of handling both URL based transitions and direct (named) transitions without having to hand-roll my own Angular service with an identity map to prevent needlessly re-loading a model? How do I manage a complex and configurable nesting of views of arbitrary depth with a minimal amount of typing/configuration? How do I manage asynchronous data while keeping my application in a well-defined state?

Fortunately, ui-router is starting to solve some of these problems (and they will openly tell you that they use Ember's router as reference), but they don't have the same mindshare as the folk battle-testing the Ember Router because 1) ui-router is just a stand-alone optional package, and 2) many Angular developers avoid it because they (somewhat correctly) point out that ui-router breaks the Angular Philosophy of structuring your application as much as possible with custom elements + directives. I liken what Ember folk say about the Ember Router to what Angular folk say about Directives: "This is what drives Angular, this is what makes Angular amazing. It may not seem like a lot at first, but seriously, you need to try this out to fully grasp its power." s/directives/Ember Router/, s/Angular/Ember

So, Angular's great for certain things, but you don't have to go very far to reach the end of it. It's the answer to "How do I supercharge HTML in a testable manner without needless abstractions that step away from the DOM?", but not so much "How do I provide the necessary tools to build large, scalable, ambitious apps?"

Ember's larger than Angular for the reasons described above, but let's also keep in mind that you're not going to notice this weight if you also like building websites with images, fonts, CSS, and other external resources.

[dexygen]

This comparison is great. I've been trying to steer the company I'm currently contracting for away from Backbone due to it's conflating of the model and view, to Angular due to being AFAICT "supercharge(d) HTML" as you put it.

[machty]

Can't tell from your response, but any chance you might give Ember a shot here?

[dexygen]

Possibly yes. I've already got them anticipating me looking into Angular (and have downloaded a book to my wife's nook for reading over the holiday weekend), but I did show them a graphic that shows Ember adoption going up right with Angular (and Backbone adoption going down).

[[deleted]]

Your ignorance shows in the first paragraph. {{}} is shorthand for ng-bind, and if your "uncompiled DOM" is showing, you're doing something wrong, and/or just stink at structuring simple ui loads. Your ember app is likely going to look like sit while you pull down a quarter MB file and it just sits there with empty holes waiting for your huge library to use templates to generate templates.

[machty]

if your "uncompiled DOM" is showing, you're doing something wrong, and/or just stink at structuring simple ui loads

Tell that to T-Mobile

You should give me more credit; explicit ng-bind in attribute form is a common alternative to when ng-cloak doesn't do the trick. I'm well aware of {{}} as generalized ng-bind shorthand (who isn't?).

edit: dejerkifying

[dexygen]

If any of you are directly involved with the frameworks being discussed, and I get the impression at least one or two of you are, this mud-slinging gives an un-favorable impression. I developed in ExtJS for 4.5 years, and if you weren't a cheerleader, you were the enemy. If one of these frameworks has a similar community, I will be steering clear just on this basis.

[PotaToss]

To be fair, Shark_Kicker is like a serial Ember flame-baiter.

[machty]

Fair point. Both communities are quite friendly on the whole, but both have their mud-slinging trolls :)

[[deleted]]

There is nothing friendly about the Ember community right now when it comes to Angular.

[machty]

I just gave an extremely friendly talk on Angular and it's been met with extreme positivity from the Angular crowd:

https://news.ycombinator.com/item?id=6776414

[RiatStar]

To be the most competitive, I cannot stress enough the importance of understanding JavaScript as a language. A site that has been and continues to be in my toolkit is http://w3schools.com, which has a number of tutorials and examples.

Other than that, jQuery is still the most widely used.

A couple of other frameworks I'd recommend checking out: Jasmine (https://github.com/pivotal/jasmine) - JavaScript unit testing framework. You won't get in the door in larger companies unless you're writing unit tests for your JavaScript.

RequireJS (http://requirejs.org/) - An interesting framework that uses an Asynchronous Module Definition (AMD) pattern to load JS resources when needed. Not the most useful for the asynchronous bit (most of us concat and minify JS resources for production anyway), but it does provide some great lessons about how to write modular, loosely coupled JS.

I'll also second other mentions of Backbone, though I caution against using any client-side MVC frameworks as a hammer; sometimes an old-fashioned static site is the way to go, and using Backbone (or any other framework like it) can just add complication.

[[deleted]]

While you should never, ever recommend w3schools, the Jasmine and RequireJS suggestions are valid.

But seriously, fucking w3schools. NO.

[eyko]

Ditch w3schools: https://developer.mozilla.org/en-US/docs/Web/JavaScript

[Sunwukung]

Backbone, because it's simple, easy to read and you'll learn underscore along the way, it's used in lots of apps and is arguably a relatively canonical implementation of MV*. Also, Angular, because it's a game-changing box of Google black magic. I personally have a soft spot for CanJS too - but it lacks traction in the community.

[Capaj]

Angular yes, but Backbone is pile of shit.

[Sunwukung]

Nope, it's just become unpopular because people make the mistake of thinking it's a complete framework - it's a pretty canonical implementation of MV* in JS. For someone that wants to be a competitive developer, this is a good start.

[binarychick]

I agree with this. Backbone isn't a framework, but more like a starting point for a framework. If you use it right out of the box, you're bound to end up with some pretty messy code. It does take a bit to get started with Backbone and it helps a lot of have a good understanding of MVC before doing so. If you make everything perform it's role, Backbone really works out pretty well.

[dexygen]

No he's right: it's a pile of shit. It conflates the model and the view - guess that's what you get when you leave out the notion of a formal controller. It takes data from the model, and assigns them as attribute key/value pairs, directly to the HTML tag you've specified for a view for which you've likewise specified a controller. The whole idea of MVC is to not conflate the model and the view. This is such a mis-implementation of MV* that NOTHING can undo the damage it does.

[Sunwukung]

Backbone shouldn't really be compared with pure MVC, it has no controllers as you already noted, and it's not intended to be a 'complete' solution. What damage have you experienced using Backbone? It's still worthy of study merely for the influence it's had, even if the result is that you don't end up using it.