Slashdot Mirror
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.
Embrace, extend and then try to squeeze out the vanilla version though?
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
To have code submitted by all interested parties, since once it's open, it doesn't matter where the code came from.
All thing will one day be open, resistance is simply stupidity!
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.
Care to elaborate? I searched the bug tracker for http headers and Carewolf, but didn't see anything relevant, although that may be because the complete fuckwit who redesigned the website recently decided that it would be a good idea to use a font size that is half the size configured in the browser (flagged as !important no less). And no, don't tell me to adjust my settings. If I have to adjust my settings to make your design readable, then you have utterly failed as a designer on the most fundamental level. And I'm not a rock star, dickhead.
Because it is everywhere, including 100% of the browsers everyone already has installed.
that kind of applies to all scripting languages. Besides, how many others are embedded in the browser?
My memory could be playing a trick on me, but I think jQuery was the framework that used x-json. Just google x-json.
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."
Coincidentally, I was just looking through frameworks to use for a new project today and decided against using jQuery in favour of prototype and/or mootools.
jQuery has a very nice website, but implementations seems slow and clunky on my ubuntu/firefox set-up.
Why jQuery?
There's another way to kill such things: decommoditizing.
Make the thing so complex that no one is willing/able to move anymore. Watch this happening in the "open" W3C standards, in (M)OOXML, nearly everywhere nowadays (WebDAV, anyone?).
Kind of a denial-of-service attack. And the big corps have tons of resources to throw at this kind of game. They will always win.
The only defense is a Benevolent Dictator With Good Taste (TM)
And yet the baseless smear against jQuery is currently at 5, Interesting. Heckuva job, moddies.
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.
Yeah, I was going to say the same thing. Considering some of the smaller scale, and a few of the larger, OSS projects have code so badly written, so badly commented that obfuscated javascript looks easy to read by comparison, how do you close a JavaScript project?
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Nearly every gripe with Javascript stems from the first and last items on your list. 99% of the javascript I come across is written as if it is C, which causes all sorts of confusion with scope and efficiency.
Second and third, true enough, but Javascript is not alone.
Other languages with tons of theoretical cred share the newline/semicolon problems (Haskell, for example).
If more programmers understood functional idioms, Javascript wouldn't have such a bad reputation.
Prone to being abused? Which language isn't?
Javascript?
It is dangerous to be right when the government is wrong.
Nearly every gripe with Javascript stems from the first and last items on your list. 99% of the javascript I come across is written as if it is C, which causes all sorts of confusion with scope and efficiency.
Yes, and I think it's a bad design to model the statements of a language against a different language, but completely change the semantics. An extreme example would be using the '+' symbol for subtraction. But I don't think that the typeof issues I mentioned are fundamental to functional programming languages. And I don't think that reusing bad design (===) excuses the language just because "Javascript is not alone."
Other languages with tons of theoretical cred share the newline/semicolon problems (Haskell, for example).
I haven't seen many other languages do this, but I still think it's a bad design. I'm sure that every programmer occasionally drops a semi-colon, and when they do, whitespace may be a significant factor in how the statement is interpreted. Good languages can have crappy features.
If more programmers understood functional idioms, Javascript wouldn't have such a bad reputation.
Even within the context of a functional language, I think that Javascript has some design problems that aren't going to go away (at least) due to legacy. A functional language can still return a useful type when you ask for it. A functional language does not have to have implicit semi-colons. A functional language can use different identifiers instead of three contextually different uses of 'this'.
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.
this is consistent, and its meaning is always dependent on context. It always refers the the instance the method was called for. If there is no instance specified, the global instance is used (which is also named window in a web browser).
Just because this isn't consistent with other languages use of this doesn't mean its not consistent.
JavaScript is a strongly typed, dynamic language. There is nothing weakly typed about it (though some operators perform automatic conversion, which I dislike in any language).
Unfortunately, it is trying to be multiple languages all at once (Schema with C/Java syntax). But I think that's forgivable.
I'm just getting into the use of JavaScript for server and client interactions. I've been pretty impressed with what's available when you take the class-like approach. For the most part, I have had no issues with JavaScript browser differences (well, back to IE 6 anyway) It appears jQuery would make my scripts smaller, but I can do that by packing my scripts too. Why should I use a library that redefines what JavaScript does so well already on its own?
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.
Apparently this news brought so much traffic to jquery.com the site has been inaccessible for me for more than two hours. !!
Congratulations to everybody who has worked on jQuery!
I have used jQuery extensively and it is easy to learn and easy to handle. In fact, I had been using JavaScript for quite a while before jQuery, but after I started using jQuery, read some source, wrote a few plugins, etc. (even some patches, including performance related ones), I feel my understanding of the weird and advanced things in JavaScript is also much much better - and it didn't require any hard work or thinking :)
In comparison, before jQuery I used Dojo, which still gives me a headache just to think about. This is now some time ago though, so I will not bash Dojo as it's quite likely my specific problems with it have long been solved. However, Dojo never 'invited' me to become better at JavaScript myself.
All in all, jQuery is a great tool, it makes JavaScript fun again, and it makes me feel sorry I'm hardly doing any webdevving anymore (imagine that!)
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.
Arguments over the use of "this" aside, I guess that strong vs. weak typing is somewhat subjective. Wikipedia implies that there's plenty of debate and wiggle-room over what qualifies as a strongly typed language. There's enough implicit casting in the language for me to consider it weakly typed. In fact, this was a design decision so that Javascript would be easy to use for non-programmers.
Just saying until they act, we can not guarantee based solely on the license what they will do. They do say they will, but the legal obligations upon them do not mandate it.
MIT license is fine, but you cannot predict traditional open-source sensibilities solely from an announcement mentioning the licens..
XML is like violence. If it doesn't solve the problem, use more.
null.typeof returns 'object'. So does Array.typeof. That's just ... dumb.
So's your face.
And I realized that you're just being a dick. Call me back if you want to have a real discussion on the merits of Javascript as a language. Until then, go to hell.
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.
The good news is that nobody's forcing you to program in it.
<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>
Actually, I was making fun of the fact that you had no argument either. It was my way of saying that you had no substance to that particular point, therefore any response to the contrary need not have any substance. I chose "so's your face" because the fact that I've never seen your face would add a little extra stupidity to the comment. For all I know, you had your face switched with John Travolta's and are, therefore, quite a good looking man.
Nokia does the work and M$ stands on the sidelines passive-aggressively finding ways to throw sand in the gears and share in the glory of anything they are unable to block.
It's great that Nokia is working on jQuery, but the leaders are dumb funkers if they think that they will be the first to come out the better for a partnership with M$. JQuery could be good for Nokia if they are not chumps for M$.
Javascript ... The good news is that nobody's forcing you to program in it.
If you want to write software for the web, this is not so; you have to know and use some javascript. The good news, some of that code is now jQuery's problem.
My Karma: ran over your Dogma
StrawberryFrog
Fascinating. Microsoft finally gets something right (reverse engineering correctly) and in the process, they manage to copy a bug. Thanks for the lesson.
I think the main reason for jQuery and Prototype is to insulate the programmer from browser idiosyncrasies. And Microsoft's IE (mostly IE6) is the main cause of them!!!
I just had horrifying visions of MS jQuery .Net Visual Studio Professional.
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
On the speed front: that isn't sufficient enough of a reason, and here's why:
On the "extendable/modular" front: I don't feel this is sufficient either, and here's why:
MT and jQuery, in my opinion, are the best two frameworks available today for javascript developers - and I would like to say personally that I don't know anything about dojo, so unfortunately I have left it out of consideration. However, from my understanding, jQuery has more educational resources available both online and in print. Why? I don't really have the answer to that question. It could be that people who are inclined to write books about the subject like jQuery's style of coding more (although I like mooTools more), or perhaps it could be that jQuery is more "javascript-oriented", while mooTools tries to make javascript "object-class-oriented".
.NET anyway.
One point I will concede is that jQuery allows multiple versions of itself to be instantiated on the same page, while mooTools really does not - although you can instantiate versions of mooTools in iframes and get away with it. However, personally, I prefer mooTools' approach. Having more than one version of a framework on a webpage - to me - is a maintainence nightmare, although I'm *positive* it sounds *delightful* to buisness people. Hence, I believe these two reasons (multiple instantiations, publications) are why jQuery was picked.
Overall, though, I'm not miffed. jQuery is my second-favorite framework, and I don't develop much
I understand the frustration on the "an Array is an Object", and I'll raise you one - there are no such things as associative arrays in Javascript.
I see it all the time in tutorials - well, check this out: If I say var foo['first'] = 'first value' what I've really said is "Of the object referenced by 'foo', update the property 'first' to contain the string 'first value'." Since an Array is an Object, this is what happens when you try to assign text indexes to an array!
After that, if you go back do a foo.length, it will return zero - because you've assigned a property, not an index.
Javascript is certainly different, but I don't feel it is broken. That's sort of like saying Python is broken because variables don't "contain" data, but reference it. Learning to do string manipulation in Python will make you want to pull your hair out until you go back and read the docs thoroughly.
Learn about Photography Basics.
I'd forgotten about that one, but yes, that bugs me, too. It's slightly less irritating to me since Javascript doesn't explicitly declare an Associative Array object. But they do declare an Array object, so it seems to me that the typeof should return 'array' just like it does for strings, dates, etc.
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.
that's good enough reason for me to never use it.
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.
While you're correct about "buggy" (which describes a deviation between specification and implementation), you're way wrong about "broken". Things most certainly can be "broken by design", which refers to the state of things when a specification says something that just can't be argued to be correct without the application of hallucinogens.
Whether or not JS fits that bill is a matter of debate. (I'm not too fussed either way there TBH; I just prefer to use other things.)
"Little does he know, but there is no 'I' in 'Idiot'!"
These are all pretty subjective points. Some would consider C syntax a feature - why subject programmers to learning your favorite functional language's syntax? (Not that JS is pure functional either; you can easily have assignments and write imperative code.) Implicit semicolons - I've *never* been bitten by this, and languages like Ruby do it too without causing serious trouble. Just don't write more than 1 statement per line please. Typeof - just check for == null? JavaScript is weird in some areas, but it's also really good at facilitating web app development for people who already know C++/Java/C#/etc (virtually any programmer). If you think JS is buggy, then C++ must be a nightmare, but hey, it's only the next most popular language after JavaScript.
but all the shitty microsoft-based sites that were thrown up in a day that will be including jQuery UI elements. Users will begin to see jQuery elements and associate them with shitty websites and they will become considered tacky/cliche despite their quality and usefulness. This is what I fear.
LS
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
JS is actually a very decent language, it you don't go into it with certain pre-conceptions as to what to expect. It has more in common with things like Scheme than C...
The things you've listed are, by and large, opinion.