Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Microsoft and Nokia Adopt OSS JQuery Framework

Posted by timothy on Mon Sep 29, 2008 06:36 AM
from the ms-could-become-the-largest-open-source-vendor dept.
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.
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Anonymous Coward

    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.

  • Just makes sense... (Score:5, Interesting)

    by Max Romantschuk (132276) <max@romantschuk.fi> on Monday September 29 2008, @06:43AM (#25192355) Homepage

    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?

    • by VGPowerlord (621254) on Monday September 29 2008, @07:17AM (#25192517) Homepage

      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.

      • 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 b

      • by Bogtha (906264) on Monday September 29 2008, @07:27AM (#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.

  • by Anonymous Coward

    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

  • by tcr (39109) on Monday September 29 2008, @09:50AM (#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!

  • 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

    • Re:Will they (Score:5, Insightful)

      by Ed Avis (5917) <ed@membled.com> on Monday September 29 2008, @06:49AM (#25192381) Homepage

      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... (Score:5, Informative)

        by Junta (36770) on Monday September 29 2008, @07:03AM (#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... (Score:5, Informative)

          by StrawberryFrog (67065) on Monday September 29 2008, @07:15AM (#25192505) Homepage Journal

          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... (Score:4, Insightful)

            by dwarfking (95773) on Monday September 29 2008, @07:27AM (#25192571) Homepage

            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... (Score:5, Insightful)

              by kripkenstein (913150) on Monday September 29 2008, @08:47AM (#25193143) Homepage

              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.

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

              • 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

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

                • 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 so

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

            • 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: (Score:2, Insightful)

                by Anonymous Coward

                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.

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

          • 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... (Score:4, Funny)

              by wilder_card (774631) on Monday September 29 2008, @07:54AM (#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!
            • 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 anyt
              • 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.

          • Re: (Score:3, Insightful)

            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!

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

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

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      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.
      • by tcr (39109) on Monday September 29 2008, @07:11AM (#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... :-)

      • 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 (Score:4, Informative)

          by Jellybob (597204) on Monday September 29 2008, @08:18AM (#25192903) Journal

          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 (Score:4, Informative)

      by Phil John (576633) <phil@webstarsltdSTRAW.com minus berry> on Monday September 29 2008, @07:15AM (#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.

    • 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?

    • by tobiasly (524456) on Monday September 29 2008, @07:30AM (#25192589) Homepage

      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?

      • by Sancho (17056) * on Monday September 29 2008, @08:40AM (#25193081) Homepage
        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.

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

          • 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 su

        • Re: (Score:3, Insightful)

          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: (Score:3, Interesting)

            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 hav
            • Re: (Score:3, Insightful)

              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 definitio

      • Prone to being abused? Which language isn't?

        Javascript?