Microsoft and Nokia Adopt OSS JQuery Framework
soliptic writes "The jQuery blog today announced that 'Both Microsoft and Nokia are taking the major step of adopting jQuery as part of their official application development platform.' So the open-source javascript framework will be shipped with Visual Studio and ASP.NET MVC. Microsoft's Scott Hanselman notes: 'It's Open Source, and we'll use it and ship it via its MIT license, unchanged. If there's changes we want, we'll submit a patch just like anyone else.'" There's also a story at eWeek about the decision.
Additionally Microsoft will be developing additional controls, or widgets, to run on top of jQuery that will be easily deployable within your .NET applications. jQuery helpers will also be included in the server-side portion of .NET development (in addition to the existing helpers) providing complementary functions to existing ASP.NET AJAX capabilities.
Javascript frameworks deal with the major hurdles of modern web design: Abstracting browser differences, and avoiding reinventing the wheel with the kind of AJAXy effects that are increasingly more common these days.
I wonder how this will affect Prototype. It's always had different design goals than jQuery, but will this diminish it's popularity?
Also, will the jQuery API eventually be integrated into the browser instead of being a huge JS blob for every page?
.: Max Romantschuk
Yeah why not? As long as they release all their code under the MIT licence (which they've said they will do), there is no reason not to embrace and extend. The parent project can choose to incorporate Microsoft's code, or not.
From the article, Microsoft have said they will contribute patches upstream rather than forking their own version. But as long as you're sure everybody is releasing their code under the same free licence, 'embrace and extend' is not a problem in the free software world. In many cases it can be beneficial.
-- Ed Avis ed@membled.com
If they follow the license and the ideals of open source are so pure than what's the problem?
Oh, that's right, it's Microsoft. That automatically makes it evil...
Give me a break.
MIT license is not a source-required license. Companies may sell, close it up, whatever they wish so long as they continue to give credit to the original product.
XML is like violence. If it doesn't solve the problem, use more.
Well.... a big part of its popularity is that it's a lightweight library, so maybe better if they don't contribute to it... :-)
Information wants to be beer.
jQuery is designed specifically to be extended, by the programming of plugins. Have a look at their plugin repository.
I find it highly unlikely that Microsoft would require anything adding to the jQuery core that couldn't be better implemented with a plugin.
I am NaN
it's slow, buggy, and prone to being abused. why are we still using it?
Slow? Not with the next generation of JIT JavaScript compilers coming up in Firefox 3.1, Google Chrome, and WebKit. And I'm sure IE will get there someday. Buggy? Not sure what you even mean by that... particular implementations may be buggy, but a programming language cannot itself be buggy. Prone to being abused? Which language isn't?
Said Googling does indeed show that your memory is playing a trick on you; it's Prototype that you're thinking of.
Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced."
This may provide a reason why the chose jQuery over prototype: http://blog.creonfx.com/javascript/dojo-vs-jquery-vs-mootools-vs-prototype-performance-comparison
jQuery is the core library, with widgets usually being distributed as independent packages, so it makes complete sense for them to do it this way.
jQuery's aim isn't to be the source for calendar and date-picker widgets, it's to provide a solid base to build those things on.
jQuery announced that the next version of their popular library will leverage the power and versatility of Microsoft(tm)(r) Silverlight(r) for delivering the next generation of .NET based media experiences and rich interactive applications for the Web.
"Freetards and other goddamn hippies need not apply." said jQuery's new maintainer, an oddly familiar, angry fat man. Going by the name of Stephan Ballmerano; he sports a beard, dark glasses, cape, and top-hat.
"I have done it before, and I'll do it again. I'm going to fucking kill the GPL!" Ballmerano replied to a question on licensing, before lifting the top-hat to mop his bald head with a hankie.
So those are only a few of the issues. It feels like it's trying to be several different languages all at once. Coupled with the issues above (particularly the inconsistent use of 'this' and the implicit semi-colons), well frankly, if any design could be considered buggy, I'd say that it's Javascript's.
You're basically arguing that since JS is not the language YOU want, its buggy. JS has its oddities, to be sure, but it is not "buggy" - its just very different. It also suffers from the same thing as PHP -- its easy to get into, but hard to master - so you get hundreds of thousands of shitty developers out there, and a handful of good ones. The shitty ones give the language a bad name, while the good ones build things like Gmail.
Learn about Photography Basics.
Sure, Microsoft has taken stuff that is under a liberal license in order to not have to write it themselves - the BSD TCP/IP stack from back in the day comes to mind.
But I believe this is something different. Even though this probably gives them some code they don't have to write, this is just to use a popular and growing JavaScript library to give ASP.NET MVC some much needed street cred, especially among open source leaning developers.
Though jQuery is better as a general JavaScript library than anything they've come up with, they've had no trouble writing this stuff for themselves before. This is a non-Microsoft developer focused thing that says: "We're cool! jQuery is in the box!" and tries to attract people to their stack by allowing them to leverage their skills with a library they've used elsewhere instead of some MS-only library.
I was a little bemused by the Microsoft guy's blog... last screenshot before the comments.
He needs to demo something non-trivial, so he switches to Firefox and Firebug.
Tell me about it, Scott!
Information wants to be beer.
Javascript is copyright just like anything else. Just because you can see the code doesn't mean you're free to use it for your own stuff. For example, you can not legally use non-free Javascript off of any random website.
I guess that it depends upon your definition of "buggy." You can design a language where the Integer object has a destructor named "toString" if you want to. And if someone did that, I would consider the design to be broken.
That's an extreme case, but it illustrates the point. Javascript takes common programming paradigms, structure, and syntax, and turns them on their heads. It would be nice if the designers had chosen to make Javascript look a little less C-like, but I suppose that it might not have gotten widespread adoption (despite mostly being used incorrectly due to the syntax).
The real key is that in Javascript, you can say that you want something, and you get something different from what you want. I'm harping on the typeof "bug" because it's the most obvious. I have an object of type Array. I ask Javascript for the typeof that object. I get returned object. Ok. I have an object of type Integer. I ask Javascript for the typeof that object. I get returned Integer. The lack of internal consistency there should be considered a bug.
Was evaluating JS frameworks for an open-source project, and ext js was precluded due to license. The project was BSD licensed, and thus neither the commercial nor GPL license was appropriate.
I understand their viewpoint (trying to make a business and community framework), but MIT licensed jQuery is much more amenable to other licenses.
I've always thought software vendors when doing open source would prefer GPL on stuff they put out (force commercial adopters to use a more commercial license), and that software vendors leeching on the community prefer BSD (lower obligation on them).
XML is like violence. If it doesn't solve the problem, use more.
<historyLesson>
This was a bug. The original implementation used tagged pointers and the tag bits for objects were zeroes. Null was also represented by zero. The typeof method forgot to treat null as a special case so, coincidentally, the type came out as object. Netscape tried to change this (and various other bugs) when ECMA standardized the language, but MS (who'd done an almost perfect job of reverse engineering the language) insisted on backwards compatibility.
</historyLesson>
The difference being, sparky, is that the source is not closed, you can read it. It maybe closed in terms of copyright, but it's still open in terms of source access. As opposed to closed, compiled binaries where the source is not available.
The discussion was about source code.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
I guess that it depends upon your definition of "buggy." You can design a language where the Integer object has a destructor named "toString" if you want to. And if someone did that, I would consider the design to be broken.
No, the definition of "buggy" is not open to interpretation. If your language defines a destructor named toString, then that is a feature of the language, not a bug. Any implementation which does not correctly implement it is therefore buggy, but the language itself is not.
Now, anyone is certainly free to argue whether a destructor named toString, or any particular feature of JavaScript, is a good idea, but saying that the language itself is "buggy" or "broken" is, by definition, incorrect.