Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Google Software Technology

Google Releases Open Source JavaScript Tools 158

Dan Jones writes "Google has open sourced several of its key JavaScript application development tools, hoping that they will prove useful for external programmers to build faster Web applications. According to Google, by enabling and allowing developers to use the same tools that Google uses, they can not only build rich applications but also make the Web really fast. The Closure JavaScript compiler and library are used as the standard Javascript library for pretty much any large, public Web application that Google is serving today, including some of its most popular Web applications, including Gmail, Google Docs and Google Maps. Google has also released Closure Templates which are designed to automate the dynamic creation of HTML. The announcement comes a few months after Google released and open sourced the NX server."
This discussion has been archived. No new comments can be posted.

Google Releases Open Source JavaScript Tools

Comments Filter:
  • Nice... (Score:3, Insightful)

    by socceroos ( 1374367 ) on Thursday November 05, 2009 @07:39PM (#30001564)
    These could come in handy. Google has had a fair bit of experience making Javascript apps that run acceptably. I've got a project coming up, and I'll bookmark this for consideration.

    Thanks Google. =)
    • Re: (Score:2, Interesting)

      by amicusNYCL ( 1538833 )

      These results are very impressive. I fed it a 445KB Javascript file for one of my applications and it was able to reduce that to only 9KB of code! Who knew that 90% of that code was just cruft? It even had the added bonus of randomly inserting subtraction operators in the middle of my identifier names and constants.

      closable:f-alse
      suc-cess:function(){window.location.reload(true)}

      I also gave it the URL of a 860KB JS file which it claimed was "unavailable", despite being able to load the 445KB file in the s

      • Re: (Score:3, Insightful)

        by tixxit ( 1107127 )
        I am pretty sure that the Closure Compiler is meant to be used with code written for, and in the style of, the Closure Library.
  • by John Whitley ( 6067 ) on Thursday November 05, 2009 @07:42PM (#30001584) Homepage

    Good grief. Homophone insanity. We've got Clojure [clojure.org] doing interesting things in the language and concurrency space. Block support in C/Objective-C [thirdcog.eu] reinjecting "closures" into everyone's vocabulary. And now Google jumps in with "Closure" just to make sure that no one has any idea what anyone else is talking about...

    • by Anonymous Coward on Thursday November 05, 2009 @09:10PM (#30002126)

      Sounds like a real clojure-fuck.

    • They are continuing with the work they started with the "Chrome" browser, making sure nobody find out that Mozilla invented "chrome://" or what it can do with that.

      • by richlv ( 778496 )

        and later they named the linux version chromium [sourceforge.net]

    • Good grief. Homophone insanity. We've got Clojure [...] "closures" [...] And now Google jumps in with "Closure"

      It's worse than that; there's also Clozure Common Lisp [clozure.com].

  • Unimpressive (Score:5, Interesting)

    by BitHive ( 578094 ) on Thursday November 05, 2009 @07:44PM (#30001596) Homepage

    Half the demos don't work and these widgets are hideous even by Google standards. I'm gonna stick with ExtJs for the forseeable future.

    • extjs (and jQuery, etc) are frameworks.... Closure isn't a framework
    • Re: (Score:2, Interesting)

      by lhoguin ( 1422973 )

      Looking at the library's source code, I don't find many new things that I can't already find in another library. I'm sure there's interesting components, but this looks more like another case of NIH than anything. If their code really is faster I'd rather have them work on existing libraries and try to speed things up for everyone rather than creating more of the same thing.

      Of course, if everyone uses Google's tools and libraries, it makes things easier for them to optimize Chrome, which is probably the who

      • Re: (Score:3, Insightful)

        by jhfry ( 829244 )

        Of course, if everyone uses Google's tools and libraries, it makes things easier for them to optimize Chrome, which is probably the whole point.

        Uhh... no.

        I would imagine that Google had been developing these libraries for years prior to even thinking about building a browser. This also explains why they have their own libraries rather than using "existing" libraries... their libraries are "existing" libraries. In fact, I would wager that their libraries were more complete than many of the competing libraries were a few years ago.

        I am guessing that if you were to compare Google's libraries to many of the "existing" libraries you wish they would co

  • by gmuslera ( 3436 ) on Thursday November 05, 2009 @07:50PM (#30001638) Homepage Journal
    I know that it probably work in current major browsers without problems, but somewhat look a bit like a push towards Chrome. If things start to base more and more in javascript, specially complex one, not only the old browsers will die (ok, killing IE6 for good is an obligation for the future of mankind, or at least internet), but also current/competitive browsers not so fast at the javascript arena will get a big hit too. Good enough will stop being enough when most internet need complex javascript and a blazing fast javascript engine to work. But i suppose that is better that it be based on open standards from the start than the adoble flash way.

    I suppose that complaining about this sounds like asking to forget civilization and go back to rural communities and simpler old way of life, but sometimes you miss the good old web as it used to be (yes, even the slashdot comment editor from 1997)
    • Re: (Score:2, Informative)

      by maxume ( 22995 )

      You can turn on the old comment system (well, the pre-javascript one, I don't remember if it is the same as what there was in 1997).

    • by Rylz ( 868268 ) on Thursday November 05, 2009 @08:09PM (#30001764) Journal

      look a bit like a push towards Chrome.

      Funny, I've also heard this argument the other way around. A lot of people seem to think that Chrome is actually meant simply to push every browser developer to build faster JavaScript support and to catalyze other technologies that will allow Google to develop better web applications. Maybe this release is also a push towards those goals.

      • Re: (Score:3, Funny)

        by the_womble ( 580291 )

        That makes a lot more sense. Google does not make money from Chrome. It does make money, and plans to make more, from web apps that benefit from fast javascript.

        Incidentally, is MS improve Javscript performance? I know Mozilla are.

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      rural communities are indeed better, more space, less snitching, you get to know people rather than just assuming everyone is a paedophile

      JavaScript is what is driving the hardware upgrade cycle these days. I can use email/IM/word processors, even minimalist image editors and possibly VoiP on a pentium 90 reasonably well but it won't run the newest browsers or load even a 'minimalist' modern site. I think client-side scripting in browsers should be done away with completely, come up with a protocol-level
      • If you want a server to draw the page for you, you might as well just run an ordinary modern browser on that server and connect via x11/citrix/whatever.

        You'll get about the same effect, and won't have to wait for everyone to adopt your plan.
      • rural communities are indeed better, more space, less snitching, you get to know people rather than just assuming everyone is a paedophile

        Assuming that everyone is a paedophile is not a fundamental part of British culture, ou insensitive clod!

        The government plans to regularly interview kids without parents present, put cameras in some people's homes, and to require people to register before you can give a friend's children a lift to school.

    • Re: (Score:3, Interesting)

      by amicusNYCL ( 1538833 )

      If things start to base more and more in javascript, specially complex one, not only the old browsers will die (ok, killing IE6 for good is an obligation for the future of mankind, or at least internet), but also current/competitive browsers not so fast at the javascript arena will get a big hit too. Good enough will stop being enough when most internet need complex javascript and a blazing fast javascript engine to work.

      It's not really that bad. I've been developing a pretty massive application based on ExtJS that runs surprisingly fast in IE6. In Chrome or Firefox it runs very fast. I'm talking about 450KB minified Javascript files here, doing things like laying out data in sortable filtering grids, tree structures, drag and drop, etc. I'm surprised at how well IE manages to use it.

      • I do the same for some time. However, I would not call ExtJS fast in IE6 on a corporate desktop (remeber, corporates are not running the latest and greatest for typing emails and word documents). Even in Firefox 3.5 and Chrome are JavaScript powered pages slow (compared to the good old HTML forms which loaded *and* rendered in miliseconds).

        However, not needing to refresh the UI after every user action will make the user experience faster in more complex web applications.

        Cheers,
        -S

    • by nurb432 ( 527695 ) on Thursday November 05, 2009 @08:22PM (#30001858) Homepage Journal

      It also kills off older hardware that was perfectly fine for rendering server side processing, but will choke with this move back to client side ( which personally, i think is the wrong direction, but that is a different discussion )

      • by khallow ( 566160 )

        It also kills off older hardware that was perfectly fine for rendering server side processing, but will choke with this move back to client side ( which personally, i think is the wrong direction, but that is a different discussion )

        Depends on the client side load. Shifting some load to a zillion clients makes a lot of sense from a serverside point of vieww.

  • by Joe Snipe ( 224958 ) on Thursday November 05, 2009 @07:56PM (#30001678) Homepage Journal

    Try Closure! It's open!

  • I currently use jquery and jtemplates with json data. How do the closure template commands compare to jtemplates? I didn't really see any ajax functionality in the tutorials but I haven't had time to delve any deeper. Has anyone spent more time with this?

    I'm still going to read through it, was just wondering if anyone else has more experience with closure.
    • Re: (Score:2, Informative)

      by Azureflare ( 645778 )
      Okay wow, spent some time looking over the API reference.. This thing seems awesome! I love the UI components they've opened up. Those could be pretty useful. Too bad it might mean having to rewrite all my jquery code to closure, but maybe that's not such a bad thing. There's a lot of things in there that would be very nice to use. I'm probably going to try creating some simple projects before adopting it though.

      You know what'd be great? If there were more tutorials that show off a lot of the functional
      • Re: (Score:2, Informative)

        by Azureflare ( 645778 )
        Addendum: I realize their various apps use this as their language but when I say "demo" I mean demo with source code (e.g. tutorial :)

        P.S. WTB edit feature on slashdot.
  • by Lemming Mark ( 849014 ) on Thursday November 05, 2009 @08:14PM (#30001812) Homepage

    "The announcement comes a few months after Google released and open sourced the NX server."

    That's a bit confused... it may just be a typo but it's resulted in a misleading statement. Google released *their* NX server as open source. Previously the FreeNX project had independently created an open source NX server, using libraries provided by NoMachine (inventor of the NX protocol) who provide all of the clever compression stuff from their server as open source libraries.

    The summary makes it sound like Google were solely responsible for the existence of an open source NX server, whereas actually I'd say they're "standing on the shoulders of giants (NoMachine), next to some other dude who was already up there (FreeNX)"

    • And killing off No Machine;'s business model while they are about it!

      Do Google actually use NX in a big way? It is easy to imagine what they might do with it.

  • Apache v2.0 (Score:5, Informative)

    by RiotingPacifist ( 1228016 ) on Thursday November 05, 2009 @08:16PM (#30001824)

    It seams silly to mention that it's open source without giving the license. Btw It's not copyleft, allows linking from other licenses and is GPLv3 compatible

    • It seams silly to mention that it's open source without giving the license. Btw It's not copyleft, allows linking from other licenses and is GPLv3 compatible

      Can you rephrase that in english please? Does that mean we can't use this in commercial products?

      I'm curious why Google didn't choose the the dual MIT/GPL license like jquery uses.

      • You absolutely can use that in commercial products. You can also create derivative works and not release the source.

        Apache 2.0 is considered a "commerce friendly" open source license (whatever that means). You'll see it in commercial products like Android and the Apache web server.

        Wikipedia entry [wikipedia.org]
        Apache 2.0 License full text [apache.org]

  • Lego-like (Score:5, Informative)

    by Art3x ( 973401 ) on Thursday November 05, 2009 @09:20PM (#30002194)

    The Closure Library has a lot of useful-looking classes and functions, like for working with Arrays, Dates, or the URL. They're divided into short files, so that you can use just the parts you want and not have to download one big file.

    jQuery has definitely been a great library, especially at finding things in the DOM. And I think its API for handling events is easier (definitely less to type) than this. But it doesn't have all of the things that this has --- short helpers that probably I would end up writing on my own (and already have started to).

    I'm also interested in the UI Widgets like an Autocomplete text field. I've been waiting for the jQuery UI team to finish that one widget for months, but for some reason their development is so slow!

    Standard Disclaimer about JavaScript:

    1. 1. JavaScript is a nice language.
    2. 2. Writing JavaScript to work in Internet Explorer, Firefox, Safari, and Opera is a nightmare like no other.
    3. 3. Mainly it boils down to writing JavaScript to work in (A) Internet Explorer and in (B) browsers that are not Internet Explorer.
    4. 4. The "core" JavaScript is really nice: dynamic typing, super-short syntax for hash tables, arrays, regular expressions; dot-chaining of members and methods.
    5. 5. The browser API, or "DOM", part of JavaScript is different in IE than in the rest, and this, I think, is the main reason it's a pain. But jQuery and other libraries smooth this over.

    Like has been said, watch the Google Video "JavaScript: the Good Parts" to elaborate on this. And if you hate JavaScript but are forced to write it and haven't read JavaScript: The Definitive Guide, it's the best book on JavaScript and one of the best O'Reilly books period.

    • 2a Trying to get your Javascript to work in Facebook's sandboxed version (FBJS) only make the nightmare worse.

    • Re: (Score:2, Informative)

      by lhoguin ( 1422973 )

      I'm also interested in the UI Widgets like an Autocomplete text field. I've been waiting for the jQuery UI team to finish that one widget for months, but for some reason their development is so slow!

      I've been using the original autocomplete plugin [bassistance.de] for a long time now, it works great. This is the plugin that is used as a basis for the UI autocomplete component. Anything preventing you from using it in the meanwhile?

    • They're divided into short files, so that you can use just the parts you want and not have to download one big file.

      The last time I used a JavaScript library like this (Ext), I discovered that this actually makes your pages slower. The overhead of each request quickly passes the time it would take to download an extra 100-200 KB. Also remember that the file can be cached, so the client only has to download the file once. Some libraries actually encourage you to source the JavaScript files from their servers instead of your own, so that browsers can cache a single copy of the files and use the cached versions on every sit

    • 6. Dealing with memory leaks on most browsers (ex: ff) is nearly impossible

      On your #2 point, my experience is that coding for: FF3, Safari4, Chrome and IE8, is no longer a compatibility nightmare. Dealing with performances and memory remain a nightmare on my view (except on Chrome which rocks on garbage collecting).

  • What would really be nice is an HTML/XML-like language that has features for building real desktop-like GUI's 95% declaratively in a state-ful way instead of JavaScript IF's, loops, and pathy set/gets.

    • What would really be nice is an HTML/XML-like language that has features for building real desktop-like GUI's 95% declaratively in a state-ful way instead of JavaScript IF's, loops, and pathy set/gets.

      1: GTK javaascript. or JavaScript .net. language + framework = program.
      2: MS has crap like that. And so does Firefox. You just don't pay attention to it.
      3: statefulness in JavaScript is simple. Passing references vs. Passing Values.... is not.

    • It's called WPF. And you can use IronPython/IronRuby for the code parts (those that cannot be shoved into the declarative model in any way).

  • wait... (Score:3, Funny)

    by smash ( 1351 ) on Thursday November 05, 2009 @11:43PM (#30002884) Homepage Journal
    ... is google evil this week, or not?
  • by Chrisq ( 894406 ) on Friday November 06, 2009 @04:28AM (#30003766)
    GWT is a great Java to Javascript environment, but falls down in that to produce new components (ouside the toolbox provided) is difficult and requires raw javascript. Does anyone know if these products integrate or work together, because what would be really nice would be to be able to use closure to produce GWT components
  • err.. that's it really.

The use of money is all the advantage there is to having money. -- B. Franklin

Working...