I love how he's so certain he's right and everyone else is wrong.
Sorry, but other people aren't here to do what you want. They are free to innovate or fail to innovate in any way they desire. The one-true-framework has not been invented yet and probably never will be. Constant improvement and competition are what drive everything right now, and asking us to stop it is insanity.
I have a vested interest in seeing SproutCore succeed, but the point I'm making does not. Backbone.js and Cappuccino are other examples of javascript frameworks which fit the same criteria I talk about.
Backbone and Cappuccino have both proven that they will last and have dedicated communities building them. All these projects need people to contribute to them and make them amazing. A core team can build it, but the community makes it a real project.
Everyone today wants to get the personal glory out of their own little pet project instead of getting the glory out of contributing important patches to existing projects.
> Everyone today wants to get the personal glory out of their own little pet project instead of getting the glory out of contributing important patches to existing projects.
Maybe you're right and it's personal glory. It could also be the (admittedly, often-naïve) assumption that maybe, just maybe, you have a better idea about how to do things. When John Resig [thought up jQuery](http://ejohn.org/blog/selectors-in-javascript/) five years ago, both Prototypejs and Behavior.js were already around. If he had decided to contribute to those projects instead, we'd have a much different landscape today.
>Everyone today wants to get the personal glory out of their own little pet project instead of getting the glory out of contributing important patches to existing projects.
Everyone? No. Most people just want to download the projects they like and build stuff with it. A fraction of those will contribute bug reports. A fraction of those will contribute patches. A fraction of those will contribute feature pull requests or plugins.
I think the perceived problem is that there isn't yet a clear winner in heavy JS frameworks. I think their usage is more niche than their social media coverage would make some people assume.
What's the problem with micro-frameworks or libraries? I prefer to be able to find a nice, compact solution to a problem and be able to jump in any make any modifications I need rather than sifting though a behemoth. It certainly takes more effort on my end to figure out the one-true-framework to the point that it abstracts what I already know. That's doubly ineffective.
I'm much more comfortable with the OS project ecosystem we have now with a ton of tools you can just download and use to your whim. Most of the time you don't even need to modify the code to suit what you want. Granted, it takes a bit more skill to be able to know which solution to choose - but that's something we should all be good at.
This article also sounds like someone who doesn't actually like the art of programming and just wants to see the end result. I'm only frustrated when I'm shackled by a technology or code framework/library. Other than that you have to enjoy the ride because the end result is never as good as you imagine it to be.
I agree with this. The way I see it is that the more you aim for consolidation at the expense of competition, the less freedom you have to renew your approach if you can't quite get the results you want.
This leads to people reinventing the wheel in such a way they're happy with the results and also learn new techniques that can be applicable outside of the framework dev environment.
This is great for innovation, and when you can code independently of a framework and create your own solutions, you're just one step closer to pushing the boundaries and coming up with something special. A custom microframework is great for that as you can get to grips with the concept of ORM, MVC, OOP (with PHP in particular) and all manner of other techniques.
On a personal level, I had the choice of learning a framework to make a REST API, or figuring it out for myself by making my own solution. I re-invented the wheel - probably made something wonky - but it's invaluable knowledge. Had I taken heed of the OP I may still be wrestling with Symfony2 or CakePHP right now.
Looking at it another way, this article could have been written a few years ago and instead of Javascript, it could have talked about fresh web developers creating a blog as their first project. The analogous question posed would be, "why don't people just install Wordpress?"
The answer to that would be: "because they won't learn anything."
The problem is there is no guarantee they will play nicely together, not clash, or provide similar and compatible APIs. JavaScript developers are running into a very similar set of problems and having everyone cobble together their own solutions is pretty clearly not an answer, which obvious to those who have tried. You may already know what is being abstracted by some of the more expansive frameworks (Cappuccino, SproutCore, Backbone, etc) but there are a lot of people who do not know or do not want to deal with the differences in browsers, etc.
I'm assuming that you don't consider jQuery or its ilk restrictive as far as abstracting the DOM. I don't know of many application developers who would prefer to deal with the low-level DOM API (which differs across browsers, etc) instead of a library like jQuery. There are many people who approach application structure from a similar viewpoint. Instead of rolling their own and running into problems scaling and maintaining their applications, they can use a framework that provides an abstraction that is proven to work. Everyone tries to roll their own pet framework project because that's where the glory is. That's not necessarily the best thing for the future of the web.
> Everyone tries to roll their own pet framework project because that's where the glory is.
Here's jtaby about twenty minutes earlier:
> Everyone today wants to get the personal glory out of their own little pet project instead of getting the glory out of contributing important patches to existing projects.
The diminutive "little pet" prefix at one point applied to: linux kernel, kde, gnome, jquery, prototype.js, node.js, ruby, &etc. Your dismissal of small, young projects is akin to saying "Don't start a startup, just join a big business!"
You're calling out to people in the Bazaar and asking them to join your Cathedral. Good luck!
I agree that rolling new frameworks/libraries out for the glory only is a terrible thing but they generally don't do much harm since the truly atrocious projects fade into oblivion. We can only hope at least one thing was learned from them.
I do not consider jQuery restrictive and in fact it's liberating because it provides a core set of tools that are much more useful than the core tools provided by native JS. jQuery was born out of a need. As long as something is more useful than what it wraps I tend to not mind it. But wrapping things arbitrarily like HTML is just useless.
I do see a stark difference between marrying independent frameworks that are proven and writing a brand new one that encompasses all the ideas of each.
Open source software is not a zero-sum game, or a limited resource to be rationed out. There is no such thing as a tragedy of the commons with open source code, because the more of it you give away, the more you have.
A bunch of mildly different Javascript frameworks creates a paradox of choice for the users. It means that when users start developing a new project, they have to weigh the benefits and costs of each of the framework. This not only increases the barrier to entry, but as Barry Schwartz outlines in his book "The Paradox of Choice", it also creates a paralysis and unhappy decisions.
That's only one of the problems. Another problem is that by having all these smart people dedicate their time to solving the same problem over and over, we get stuck at the same level of abstraction. If instead of solving the same problem in slightly different ways, we iterate and build abstractions, we can make apps previously impossible to build in reasonable budgets and time, possible.
It doesn't need to be Sproutcore that we coalesce around. It could be Backbone.
This has already happened with jQuery. The JavaScript community coalesced around the framework, contributed API changes, bug fixes, documentation, unit tests, and as a result, we can operate and build applications without having to re-implement the same cross-browser, low-level code.
Barry Schwartz also talks about the different vinegars, olive oils to make your own salad dressing. Mix & Match. Are you proposing we only have a few salad dressings?
I consider jQuery an olive oil, SproutCore a dressing.
I respectfully disagree. The paradox of choice is not, I think, controversial to anyone here. There is a cognitive burden to new web developers when deciding which framework to use. Often times, they'll make the wrong choice, say "forget it," and go back to native development.
The social incentives in the JavaScript community are structured so that you get recognition for rolling your own library because you disagree with a naming choice. Forking or rolling your own should be a last ditch effort, not the first tool in your toolbelt.
Competition is great, but it must be balanced with collaboration. And I think that's what's out of whack in the JavaScript community.
FWIW, I think Backbone is an example of a library that does things right: it's well-maintained, has an awesome community, and a whole ecosystem of plugins and extensions around it.
My team has struggled to decide how to build a rich JS app precisely because there are so many choices. We have spent a lot of time looking at the strengths and weaknesses of each of the major ones. All that time was time spent not coding. Now, as developers working with the latest stuff, this goes with the territory. But at the same time all this choice was not zero cost for us by any means.
Not to mention that SproutCore itself is a bunch of micro-frameworks all packaged together. sigh
What jtaby's saying, in a nutshell, is: other developers should just stop working on their own (micro-)framework(s), and instead...work on Strobe's (micro-)framework(s).
Coming from a Strobe employee (who has skin in the game), this is somewhat disingenuous...
That's actually not at all what Majd is saying. He's saying that a few good answers with a large community is better than dozens of one-off weekend projects that siphon energy from application developers and open source contributors.
There are so many interesting jumping off points in this post.
* Must web apps go the same route (of consolidation) as desktop apps have (largely resulting in a Windows monopoly)?
* What's to be said about the fact that we're now seeing a dramatic increase in platform diversity in the form of mobile platforms, web apps, and even an increase in the diversity of desktop computing platforms?
* Web apps (HTML/CSS/JS) are one interface to the Internet; what about apps with the Internet as transport and APIs as the endpoint?
* Have we forgotten how young all this internet technology is? The GUI was born (commercially) in 1984 with the release of the Macintosh, making it almost 30 years old. The timeline for web apps is a lot fuzzier. In 1995 NSFNET disappeared and the Internet was 100% available to commercial organizations, but didn't take off right away. Still, if you take 1995 as the "beginning" of the web application, that makes it half as old as the GUI.
IMHO, your third point about "apps with the Internet as transport and APIs as the endpoint" is now where all the interesting client behavior is. Web apps in this regard are just clients implemented in JavaScript.
I'm a big lover of arrogance, controversy and challenging status quo... But seriously? Challenging it with "lets all come together, in a one-size-fits-all, uniform, productivity parade honoring the propaganda department of Apple"??
I hated really the Microsoft experience and was so disappointed by the earliest Linux distribution I switched to OS X when it came out and I have never looked back. I recognize Apple's great contributions to UX and their truly awesome dedication to their mantra "It just works" but I also recognize when they are wrong. I am not blinded by their sales-pitch. And no one with respect for the "Apple-philosophy" should ever be colored by the works of their marketing department. No one should be lead to believe there is reason to settle and not try harder. Apple certainly would not do that themselves. Their core idea is to challenge everything and keep pushing the envelope.
We all do different things for different reasons. Thank for that.
Productivity, efficiency, status and financial success is not the common motivator for all mankind and I hope it never will be. This I say because I believe we can do far better than that.
Experimenting, trying out new things and failing is all a part of the learning experience. Embrace it.
Since when are CSS3 transformations well known and well documentation. Correct me if I'm wrong but aren't new CSS3 trasformations being added to WebKit every couple of months?
Until recently I don't think too many people thought of using them for more than just a nifty effect. Certainly not build an app around them. The debate was whether to build on canvas or svg. Now that's changed with a few recently apps created in purely CSS3 transformations. I don't think anyone is surprised that iCloud is smooth; CSS3 transformations are hardware accelerated.
Sure, sure, sounds great. Unfortunately I'm not in a position to demand that the company that provides my income effectively abandon around 80% of its customer base for whiz-bang features they'll never see nor increase development time/budget for those features.
But I'm confused, is he talking web development or mobile application development? From my perspective those are two different things that may occasionally overlap.
Yeah, he's not wrong about this, but I also don't think that we have settled on what's best right now for developing big time interactive apps for web, which is why there's 40 thousand microframeworks right now. I do think this will start to grind to a halt naturally as HTML5/JS developers mature and apps become proven in the market.
It's a developer preview. I've seen people around here talking about dumping IE entirely if a sufficiently small number of their users used IE8. How is this different?
"They prove that a buttery-smooth UI is not impossible to build on the web."
In my opinion, this application has not proven such a thing (yet), since it doesn't work in IE. I don't build UIs that don't work in IE.
"It shouldn’t be a magical surprised that a good, no-compromise UX is possible on the web."
And yet, currently it DOES compromise. It doesn't work in what is currently the leading browser.
Don't get me wrong, I hate IE and the iCloud application is nice and slick. But it's not currently a viable UX for the most popular browser in use, and therefore is not a viable UX for many web applications. Yet. I have hope for them, though. It does look promising.
Trailer for a movie wherein a member of the crew spends 3 minutes telling you (unconvincingly) that film making is broken and nothing about his movie. Poor form.
Sorry, but other people aren't here to do what you want. They are free to innovate or fail to innovate in any way they desire. The one-true-framework has not been invented yet and probably never will be. Constant improvement and competition are what drive everything right now, and asking us to stop it is insanity.