Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft and Nokia Adopt OSS JQuery Framework

timothy posted more than 5 years ago | from the ms-could-become-the-largest-open-source-vendor dept.

Microsoft 126

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.

cancel ×

126 comments

Will they (0, Troll)

Chrisq (894406) | more than 5 years ago | (#25192325)

Embrace, extend and then try to squeeze out the vanilla version though?

Re:Will they (4, Insightful)

Ed Avis (5917) | more than 5 years ago | (#25192381)

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.

But... (5, Informative)

Junta (36770) | more than 5 years ago | (#25192449)

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.

Re:But... (4, Informative)

StrawberryFrog (67065) | more than 5 years ago | (#25192505)

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.

And is that relevant? This issue has been addressed:

Scott Guthrie says: [asp.net]
"We will distribute the jQuery JavaScript library as-is, and will not be forking or changing the source from the main jQuery branch."

The Scott Hanselman says: [hanselman.com]
"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."

Re:But... (3, Insightful)

dwarfking (95773) | more than 5 years ago | (#25192571)

Outside of obfuscation, how exactly do you close source a JavaScript library that your browser can access via HTTP? I suppose Microsoft could incorporate it directly into the browser, but that doesn't seem likely.

Re:But... (4, Insightful)

kripkenstein (913150) | more than 5 years ago | (#25193143)

Outside of obfuscation, how exactly do you close source a JavaScript library that your browser can access via HTTP? I suppose Microsoft could incorporate it directly into the browser, but that doesn't seem likely.

"Close" can mean two things here. Yes, the source will remain visible, since its Javascript. So that's one sense of "open". However, it doesn't need to remain open source in the sense of the license. Microsoft could, in theory, add some features and relicense it under proprietary terms; the MIT license allows that. That is, seeing the source doesn't mean it's open source in the licensing sense.

Happily, Microsoft announced that they won't change the license.

Re:But... (2, Funny)

nschubach (922175) | more than 5 years ago | (#25193317)

I suppose Microsoft could incorporate it directly into the browser, but that doesn't seem likely.

Microsoft could, in theory, add some features and relicense it under proprietary terms; the MIT license allows that. That is, seeing the source doesn't mean it's open source in the licensing sense.

Say hello to Microsoft DirectHTML!

Re:But... (2, Interesting)

SanityInAnarchy (655584) | more than 5 years ago | (#25193343)

In fact, this has already happened to a Javascript library: EXTJS. Not quite in the sense you're talking about -- it was GPL'd -- but we still had to port away from it.

We might've been willing to release some of the Javascript source -- after all, GP is right, it's not like we can hide it -- but the author was claiming it applied to the web app serving the Javascript, also.

Although that's patently absurd, it's also untested in court, and it proved that he's exactly the kind of assmunch we don't want to work with. We've just finished porting everything to jQuery and MooTools. Probably better off for it.

Re:But... (1)

foniksonik (573572) | more than 5 years ago | (#25193773)

Uh you did look and see that ExtJs has a commercial license and always has had one, which you could use to create a proprietary blend with?

Not saying your decision was rash or unfounded, just wanted to point out to the discussion that Ext and Josh Shlocum considered their options and chose to offer dual licenses as there was not a single license available which met their needs.

That being said, good luck with that closed source thing you've got going on...

Re:But... (2)

larry bagina (561269) | more than 4 years ago | (#25196139)

It was dual licensed (commercial or LGPL) before the switch to (commercial or ) GPL. I don't know if they gave a coherent reason for the switch (although it was probably to discourage use of the free version) but they did make some bizarre claims about what needed to be GPL (which hasn't been tested in court) although I think they later got a little more realistic about server side being unaffected.

Same thing here.. (2, Interesting)

Junta (36770) | more than 5 years ago | (#25194189)

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).

Re:But... (1)

orasio (188021) | more than 5 years ago | (#25193611)

Well, it might even be open source. You get the source, and you can change it.
That is why "open source" is an unfortunate term.
It would not be free software, because the user would be some freedoms short.

Re:But... (0)

Anonymous Coward | more than 4 years ago | (#25196307)

Happily, Microsoft announced that they won't change the license.

Saying and doing are two different things.

Yeah, I was... (1)

WED Fan (911325) | more than 5 years ago | (#25193159)

Outside of obfuscation

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?

Re:Yeah, I was... (2, Insightful)

Anonymous Coward | more than 5 years ago | (#25193865)

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.

Re:Yeah, I was... (2, Funny)

WED Fan (911325) | more than 5 years ago | (#25195033)

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.

Re:But... (5, Insightful)

morgan_greywolf (835522) | more than 5 years ago | (#25192609)

What he's saying is that although Microsoft will be distributing the JQuery framework as-is, they may decide to use it in a closed-source product, with custom changes that don't get sent upstream. I'm not saying that Microsoft will do that, because I'm not in a position to speak for them, but it would definitely not be outside of their usual MO. Furthermore, parents point is that there is nothing in the MIT license that prevents them from doing this. Whether you agree with the philosophy of the MIT license or not is out of scope and off-topic.

Re:But... (4, Funny)

wilder_card (774631) | more than 5 years ago | (#25192721)

"Whether you agree with the philosophy of the MIT license or not is out of scope and off-topic."
In other words: It's time to start a flame war! Right here! Right now!

Re:But... (0)

Anonymous Coward | more than 5 years ago | (#25192845)

You smell bad and your ideas are stupid.

Re:But... (1)

larry bagina (561269) | more than 5 years ago | (#25192751)

The MIT license doesn't prevent anyone else from doing that either.

Re:But... (2)

morgan_greywolf (835522) | more than 5 years ago | (#25193859)

And? Do you want a cookie for pointing that out, or do you actually have a point?

Re:But... (1)

DrJokepu (918326) | more than 5 years ago | (#25193093)

Due to the client-side script nature of JavaScript, I am struggling to be able to imagine a situation where it makes sense to release jQuery or any other JavaScript web library as closed source.

Re:But... (1)

Jah-Wren Ryel (80510) | more than 5 years ago | (#25193191)

Due to the client-side script nature of JavaScript, I am struggling to be able to imagine a situation where it makes sense to release jQuery or any other JavaScript web library as closed source.

Just because you can access the source doesn't mean you have license to do anything with it. There own extensions, especially if contained in separate source files, do not need to be covered by the same license.

This is just for cred (3, Insightful)

LeedsSideStreets (998417) | more than 5 years ago | (#25193727)

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.

Re:But... (2, Insightful)

deander2 (26173) | more than 5 years ago | (#25193015)

yes, because we all know how trustworthy microsoft is when it comes to keeping their promises...

heck, why bother with OSS licenses at all? just trust companies during the "embrace" stage, and i'm sure nothing else will come of it!

Re:But... (1)

sgt scrub (869860) | more than 5 years ago | (#25193583)

Submitting a patch and that patch being useful to anyone using a non-windows platform are two different things.

Re:But... (1)

Captain Arr Morgan (958312) | more than 5 years ago | (#25194181)

But as a web app developer, isn't getting patches for any browser useful? If you look at the jQuery bug track, many of the outstanding bugs are IE related. It will be very nice if Microsoft takes it upon themselves to fix these, benefiting anyone using the framework in the real world.

Re:But... (2, Insightful)

dedazo (737510) | more than 5 years ago | (#25194925)

That's right, in a few months Microsoft will submit a patch that ties jQuery hopelessly to IE8... and no one will notice.

Such things tend to happen with projects with no oversight and no established community, of which jQuery is clearly a shining example.

Re:But... (1)

StrawberryFrog (67065) | more than 5 years ago | (#25194939)

Submitting a patch and that patch being useful to anyone using a non-windows platform are two different things.

JavaScript doesn't run on windows, it runs on browsers.

The Asp.Net team, from whom this announcement comes, have been pretty good for the last few years in making sure that their stuff works in the big 4 browsers: IE, Firefox, Safari, Opera. So their patches would have to work in Firefox and Safari to pass MS internal QA. You can then run it on Windows, Linux, Mac, whatever.

To be cynical, you could say that this is because the ASP.NET team care about selling the server side: Visual Studio licences, IIS installations, and SQL server licences, but that's business and is besides the point; they don't care which browser you use.

I hope that gets you over your paranoia.

Re:But... (1)

ericlondaits (32714) | more than 5 years ago | (#25192729)

So, should they distribute under a more restricted license in order to show everyone how open they are?

Not saying that... (1)

Junta (36770) | more than 5 years ago | (#25194135)

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..

Re:Will they (2, Interesting)

Anonymous Coward | more than 5 years ago | (#25192445)

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.

Re:Will they (5, Funny)

tcr (39109) | more than 5 years ago | (#25192489)

Well.... a big part of its popularity is that it's a lightweight library, so maybe better if they don't contribute to it... :-)

Not so funny [was: Will they] (0)

Anonymous Coward | more than 5 years ago | (#25192695)

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)

Re:Will they (1)

not already in use (972294) | more than 4 years ago | (#25195179)

a big part of its popularity is that it's a lightweight library

Last time I checked, it was ~50kb, minified, and included all sorts of visual effects that I have no desire to use. I wouldn't call that lightweight. Why any of the visual stuff is part of the core distribution is beyond me.

Re:Will they (1)

gbjbaanb (229885) | more than 5 years ago | (#25192635)

If......

from TFA:
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

so much for "if we want changes, we'll submit a patch like everyone else"

Re:Will they (3, Informative)

Jellybob (597204) | more than 5 years ago | (#25192903)

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.

Re:Will they (1)

Captain Arr Morgan (958312) | more than 5 years ago | (#25194279)

How is this different from anyone else writing a plugin to interface with their system? If I have some proprietary backend that I extend jQuery to work with, what use is this to anyone else?

Re:Will they (1)

plague3106 (71849) | more than 4 years ago | (#25195483)

It's pretty clear you've never seen asp.net, or you'd realize how silly your comment was.

Re:Will they (3, Informative)

Phil John (576633) | more than 5 years ago | (#25192503)

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.

Re:Will they (1)

sortius_nod (1080919) | more than 5 years ago | (#25193037)

Where there's a will there's a way... where there's Microsoft you can bet your arse they'll try to proprietry it.

Re:Will they (0)

Anonymous Coward | more than 5 years ago | (#25194405)

to proprietry

Stop verbing your nouns, you sound silly enough as it is.

Re:Will they (1)

PietjeJantje (917584) | more than 5 years ago | (#25194973)

Moreover, these are different times. Balmer just admitted that Microsoft lost a generation of programmers who now build web apps using more open tools. They want to appeal to those developers. Embrace and extend is not an option, that is what scared them away, among others. We've seen the new two-faced MS before. I'm not sure where this limbo dance will take them. But I don't think it's a coincidence that this is announced just a few days later, it is exactly the new MS as Balmer likes us to see them. jQuery is no threat to .NET, just an addition. Their new strategy is simply: combine. I guess they're hoping that's good enough for a lot of developers.

Same ol' embrace, extend, extinguish? (2, Informative)

Anonymous Coward | more than 5 years ago | (#25192339)

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.

Re:Same ol' embrace, extend, extinguish? (1, Funny)

Anonymous Coward | more than 5 years ago | (#25192639)

Oh noes they take a open source project and want to use it for their own intend. Damn those devils! Open Source Software does not want to be used, it wants to be free!

Just makes sense... (4, Interesting)

Max Romantschuk (132276) | more than 5 years ago | (#25192355)

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?

Re:Just makes sense... (3, Insightful)

VGPowerlord (621254) | more than 5 years ago | (#25192517)

Also, will the jQuery API eventually be integrated into the browser instead of being a huge JS blob for every page?

I imagine not, since it would make upgrading a major pain. As long as the site controls which version of jQuery you have, they can opt in to the latest and greatest version without having to wait for the browser manufacturers.

Re:Just makes sense... (1)

zaydana (729943) | more than 5 years ago | (#25192551)

True, although it would be interesting if future browsers could detect certain versions of jQuery via the <script> tags in webpages, and accelerate those versions. That way, the latest version could always be included if needed, but for older versions browsers could provide a native implementation.

Of course, that doesn't mean its a good idea. If Microsoft managed to fuck up CSS, JavaScript and pretty much everything they have implemented so far, I sure as hell don't think they'd implement jQuery any better.

Re:Just makes sense... (4, Informative)

Bogtha (906264) | more than 5 years ago | (#25192569)

jQuery is entirely contained within its own namespace. Multiple versions of jQuery can coexist on the same page, so upgrades wouldn't be a problem, sites could just include the latest version if the version shipped with browsers wasn't suitable.

Re:Just makes sense... (1)

fmobus (831767) | more than 5 years ago | (#25194971)

One thing I would like to see in the future is some apt-like repository for commonly used javascript libraries. E.g., if I use Yahoo! js libs, the page would just ask for whatever lib version it was designed for, and the browser would load it from a local repository. Some libs are huge, and there should be no need for downloading it again and again from different sites.

Of course, this could be done today by simply point the src attribute in your script tag to yahoo's repository, but this would not be good on yahoo's bandwidth. Also, this would require some standarization across multiple browsers, which is something we know is not happening any time soon.

Re:Just makes sense... (1)

mounthood (993037) | more than 4 years ago | (#25195293)

If sites link the Google API version you only have to download it once, even if you go to multiple sites that use it. The sites can also have automatic security updates by only specifying a major.minor version number.

http://code.google.com/apis/ajaxlibs/ [google.com]
From the site:

The AJAX Libraries API is a content distribution network and loading architecture for the most popular open source JavaScript libraries. ... We take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.

Contrast the following with Microsoft's statement:

Google works directly with the key stake holders for each library effort and accept the latest stable versions as they are released. Once we host a release of a given library, we are committed to hosting that release indefinitely.

Re:Just makes sense... (0)

Anonymous Coward | more than 4 years ago | (#25195815)

[...] will the jQuery API eventually be integrated into the browser instead of being a huge JS blob for every page?

This isn't really needed. You can achieve nearly the same effect by referencing a version-qualified URL for the library and setting an infinite cache time.

In other news ... (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#25192375)

hell freezes over and pigs fly!

Isn't this exactly what was wanted? (0)

Anonymous Coward | more than 5 years ago | (#25192395)

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!

Will they fix it? (-1)

Carewolf (581105) | more than 5 years ago | (#25192477)

Hopefully they will fix JQuery to make it stop abusing HTTP headers, and act more standard compliant. It is one of the major issues with jQuery that it transmits data in the headers where it doesn't belong. Among other things this breaks at various point in various browsers; 4k in IE, 8k in Firefox, plus it breaks most types of HTTP caches.

Re:Will they fix it? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25192547)

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.

Re:Will they fix it? (1)

Carewolf (581105) | more than 5 years ago | (#25192585)

My memory could be playing a trick on me, but I think jQuery was the framework that used x-json. Just google x-json.

Re:Will they fix it? (4, Informative)

Chaos Incarnate (772793) | more than 5 years ago | (#25192621)

Said Googling does indeed show that your memory is playing a trick on you; it's Prototype that you're thinking of.

Re:Will they fix it? (1, Funny)

Anonymous Coward | more than 5 years ago | (#25192701)

And yet the baseless smear against jQuery is currently at 5, Interesting. Heckuva job, moddies.

pity JS is crap to start with (-1, Troll)

timmarhy (659436) | more than 5 years ago | (#25192541)

it's slow, buggy, and prone to being abused. why are we still using it?

Re:pity JS is crap to start with (1)

cryfreedomlove (929828) | more than 5 years ago | (#25192553)

Because it is everywhere, including 100% of the browsers everyone already has installed.

Re:pity JS is crap to start with (1)

gbjbaanb (229885) | more than 5 years ago | (#25192559)

that kind of applies to all scripting languages. Besides, how many others are embedded in the browser?

Re:pity JS is crap to start with (3, Insightful)

tobiasly (524456) | more than 5 years ago | (#25192589)

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?

Re:pity JS is crap to start with (3, Interesting)

Sancho (17056) | more than 5 years ago | (#25193081)

The programming language itself has many, many problems.
  • It's a fully functional language which uses a syntax almost identical to C.
  • It implements the awful === operator.
  • Boolean values can be True, False, Undefined, or Null (this is a side effect of being weakly typed)
  • It tries to be easy to program by assuming end-of-statement operators (';') at certain places if the function wouldn't otherwise parse. This makes it incredibly difficult to debug. I truly consider this a bug in the design.
  • It's a weakly typed language with a strong understanding of type. By this, I mean that any variable is actually a reference which can hold values of any type (though they're all just objects anyway.) This isn't so much a bug as a design decision, but it's important for understanding the below--
  • null.typeof returns 'object'. So does Array.typeof. That's just ... dumb.
  • The object which 'this' references has several different meanings depending upon the context.

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.

Re:pity JS is crap to start with (1)

daemonburrito (1026186) | more than 5 years ago | (#25193315)

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.

Re:pity JS is crap to start with (1)

Sancho (17056) | more than 5 years ago | (#25193665)

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'.

Re:pity JS is crap to start with (3, Insightful)

lwsimon (724555) | more than 5 years ago | (#25193689)

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.

Re:pity JS is crap to start with (2, Interesting)

Sancho (17056) | more than 5 years ago | (#25193955)

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.

Re:pity JS is crap to start with (1)

lwsimon (724555) | more than 4 years ago | (#25196223)

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.

Re:pity JS is crap to start with (0)

Anonymous Coward | more than 5 years ago | (#25193741)

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.

Re:pity JS is crap to start with (1)

Sancho (17056) | more than 5 years ago | (#25194079)

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.

Re:pity JS is crap to start with (-1, Troll)

moderatorrater (1095745) | more than 5 years ago | (#25193997)

It's a fully functional language which uses a syntax almost identical to C

And then you have a gripe about using "this"? Javascript and C are extremely dissimilar, and if you can't figure that out then don't program in it. Might as well be complaining that python, C++, and Java all have syntax almost identical to C yet act differently under difference circumstances.

It tries to be easy to program by assuming end-of-statement operators (';') at certain places if the function wouldn't otherwise parse. This makes it incredibly difficult to debug. I truly consider this a bug in the design.

I think it's dumb too, but then again I think that the way C-like languages ignore whitespace is also kind of dumb. Modern written languages use white space to denote many things and it's carefully controlled and used. Programming languages ignore almost all white space; how does that make sense? I'm not saying that Javascript is right in this instance, but making white space meaningful shouldn't automatically mean it's bad.

null.typeof returns 'object'. So does Array.typeof. That's just ... dumb.

So's your face.

It feels like it's trying to be several different languages all at once

That's your problem. Stop thinking about Javascript as other languages and think about it as a language all its own. If I tried to program in C as if it were Java, I'd have a hell of a time doing it too. Javascript follows a different paradigm, and if you come at it with preconceptions like you evidently have, you're going to have problems.

Re:pity JS is crap to start with (1)

Sancho (17056) | more than 5 years ago | (#25194179)

You know, I had a well-reasoned, civil responses to most of your post. Then I got to this:

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.

Re:pity JS is crap to start with (1)

moderatorrater (1095745) | more than 5 years ago | (#25194569)

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.

Re:pity JS is crap to start with (1)

discord5 (798235) | more than 5 years ago | (#25194451)

The good news is that nobody's forcing you to program in it.

Re:pity JS is crap to start with (1)

StrawberryFrog (67065) | more than 5 years ago | (#25194785)

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.

Re:pity JS is crap to start with (2, Interesting)

Anonymous Coward | more than 5 years ago | (#25194547)

<historyLesson>

null.typeof returns 'object'

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>

Re:pity JS is crap to start with (1)

Sancho (17056) | more than 5 years ago | (#25194801)

Fascinating. Microsoft finally gets something right (reverse engineering correctly) and in the process, they manage to copy a bug. Thanks for the lesson.

Re:pity JS is crap to start with (1)

dotancohen (1015143) | more than 5 years ago | (#25193329)

Prone to being abused? Which language isn't?

Javascript?

Coincidentally (1)

Redlemons (1313923) | more than 5 years ago | (#25192623)

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?

Re:Coincidentally (1)

PenguSven (988769) | more than 5 years ago | (#25192691)

Because jQuery is like XML (or JSON these days), Web 2.0 and AJAX. If you don't have it on your CV these days, you should convince your current employer they need to use it so you can add it to your CV.

Re:Coincidentally (3, Informative)

thelawal (1099989) | more than 5 years ago | (#25192773)

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 [creonfx.com]

Re:Coincidentally (1)

Redlemons (1313923) | more than 5 years ago | (#25193007)

That's a very interesting article. So whilst Prototype is (marginally) faster on linux, in the grand scheme of things it's pretty poor.

Re:Coincidentally (1)

foniksonik (573572) | more than 5 years ago | (#25193855)

My biggest problem with Prototype is that it doesn't play nice (last time I checked) with other libraries and you have to jump through hoops to do so.

Re:Coincidentally (1)

modmans2ndcoming (929661) | more than 4 years ago | (#25195653)

And according to Hannselminutes from last week (I think , I am backlogged a bit) ASP.Net Ajaxs works very well with jQuery.

Re:Coincidentally (1)

chrysalis (50680) | more than 5 years ago | (#25194679)

It would be a very stupid reason to pick a framework over another one.

Your link shows results from a benchmark. What does that benchmark? It just benches the speed of selectors.

It tries tons of times to fetch DOM nodes from a fixed definition like "a A in a P in a DIV".

If your application heavily depends on the framework's ability to fetch 10000 times the same element the same way, there's something really wrong with it.

I can't understand how Javascript frameworks can be compared using such a benchmark.

Moreover the Selectors API is coming to browsers, so this is going less and less significant. Prototype 1.6.0.3 (released today) supports it, every other frameworks will soon do.

The real difference between frameworks in the time you need to build the app you need with them.

When it comes to playing with the DOM and building visual components, jQuery is great.

When it comes to working with data structures, Prototype fits like a glove, way much than jQuery.

Re:Coincidentally (1)

FLEB (312391) | more than 5 years ago | (#25194991)

Running 10,000 queries isn't a benchmark because it's a likely use of the library, it's a benchmark because 10,000 queries will create measurable timing differences where the difference in each one is too small to measure. An immeasurable timing difference might not seem like much, but for effects that have to run smoothly or synchronized, it can create undesirable visual effects. I've seen the difference in MooTools versus jQuery, for instance, in that a MT app often has smoother motion and fade effects than jQ.

In other news (2, Funny)

Anonymous Coward | more than 5 years ago | (#25192983)

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.

jQuery vs. JavaScript "classes" (1)

xdor (1218206) | more than 5 years ago | (#25193763)

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?

Re:jQuery vs. JavaScript "classes" (1)

modmans2ndcoming (929661) | more than 4 years ago | (#25195709)

It abstracts the more complex client-server interactions and lets you use a pre-built tool for such interactions rather than creating one yourself.

Not eating the dogfood? (2, Insightful)

tcr (39109) | more than 5 years ago | (#25193767)

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!

JQuery site down???? (1)

Amamdouh (1130747) | more than 5 years ago | (#25193775)

Apparently this news brought so much traffic to jquery.com the site has been inaccessible for me for more than two hours. !!

Re:JQuery site down???? (1)

SirJorgelOfBorgel (897488) | more than 5 years ago | (#25193925)

That's not uncommon even if the the site isn't slashdotted. It's getting a lot better, though :)

That's great! (1)

SirJorgelOfBorgel (897488) | more than 5 years ago | (#25193919)

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!)

Re:That's great! (1)

dedazo (737510) | more than 5 years ago | (#25194475)

Agreed, and I have to say I'm happy for ASP.NET. I used Prototype for a while when the Ajax craze first started and I ended up switching to jQuery. Smaller, faster, better designed.

Congratulations to the authors indeed. It's not easy to get $LARGE_COMPANIES to use things like these, let alone advertise the fact that they are using them or actually incorporate them into their existing products.

Re:That's great! (1)

chrysalis (50680) | more than 5 years ago | (#25194867)

Also songratulations to everybody who has worked on Prototype!

I have used Prototype extensively and it is easy to learn and easy to handle. In fact, I had been using JavaScript for quite a while before Prototype, but after I started using Prototype, 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 Prototype 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, Prototype is a great tool, it makes JavaScript fun again, and it makes me feel sorry I'm hardly doing any webdevving anymore (imagine that!)

jQuery is a great tool, too. It all depends on the application you are working on.

Nokia does the work and MS ... (0)

Anonymous Coward | more than 5 years ago | (#25194725)

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$.

Isn't IE the problem (1)

hey (83763) | more than 4 years ago | (#25195343)

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!!!

Bleh... (1)

spottedkangaroo (451692) | more than 4 years ago | (#25195647)

I just had horrifying visions of MS jQuery .Net Visual Studio Professional.

Speed isn't the real reason- its documentation (1)

mckinnsb (984522) | more than 4 years ago | (#25195983)

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 [creonfx.com] [creonfx.com]

On the speed front: that isn't sufficient enough of a reason, and here's why:

  • The benchmarks are based on DOM selector tests. The code for the benchmark is not provided, so we don't really know in what manner he selected DOM elements, or if he even used the elements after selecting them. For instance: mooTools may be slower in picking a DOM element the first time, but part of the reason why it is slower is because it automatically extends the element to be of object type Element (with all functions associated - which is extremely convenient because you often want to operate on the element after selecting it) unless you tell it not to. There is a chance that he didn't tell mooTools to not extend the object. In addition, mooTools also adds the element to Hash object of all elements that are already extended - so you don't have to extend it twice. If he selected DOM elements twice in his benchmark, or had another benchmark that only focused on selecting elements twice, MT might be faster.
  • MT in this benchmark is in beta - its stable now. I'd like to see another benchmark with varied tests (see above) across more browsers to properly come to the conclusion that MS picked jQuery for speed. I'm assuming here that most people at MS are smart enough to understand the above.
  • If they picked jQuery for speed, why didn't they pick dojo for speed?

On the "extendable/modular" front: I don't feel this is sufficient either, and here's why:

  • MT is just as extendable as jQuery. It is also just as modular as jQuery. Both are similar in terms of size, depending on your options. (Your mileage may vary.)
  • Prototype is fairly extendable, although in its recent incarnation , it can hardly be called "lightweight while being extendable" - see Scriptaculous.
  • By definition, javascript is a prototypical inheritance language, automatically lending extendability or modularity to nearly any framework. Thats the beauty of JS.

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".

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 .NET anyway.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...