HN Explorer

On the horrific state of JavaScript frameworks

21 points by gasping ↗ HN
Is it just me or are Javascript frameworks among the most horrendous libraries in software development right now? I've tried several Javascript MVC frameworks and the glue libraries that come with them (Angular, Backbone, Sails, Waterline, etc.) and the one common theme among all is that they have the absolute minimum feature set to put together a simple application like a TODO app but completely fall apart when developing a real-world rich client application. To give an example, most ORMs like Waterline have extremely basic relational support with little or no support for querying beyond basic operators against numeric or string properties. Waterline can't query an object based on a property of a child association, for example, and is thus almost useless in real world scenarios.

The state of debugging is also shockingly terribad. How can people seriously debug a client side application in Chrome or Firefox's developer tools?

What am I doing wrong? Are Javascript client frameworks really this bad?

17 comments

[ 3.5 ms ] story [ 45.6 ms ] thread
barrystaes
Good question, wondering the same. Although not tried many JS libraries and supposedly the Chrome dev tools are top notch. Going to follow this..
oweiler
It's not that these are 'just bad', it's often that these frameworks often did not have much time to mature.

You just can't compare the JS libary ecosystem to something like e.g. the Java ecosystem which had much more time to grow and mature.

heldrida
They're not, depending on how much experience and understanding of Javascript you have it can be a painful experience. In my opinion, I've experienced AngularJs in a few projects, the learning curve was a bit longer then I expected but the community helped me a lot, plus there's lot's of tutorials and also, you don't need to learn everything and it's not that big in comparision with Backbonejs that depends on Underscore, jQuery or ZeptoJs, etc.

On SailsJs I tried for a bit, but all the NodeJs frameworks are in a different league, so I think you shouldn't really compare them.

Some tips, there's this website called echojs.com (like hacker news for the js world), there's also frontendmasters.com with really good learning resources for a small monthly fee from experts all around the world.

I've been working as a Full Stack Developer for a long time and now decided to do just front end development and I couldn't be happier with the state of tools we have nowadays, specially for debugging: Chrome, Firefox, etc. For example, have you checked the new Firefox feature that allows you to get the list of event listeners attached to a DOM element ? That's sick! What about remote javascript debugging ?

In the end of the day, maybe javascript is not for you or you need some more time.

The new kid on the block is famo.us! Have a look!

gasping
Thanks for those resources, I will keep an eye on them.

The new kid on the block is famo.us! Have a look!

That's sort of my problem with these frameworks. A neverending explosion of new frameworks that haven't been thoroughly field tested. Meanwhile existing frameworks move on from their 5 minutes of fame and fall into obscurity / deprecation.

auganov
It's not clear to me what you're expecting from a JavaScript 'framework'. It seems like you're looking for an all-encompassing backend and frontent framework?

Try to go for a more loosely coupled approach and look beyond MVC[1] frameworks in general. I'd suggest trying React for the front end. It's not a framework, but it will definitely influence the general architecture of your app. That is, you'll probably end up using some form of 'Flux'. http://facebook.github.io/react/docs/flux-overview.html

[1] Nothing wrong with MVC as an architecture, but most attempts to reify in a framework don't work out IMO. Pretty much same goes for OOP.

[dead] zobby
Beyond programmatical shortcommings I can't help but wonder how they would be usefull in real web, out of logged-in webapps: Google nor any crawler on earth can reference their contents, so you're making a hype top-tech website that nobody would actually visit?
raelmiu
I completely agree. There's something really wrong with the approaches.

They're both too complex and too simplistic at the same time. BackBone and Angular in particular demand a lot of code to do simple things and still fall apart in large scale production.

The best I've seen is https://muut.com/riotjs/ which is basically just a collection of JS-objects and a router. But it's far from useable because they've tried to cut corners, and lacks all sorts of documentation.

elblanco
It might just be the complexity of the language almost lends itself to complex approaches for relatively simple tasks.
raelmiu
True. But odder still that frameworks would need even more complexity.
lstrope
The Flex community (before steve jobs killed it) had the same issues - every week a new client-side framework would come out and try to re-define client-side MVC.

The best framework I found back then was RobotLegs, which was an MVC(s) framework which I loved because it was more of a set of patterns you followed. Dijon.js https://github.com/creynders/dijon is a port of Robotlegs to JS which seems cool. It just provides dependency injection and leaves the MVC part up to you.

Flux seems like the way to go, IMHO. It is more of a set of patterns rather than a "framework". It's a lot to grok at first though.

I'd look at Fluxor http://fluxxor.com/, or Reflux https://github.com/spoike/refluxjs, which both seem to make Flux a bit simpler.

(I do agree with you that the state of frameworks now is ridiculous)

sheraz
Not sure where to begin, but I'll take a crack at this one...

I used to be like you. I was out at every meetup -- flirting with all the new frameworks in town. We would start off hot-n-heavy, staying up late into the night, making big plans. But just as things were about to get serious, I back-peddled and started to better-deal -- thinking there is a "better framework" out there. I didn't want to make the wrong choice.

Backbone was the hot new sexy, and we got along great. We breezed through TODOMVc, and everything just "clicked." She showed me a better way to javascript. This was great! I took the relationship to the next level, and we were off on our enterprise app. Sad to say, the romance ended the moment I realized what two-way data-binding was, memory leaks when destroying views, and the need for good message passing. Backbone had none of it, and I told her about it. Then one day she came home dressed as Marionette (marionettejs.com), and I hardly recognized her. I found her to be complex and abstract. She was no longer the simple and elegant framework I knew, and so I moved on...

And soon enough, there I was out at the meetups again. That was when I met Angular. I found her opinionated, and a really domineering. However, she was from a well known and respected family. Besides, I was happy to be with someone who took care of so many things. But that comfort came with a price. She wanted me to do things her way, and do it without much documentation. She just wanted to me to "get it." But it didn't click. And so I gave her the "its not you, its me" talk, and I moved on.

See a pattern here? I think many devs can relate. Let me explain:

TL;DR

Frameworks are like relationships. The only way you can get the most out of it is to fully commit yourself to it -- using the good parts and working around the bad. The sooner you realize this the better, because you will stop wasting your time with frameworks who don't do more than offer a weekend thrill with TodoMVC.

BTW: I'm now in a polyamorous relationship with Flux and ReactJS, and it is wonderful.

brotchie
Perfect description.

Now on a Fluxxor+ReactJS stack moving from Backbone... couldn't be happier.

gasping
What did you do when the infatuation with Angular wore off? Did you see the project through to production release? Was your employer satisfied with the outcome?
sheraz
Fortunately there was no app built in Angular -- it was Backbone. We saw it through to the end, and everyone is happy (at least no one was fired). But you don't want to look at my git commit messages. Lots of cursing at callbacks and async hell.

Big lesson kids: When learning a new toolkit or framework, build a toy project you can discard when it is over. That way there is no technical debt, and you will be better able to analyze and decide if this is right for the Big Project(tm) ahead.

That is what I did for React and Flux. I took some hours at work and at home to get up to speed with a small PhoneGap app. Once I was satisfied, I presented to my team. There were some questions and feedback, and it made evangelizing much easier -- it sold itself.

infinii
It's a consequence of too many choices. A new framework pops up showing great promise. Nothing is every fully polished to begin with but before it can gain widespread adoption where contributors fill in the blanks, a new kid on the block shows up and any momentum with the first one is lost as people move on looking for grassier fields.
LarryMade2
Maybe you've outgrown frameworks in what you do? Frameworks are built up to take care a host of situations usually in a specific way or another, but they aren’t a panacea.

Sometimes you have to take down the "rails" and chart your own path.