Client-Side Frameworks Suck
quirkey.com
quirkey.com
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.
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.
Is this a serious statement? The amount of X.js I see here is just crazy.
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.
It is genuinely hard to ignore the trolls. If a thing is useful, lets talk about that.
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.
It is quite likely that the final LOC for lots of frameworks will look the same, assuming both framework and app developer are on the same professional level. Opinions differ on how much of that code is reasonable to put in the framework itself (and I bet a lot of that is stemming from differences on how professional/good your average app developer is).
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.
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.