

On the horrific state of JavaScript frameworks - gasping

Is it just me or are Javascript frameworks among the most horrendous libraries in software development right now? I&#x27;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 <i>absolute minimum</i> 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&#x27;t query an object based on a property of a child association, for example, and is thus almost useless in real world scenarios.<p>The state of debugging is also shockingly terribad. How can people seriously debug a client side application in Chrome or Firefox&#x27;s developer tools?<p>What am I doing wrong? Are Javascript client frameworks really this bad?
======
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.

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

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

------
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](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/](http://fluxxor.com/), or Reflux
[https://github.com/spoike/refluxjs](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)

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

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

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

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

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

