

Client-Side Frameworks Suck - jashkenas
http://www.quirkey.com/blog/2012/09/04/client-side-frameworks-suck/

======
courtewing
I'm not sure what to make of this article.

I think we can all get behind the idea that the ongoing "which framework is
better" debate is often pretty ridiculous. Different frameworks are clearly
better suited for different tasks.

But I can't really get behind the author's stance that it is wrong for people
to have preferences (even strong ones) about which javascript frameworks they
like to use.

For one, while every framework likely has different strengths, that isn't the
same thing as all frameworks actually being good. It is very possible that an
intelligent person with great intentions could write a framework that simply
falls short of other frameworks in so many important regards that you can't
really consider it "good". It is also possible that a framework will have such
a niche use that most people would not benefit from using it.

Additionally, while not every project has the same sorts of requirements that
could be satisfied with a single javascript framework, most are. Most apps
that are being built in the startup community these days are basically little
more than user interfaces to some REST api. Some may take it a step further
and go "realtime" by using web sockets, but the application doesn't differ
significantly from a REST based equivalent. If multiple frameworks set out to
solve _common_ problems, then I don't think it is ridiculous at all to compare
them and maintain a preference.

One way or another, I think we can all agree that the title "Client-Side
Frameworks Suck" is total link-bait that does not adequately describe the
article itself. To be fair though, I did not watch his talk, so it is very
possible that this title better describes the contents of the talk itself.

~~~
mattdawson
_But I can't really get behind the author's stance that it is wrong for people
to have preferences (even strong ones) about which javascript frameworks they
like to use._

Exactly. As a developer, I can appreciate that every framework has different
strengths and that you should use the tool appropriate for the task, but the
fact of the matter is that I have work that needs to get done _now_ and if I
spend all my time choosing the perfect tool, I won't ship anything. I have a
toolbelt stocked with the tools I like best. I wouldn't want to stifle the
discussions on which one's "best," though, because they can be really
informative for those looking to add a new tool to their stack.

------
why-el
> No one was actually shipping

Is this a serious statement? The amount of _X.js_ I see here is just crazy.

~~~
asolove
Yeah, I definitely agree. I frequently comment on MVC js discussions on HN to
talk about my experiences with different frameworks. I also know that where I
work, we're doing way more work, much faster, with better testing, and having
a lot more fun, since we moved to using frameworks.

There was a brief period where different frameworks' Todo list examples got
play on HN. Today, you can go to the Backbone homepage and scroll through too
many awesome production apps to count, most of them going way beyond simple
CRUD and demonstrating some very immersive UIs that would have been very
difficult to build before.

------
badclient
Incoherent venting. Flagged.

------
joelhooks
His approach to dealing with "Why is X better than Y?" conversations is spot
on. I spent some time as a "open-source MVC framework evangelist" (heh), and
always made a point to ignore the trolls and focus on delivering the benefits
(and costs) of using the framework.

It is genuinely hard to ignore the trolls. If a thing is useful, lets talk
about that.

------
KaoruAoiShiho
Backbone really doesn't suck though if you add enough stuff on top of it. It
only sucks if you're forced to use it raw.

~~~
ajross
For the life of me I can't tell if this is satire or not.

On the assumption it's not (and apologies otherwise): The universally
acknowledged downside of "frameworks" (vs. "toolboxes") is the "weight" of
unused software that they bring along for the ride. So to argue that a
framework is good only if you add enough junk _on top_ (!) of it just seems
like a joke.

~~~
KaoruAoiShiho
I wouldn't recommend a heavy framework that tries to magicfy everything for
you, that kind of framework is really not to my taste. ie emberjs. But
backbone itself is very light, you can probably read the entire source in
under 30 minutes. Nobody is telling you to pack some huge framework on top of
backbone, but depending on the complexity of your application Backbone might
just not do enough.

Something like <https://github.com/marionettejs/backbone.marionette> is just
another toolbox where you can pick and choose the tools you need.

This is why I really like backbone, because you have the option of going big
or small on the libraries you're using depending on your needs, and each
individual component is small and easy to understand.

------
ismyrnow
Yes, the title is link bait.

However, it was written by the author of a popular JS framework. It should
really be titled "There is no Best client-side framework".

It's a good point he made, and one that anyone new to the client-side
framework market should learn sooner, rather than later.

------
jonny_eh
So client side frameworks suck because he's sick of the false battles
portrayed in the development community? I don't follow.

