Client-side frameworks suck
Almost a year ago I gave a talk at JSConf.eu after spending a long time thinking about what had been irking me so much about client side frameworks and the JS community in general. The premise for the talk was simple: frameworks are not the answer and certainly not the goal. I noticed how much time people spent debating the merits and qualities of frameworks and it seemed like no one was actually shipping.
You can watch the full talk here:
There is no BEST
I think the thing that had bothered me the most was that people kept wanting to elect the ‘BEST’ framework, like that was a prize to be won. It just made so little sense to me. The concept of best is so silly in the development world. Not only do standards and best practices change constantly (much faster than frameworks can or do) but the idea that there is a single library or system that could satisfy the needs of a majority of projects is just absurd. Some apps are structured around pages, some around events; some are simple single page information holders, some are complex intertwined real-time emotion recorders. Any level of complexity in a framework is going to make it not useful for a majority of cases and any level of simplicity is going to make the framework not that helpful. The fact that someone would go into a project with the goal of using a specific framework seems so backwards.
Obviously, different applications/sites/businesses have different goals, but for 99% of them that goal has very little to do with the technology used, especially the technology chosen to power the client side.
Sammy lost
To the outside world, though, Sammy lost this war to be the best. The funny thing to me is that I was never trying to fight. Over and over again, people tried to pull me into the battle of “What’s better, Sammy or X?” and I refused to answer. Not only was trying to defend something that I wrote for myself and gave to the community as a gift, just straight exhausting, it was futile. Sammy isn't the best. It is good for a number of use cases and not very good at all for others. It’s an idea and a tool, not a religion, and definitely not a messiah. The smart people out there should look up and realize that niether is any other framework.
It’s fucking JavaScript
In the client side especially, the fact is that however complex your app is and how fully featured your framework is, you’re going to be writing JavaScript. JavaScript is a constrained and pretty crazy language running in a wacky ever changing environment. If you expect your framework to hold your hand through the battle field, you’re going to end up hitting a mine at some point and if you don’t understand or know how to write vanilla JavaScript, you will never escape.
I really, really love JavaScript (especially in the browser). It’s bizzare but it’s powerful. I created a framework to help me have a basic layer on which to build JavaScript applications, that fit the style of applications I wanted to and was building. Its goal was to help me ship interesting things faster, and it definitely succeeds in that. In all of those applications though, Sammy was maybe 5% of the final application. The rest - it was just fucking JavaScript.
Where to
Sammy.js quietly turned 3 years old in May of this year. It was a moment that passed without fanfare or celebrations. I reflected on what I’d accomplished since then, and though Sammy has changed a lot since the begining I know for a fact that the JS world has changed more around it. It will continue to change and whatever is hot now, will look like the stupidest idea ever very soon. Thats the nature of this crazy world we work in.
I’ve stepped back a lot from maintaining Sammy day to day and Frank Prößdorf aka endor has been doing a great job pushing the project forward.
Sammy is still here, and will still be here. Whether or not the actual code is still in use, the ideas live on in a ton of other projects and frameworks and that I can certainly be happy about.
Subscribe via RSS
it’s not popular unless it looks like java: Ember.Object.extend({}).reopenClass({}), people are so afraid of javascript for some reason :s
TJ, none of the Ember developers are Java fans nor were any of the SproutCore developers. Ember has no desire to look like Java, nor does Ember actually look much like Java. Please refrain from commenting in areas that you’re not familiar with.
@TJ Can’t tell if serious or trolling.
@TJ Have you ever used Java?
I feel ya man. I wrote about similar sentiments a while back: http://briantford.com/blog/too-many-frameworks-qq.html
“Sammy is still here, and will still be here. Whether or not the actual code is still in use, the ideas live on in a ton of other projects and frameworks and that I can certainly be happy about.”
Very true. The value of a framework isn’t in the implementation, it’s in the ideas.
Mb because all the grads naively assume if they’re doing “OOP” then they’re engineers…
Absolutely freaking brilliant! You comment: “Sammy was maybe 5% of the final application. The rest – it was just fucking JavaScript. ” should make people sit up and take notice. I have wrestled with what framework to use, but usually just write things in the same patterns.
I see value in a framework, but case by case. Glad you shared this. Thank you! Now I don’t feel like I have three heads when I ask “why do you need a framework?”
What’s better: Sammy or python?
I agree, questions posed like that are not particularly interesting and can be traps. The real question of course is, what’s the problem you’re trying to solve?
When people ask questions like “what’s better, x or y” likely they don’t understand the domain very well, and what they are really asking is “what’s the difference between x and y and why would I choose one over the other?” With the plethora of client side frameworks out now, simple guides (they do exist but can’t remember one off the top of my head) to answer “when is framework X a good fit?” can be useful, I think, though I’ve never consulted one…
So frameworks are still useful, there is just not a single best framework.
The utility of a framework is that it provides robust solutions for repetitive, usual tasks so that you, the app/site developer, don’t have to. I’m not acquainted with javascript frameworks but in Ruby for example I’d choose Sinatra for simple, lightweight applications and Rails for anything else (in javascript, it’s probably more granular)
[…] From Client-side frameworks suck: If you expect your framework to hold your hand through the battle field, you’re going to end up […]