Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Microsoft Programming Software IT Technology

Microsoft and Nokia Adopt OSS JQuery Framework 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.
This discussion has been archived. No new comments can be posted.

Microsoft and Nokia Adopt OSS JQuery Framework

Comments Filter:
  • Will they (Score:1, Troll)

    by Chrisq ( 894406 )
    Embrace, extend and then try to squeeze out the vanilla version though?
    • 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.

              • Re: (Score:3, Funny)

                by nschubach ( 922175 )

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

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

                  • 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.
                  • Closed source, for now. There's always the chance it will be opened in the future, but even if it was, there are other licenses to consider -- for example, we link against plugins which are MIT-licensed, and that's not GPL compatible.

                    And we do contribute back to open source projects we use. So, really, EXT's loss is jQuery's gain.

                    Now, the commercial license would be worth it. We're not against paying for things -- most of us use TextMate, for example, with legitimate licenses, and we have paid for Photoshop

                • Same thing here.. (Score:3, Interesting)

                  by Junta ( 36770 )

                  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

              • by orasio ( 188021 )

                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.

                • Re: (Score:3, Funny)

                  by WED Fan ( 911325 )

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

            by morgan_greywolf ( 835522 ) on Monday September 29, 2008 @07:35AM (#25192609) Homepage Journal

            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!
            • The MIT license doesn't prevent anyone else from doing that either.
            • 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.
              • 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.

                • by dkf ( 304284 )

                  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.

                  But if your business model depended on keeping the code confidential you wouldn't send it over the wire to browsers to execute, whatever the license says, since you can be sure that people will poke around and probably half-inch bits and pieces of it. If you want it confidential, you don't send the source to the user.

                  • If you are microsoft you would probably just LOVE it for some sucker to do that.
                    Because then you can nail them on copyright infringement if they become a significant competitor.

            • 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
              • And? What's wrong with that? I use Visual Studio in addition to a number of open-source tools. I think this is a great inclusion into Visual Studio.

          • Re: (Score:3, Insightful)

            by deander2 ( 26173 ) *

            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.

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

              by dedazo ( 737510 )

              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.

            • 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

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

          • 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: (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... :-)

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

          • I don't like the increase in size too, it used to be exactly right. One requirement for my ajax stuff is that page loading should feel instantaneous, not the feeling big libraries are loaded in the background, or even worse, show some ajax indicator. The 15K mentioned is indeed incorrect. That said, you confuse the minified version with the packed version. The packed version is much smaller, but has a relatively big client side penalty as decompression is done in javascript. When you have compression on the
      • 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@NOSPAM.webstarsltd.com> 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.

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

      • 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. jQu
        • there was apparently a good stir about jQuery at VSLive this year. One of the presenters even mentioned it during his talks.

          I know this is a welcome addition for me, as my employer just decided to start investigating doing this on our own.

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

    • Re: (Score:1, Funny)

      by Anonymous Coward

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

      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.

      • by zaydana ( 729943 )

        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 fmobus ( 831767 )

          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 o

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

        by thelawal ( 1099989 )
        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]
        • That's a very interesting article. So whilst Prototype is (marginally) faster on linux, in the grand scheme of things it's pretty poor.
        • 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.

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

          More

          • by FLEB ( 312391 )

            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 th

            • You don't need to seek 10000 times for the same element. You can look it up *once* and store it. Avoiding useless DOM traversal is the basic of javascript optimization.

              If your visual effects depends on traversing 10000 times the DOM in order to always find the same node, something is seriously broken in your code, not in the framework.

  • 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

  • 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?
    • It abstracts the more complex client-server interactions and lets you use a pre-built tool for such interactions rather than creating one yourself.

    • by Tweenk ( 1274968 )

      The most imprtant feature of jQuery is that you can select groups of HTML nodes using CSS selectors, and modify them in bulk with a single function call instead of iterating over some array. I didn't use it too much, but this approach is extremely powerful and simplifies code a great deal. There are also simple and usable Ajax APIs and other assorted goodies, but the CSS selector idea is really brilliant.

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

  • 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

    • 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

      • Undoubtedly Prototype is very nice as well. Never used it though, after Dojo (which was pretty heavy at the time, with lots of server requests) I decided to pick a new framework; jQuery and Prototype were the candidates at the time, and I picked jQuery. Not sure why I picked it over Prototype at the time, though, but this was already some time ago.

        Either way, the last part of your 'rewrite' seems to imply there are some specific cases where you'd pick Prototype over jQuery (or vice versa). Care to elaborate

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

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

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...