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.
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.
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.
Still watching the video but the impression I got was that developers were stuck choosing between frameworks and not shipping whatever they wanted to build, not that frameworks themselves weren't shipping.
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.
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.
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.
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.
The difference in framework "weight" is mostly about an opinionated view regarding how the non-framework part of your final application will and/or should look like. Backbone is assuming that this will look quite differently, depending on your personal style and the needs of the application. Other frameworks differ.
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).
I'm going to go with venting since it would have made sense to actually show the screen his was using for his presentation. Instead, it was completely ignored during the course of the rant.
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.