The problem with JavaScript frameworks
Before I get flamed, let me clarify–I like frameworks. I use frameworks. This site’s JavaScript is run on Prototype and Script.aculo.us. The problem is, JavaScript isn’t just JavaScript anymore.
Perhaps you’re using Dojo and absolutely love it. So, whenever you’re writing some JavaScript, you’re obviously going to write it over Dojo. Or, if you’re a blogger, whenever you’re writing about JavaScript your example code will probably use Dojo as well.
But I use Prototype/Script.aculo.us, and to be honest, I’ve never touched Dojo. So if I have to work on a project with you, how’s that going to work? It’d be crazy to include both of them.
Or perhaps I’m reading your blog and you’re introducing some sweet new JavaScript. Now that’s all fine and dandy, but if it’s built on Dojo what good is it going to do me? I’ve already built my stuff on top of Prototype.
Frameworks are changing the way developers both write and write about code. This works great when you’re the only developer on the project, it’s for yourself, or it’s for others using that particular framework. But what about everybody else?
Should we as developers try to get a basic understanding of all the major frameworks so we can easily understand and use each other’s code?
When releasing scripts to the public, should developers try to create versions for as many different frameworks as possible (much like software developers would build for multiple operating systems), or should they ditch using a framework all together?
Or, should each develop to his own and hope that others will create versions for other frameworks (though, this wouldn’t solve the problem of multiple developers working together on one project)?
I have no solid answers to these, so I pass off these questions to you, the blogosphere. What do you say? 
Wow. A problem I hadn’t even considered. Maybe that’s because Javascript frameworks sort of came out of nowhere to me. Whenever I add any Javascript to something, I’m still doing it the old fashioned way, in plain ol’, framework-free Javascript.
Yeah, I’m behind the times: I just got rid of the outhouse last year!
Seriously, that makes what Elliot has to say all the more important. Someone using no framework is just as in the dark as someone who is using a different framework from an example.
So, I think the “ambidextrous” coders will give multiple examples and others will only give the example they know. And I think that’s fine. ASP.NET has done a-okay, with some people using VB.NET and others C#.
If I really want to do what a tutorial explains, I’ll use my brain and translate the concepts to the technology I know. Otherwise, I’ll move on to the next how-to that speaks to my Byzantine ways. I mean, who does Javascript without a framework these days? I’m so incredibly out-dated… at 27.
You’ve got a good point there as well, one I never thought of. Those who haven’t used any frameworks are also going to have a tough time–probably tougher.
A point that was made in the @media Javascript Libraries panel (and one I happen to agree with) is that unless you understand what the Javascript in the libraries is doing, you have no business using a library.
The function of a library should be to make your development work quicker and easier, not to provide an easy shortcut to actually learning anything.
With that point in mind, any serious Javascripter should be able to translate an example posted using YAHOO or Dojo or jQuery or Prototype or whatever into their own chosen library.
That said, it would be nice if common API calls became standardised across libraries, so that you could be pretty confident that Ajax.send (for example) will work regardless of the library.
Some standard calls would be nice, or perhaps some sort of converter that can convert as much code as possible, then somebody else would have to do the rest.
I agree with what Matthew wrote. Imagine a group of math students all using different brands of calculators. If they only think in terms of the buttons they press, they won’t be able to share and compare work with eachother. However, if they understand the mathematical principles behind what the calculator is doing, what brand of calculator they use shouldn’t be much of an issue. The same idea could be applied to javascript frameworks.
I think you have been getting too used to having everything you need built in. That situation is no different to any serverside platform out there.
AJAX/DHTML is growing wildly now. Once people run out of crucial features to implement, they will start to discuss how to standardise the APIs, making them more similar.
Just count yourself lucky that JavaScript libraries never can become truely bloated or the download overhead will unacceptable. Unlike most other programming environments that are approaching three digit megabyte sizes.