Compile Java to JavaScript, from Google!



  • I wish I was making this up.

    http://code.google.com/webtoolkit/

    GWT lets you avoid many of these headaches while offering your users the same dynamic, standards-compliant experience. You write your front end in the Java programming language, and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.
    It "compiles" Java to JavaScript, you say? How?! Java and JavaScript are two high level languages that are completely different from one another!



  • Nooooooooooooo!!!! I can't look!



  • The statement is accurate.  The GWT compiler parses the Java input and produces a javascript output that does exactly the same thing.  Compilers are allowed to emit things besides machine code.



  • There have been a lot of projects along these lines in the research
    community (e.g. haXe ( http://haxe.org/ )), but I've never seen one
    that was intended for "real-world" use. The choice of Java is
    interesting, as well.



    In short: not a WTF.




  • So wait, this is essentially a kind of scripted dreamweaver?

    That could actually be rather handy, for stuff like their Maps.
    But it's not an easy task, and Google is not renowned for producing decent code, and development systems are not exactly their core business.

    I don't trust it.



  • @Brendan Kidwell said:

    I wish I was making this up.

    http://code.google.com/webtoolkit/
    GWT
    lets you avoid many of these headaches while offering your users the
    same dynamic, standards-compliant experience. You write your front end
    in the Java programming language, and the GWT compiler converts your
    Java classes to browser-compliant JavaScript and HTML.
    It
    "compiles" Java to JavaScript, you say? How?! Java and JavaScript are
    two high level languages that are completely different from one another!



    Nothing special about this at all, there are many client-javascript
    enabled web dev systems around. Google happen to be using Java, but any
    web scripting language is fair game. Currently I'm playing around with
    codename "Atlas" from MS as an add-on to ASP.NET 2.0, but there are
    more out there. AJAX is the big web buzzword at the moment, and there
    are many project about to do the heavy lifting for you instead of you
    having to handwrite all the javascript, managing server requests, etc.



    In essence, all it's doing is looking at your server-side code,
    thinking "hmmm, this could be done client-side in javascript", and
    emiting the javascript to do it along with the HTML output. No
    different to your Java/C# compiler outputting a bytecode language
    instead of machine code, and even that when you think about it is just
    another language (we just can't read it well).



    I thought it was all a load of fuss over nothing at first, and a lot
    of work for little result, but taking an existing web app, wrapping a
    few <atlas:updatepanel></> tags around it and having your
    server-side app turned by magic into a rich client app as easy as that
    was pretty damn neat. Google's webtoolkit will just be doing the exact
    same thing.



  • @jesuswaffle said:

    In short: not a WTF.


    Okay, you're all right, it's not really a WTF, but it scares the crap out of me. Java has lots of language features that JavaScript doesn't have, and vice versa. But I suppse that's what a compiler does--take the meaning of code in one language and rewrite it in terms that the target execution machine can handle.

    Still, I'll stick to real client-side JavaScript libraries for now. This Google thing spits out ~100kB of compiled JavaScript code for a "typical" project, according to the docs.



  • You know, if this produces JS that works in both IE and firefox, then it's all worth it.

    That's really the hardest part of approaching web development as a non-JS experienced programmer:  It's a pain in the fucking ass to work around the flaws in BOTH IE and firefox.

    If my primary experience was java, and I needed to produce some complex web UI, I'd be all over this.  After all, the browser's just a client, and a damn quirky one at that! Why learn all the peculiarities of JS and HTML, and the cross-platform issues, if you can just code for it in java?

    I've gotta say, the whole 'write web apps w/o html/js' idea seems fuggin brilliant to me, and I hope others will produce competing libraries.



  • @Brendan Kidwell said:

    Okay, you're all right, it's not really a WTF, but it scares the crap out of me. Java has lots of language features that JavaScript doesn't have, and vice versa. But I suppse that's what a compiler does--take the meaning of code in one language and rewrite it in terms that the target execution machine can handle.

    Still, I'll stick to real client-side JavaScript libraries for now. This Google thing spits out ~100kB of compiled JavaScript code for a "typical" project, according to the docs.

    I don't know if that's what you mean, but you're giving the impression that you what they're doing is "take this Java app in its entirety and convert it to JS". That is NOT the case. While I've not had the time to look into the full details, they're 99% probably just doing what everyone else is doing - keep all the app logic on the server, and emit basic JS to do simple stuff client-side (load up the contents of a dropdown, etc), and use an XML call to update page contents instead of doing a full page reload.
    There is no magic, no "turning Jva apps into JS apps" - just doing what existing web app frameworks already do and have done for ages. It just does it with more "updating the existing page with JS" and less "reload the whole page".
    Again, not having looked at Google's stuff, I'd assume/hope that the 100kb of javascript is in a cacheable external file so you have a one-time per-user hit and then it's plain sailing.

    Google aren't even revolutionary here. Microsoft, Yahoo, and loads of others already have stuff out there.

    I've gotta say, the whole 'write web apps w/o html/js' idea seems
    fuggin brilliant to me, and I hope others will produce competing
    libraries.
    Travel back a year or two and that'd make sense. The competing libraries already exist. Some in beta, some that have been out in production for a while!

    That said, it really is a fuggin brilliant idea. A few months ago I wrote a small web app without touching any html or js. On Tuesday, within an hour or two I added client javascript-based functionality all the way through without writing so much as a semicolon.



  • @Brendan Kidwell said:

    I wish I was making this up.

    http://code.google.com/webtoolkit/
    GWT lets you avoid many of these headaches while offering your users the same dynamic, standards-compliant experience. You write your front end in the Java programming language, and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.
    It "compiles" Java to JavaScript, you say? How?! Java and JavaScript are two high level languages that are completely different from one another!

    With Rails 1.1 you can also compile Ruby code to JS.

    That kind of generated code blows though, in my opinion. It's extremely dangerous because the server-side devs that will be tasked to do the scripts will think they have the power of their usual language (well, they do) but will completely forget about the potential limitations and incompatibilities that plague browsers, and most of the performance issues.

    If on the other hand I could directly use Python or Ruby to script my pages (instead of JS) i'd be some fucking happy man.



  • @masklinn said:

    If on the other hand I could directly use Python or Ruby to script my pages (instead of JS) i'd be some fucking happy man.


    I'm really curious what that would look like.

    What if browsers supported client-side Ruby or Python?

    function setSitemap()
    {
    var pluses = elemsByClass('plusmin');

    for (var i = 0; i < pluses.length; i++)
    {
    pluses[i].onclick = function ()
    {
    var nodeChildren = elemsChilds(this.parentNode.parentNode);
    nodeChildren.shift();
    for (var i=0; i < nodeChildren.length ; i++ )
    {
    toggle(nodeChildren[i]);
    }

         var plusminFile = /min\.gif/.test(this.src)? 'plus.gif':'min.gif';
    
         this.src = '../gfx/tree_icons/' + plusminFile;
      }
    

    }
    }



  • @RayS said:

    I don't know if that's what you mean, but you're giving the impression that you what they're doing is "take this Java app in its entirety and convert it to JS". That is NOT the case. While I've not had the time to look into the full details, they're 99% probably just doing what everyone else is doing - keep all the app logic on the server, and emit basic JS to do simple stuff client-side (load up the contents of a dropdown, etc), and use an XML call to update page contents instead of doing a full page reload.

    Actually, when I skimmed the docs the first time they seemed to indicate just that: you write Java code and compile/test/edit in a browser using a real JVM, then when you're done, you compile to standalone JavaScript+HTML. This code can of course talk to other completely different modules that live on the server, and it's all nicely integrated, but the client-side code is client-side code.



  • <font face="Georgia">The above JS would look something like this in Ruby:</font>

    <font face="Courier New">def setSitemap()
      pluses = elemsByClass('plusmin')
      pluses.map! {|plus|
        plus.onclick = lambda {
          nodeChildren = elemsChilds(self.parentNode.parentNode)
          nodeChildren.shift
          nodeChildren.map! {|nodeChild|
            toggle(nodeChild)
          }
          plusminFile = /min.gif/.test(this.src)? 'plus.gif':'min.gif'
          self.src = '../gfx/tree_icons/' + plusminFile
        }
      }
    end

    <font face="Georgia">Looks pretty similar to me. I don't see a lot of gain here, except that it would be nice to have the same language client-side you're using server-side. Personally, I'd like to have everything - JS, HTML, CSS replaced by something based on Scheme. Of course, you'd be able to use it server-side too.</font>
    </font>



  • @dhromed said:

    @masklinn said:
    If on the other hand I could directly use Python or Ruby to script my pages (instead of JS) i'd be some fucking happy man.


    I'm really curious what that would look like.

    What if browsers supported client-side Ruby or Python?

    function setSitemap()
    {
    var pluses = elemsByClass('plusmin');

    for (var i = 0; i < pluses.length; i++)
    {
    pluses[i].onclick = function ()
    {
    var nodeChildren = elemsChilds(this.parentNode.parentNode);
    nodeChildren.shift();
    for (var i=0; i < nodeChildren.length ; i++ )
    {
    toggle(nodeChildren[i]);
    }

         var plusminFile = /min\.gif/.test(this.src)? 'plus.gif':'min.gif';
    
         this.src = '../gfx/tree_icons/' + plusminFile;
      }
    

    }
    }

    In Ruby i'd probably write something like

    document.getElementsByClass('plusmin').each do |plus_element|
        plus_element.onclick = proc do |event|
            self.parentNode.parentNode.children.each do |child|
                toggle child
            end
            plusminFile = /min\.gif/.test(this.src)? 'plus.gif':'min.gif'
            self.src = '../gfx/tree_icons/' + plusminFile
        end
    end

    but i must admit that I don't quite grasp what your script is supposed to do: on a click on an element.plusmin you call "toggle" what seem to be the uncles (the children of the grandparent) of your element?

    I probably wouldn't do it that way in the first place (in javascript).

    And the reason why I'd want these languages would be more about their sheer expressiveness (some of which has been included in JS2.0 which makes me very happy) and a potentially more coherent cross-implementation experience.

    That, and being able to use the same language with the same constructs and same expressive power whether coding client or server side, even with good libs such as Prototype having to switch back and forth between python/ruby and Javascript annoys me.

    @Zak said:
    <font face="Georgia">The above JS would look something like this in Ruby:</font>

    <font face="Courier New">def setSitemap()
      pluses = elemsByClass('plusmin')
      pluses.map! {|plus|
        plus.onclick = lambda {
          nodeChildren = elemsChilds(self.parentNode.parentNode)
          nodeChildren.shift
          nodeChildren.map! {|nodeChild|
            toggle(nodeChild)
          }
          plusminFile = /min\.gif/.test(this.src)? 'plus.gif':'min.gif'
          self.src = '../gfx/tree_icons/' + plusminFile
        }
      }
    end

    <font face="Georgia"></font>
    </font>

    MAP is used to modify a list by applying a function to each of it's elements, not to do an operation on every element. Here your "nodeChildren" sequence will be filled with whatever is the return value of "toggle" for each of your elements when you reach the end of map!, what's the point?



  • @masklinn said:

    but i must admit that I don't quite grasp what your script is supposed
    to do: on a click on an element.plusmin you call "toggle" what seem to
    be the uncles (the children of the grandparent) of your element?


    The plusmins are images that are pluses or minuses, like folder tree views have, that toggle the children of the node the plusmin belongs to.

    Couple notes:
    elemsByClass is a custom function of mine because the DOM lacks such an incredibly handy feature.
    toggle is also a custom function, that switches an element's display state between 'block' and 'none'.

    I quickly lifted this bit from a site I did some time ago, and see now that it toggles all these children separately. Apparently, it still uses the sub-optimal tree format of XHTML. I enhanced that a bit later on, so that all children of a node are encased in their own .children element, which would make the second loop obsolete.

    I used the proper version of the tree format for my experimental CSS-only dropdown menus which do not work in IE6 for lack of CSS selector support, and still require JS.

    @masklinn said:
    That, and being able to use the same language with the same constructs

    Agreed. That would be great. I already enjoy the fact that I use Javascript for both ASP and on the client. I only have to be proficient at one language.



  • @masklinn said:


    MAP is used to modify a list by applying a function to each of it's elements, not to do an operation on every element. Here your "nodeChildren" sequence will be filled with whatever is the return value of "toggle" for each of your elements when you reach the end of map!, what's the point?


    No more coding under the influence for me!

    I was expecting toggle to return a toggled nodeChild, and for some reason I was thinking nodeChildren was going to be used again. My first use of map! was certainly a WTF as the inner expression returns the anonymous function that plus.onclick is being set to, resulting in plusses being a list of anonymous functions that's not used again. What's really funny is I started out using each and changed it to map!


Log in to reply