The Fallacy of Modern Web Development
jtaby.com
jtaby.com
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.
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.
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? 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.
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'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.
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.
> 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.
Talking point much?
You're calling out to people in the Bazaar and asking them to join your Cathedral. Good luck!
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 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.
It's the Backbone copycats that drive me crazy.
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.
http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_ch...
I consider jQuery an olive oil, SproutCore a dressing.
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...
* 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.
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.
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.
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.
"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.