Thursday, April 10, 2008
An idea for Dojo from GWT land
Now that I'm at Google I've been getting a bit more exposed to GWT (the Google Web Toolkit). I used to dismiss it because I'm a JavaScript hacker and GWT is in Java-land, but I've been learning some interesting things about it that I think could help in Dojo-land if we adopted them.
Ray Cromwell rolled something called GQuery, which is basically JQuery inside of GWT. What is unique is you can do JQuery style selectors inside of Java. Dojo has this as well, with dojo.query, but what Ray is doing is crazy. Because GWT gets compiled, he can turn something like this:
"#foo"
into this:
document.getElementById("foo")
in the source. Here's Ray describing it:
"GQuery is progressing nicely. I implemented all of CSS3 selectors by following ExtJS's DomQuery implementation, only I added the ability to parse at runtime as well as via a generator at compile time. The compile time generator turns a CSS selector into 100% inlined code. That is, a selector like "#foo", will turn into "return document.getElementById("foo");", no parsing step involved. I've still got a bunch of optimizations to make, add support for XPath and native getElementsByClassName, but even now working with the library in GWT is very cool. I just started looking at DomAssistant as well, to incorporate (i.e. steal) the best algorithms from each."
One of the comments sums up the benefits of this nicely:
"You have an unfair advantage; since your selectors are compiled you can do any number of optimizations to them, and basically beat any other selector engine out there."
GWT itself does some interesting optimizations like this around what code is sent to specific browsers. I'm seeing numbers that blow me away, that because you can only send down the code needed for a specific browser you can really slim things down. For example, something like Dojo GFX has code paths for IE (VML), Firefox (SVG), and Safari (Canvas). If we could just send which one you need then the code would be 1/3 the size.
How can we get these kinds of benefits in Dojo? We already have a build time that runs through a JavaScript interpreter; can we start to do magic like this? The performance and size benefits I'm seeing in the GWT-world seem to indicate that it is useful.
Ray Cromwell rolled something called GQuery, which is basically JQuery inside of GWT. What is unique is you can do JQuery style selectors inside of Java. Dojo has this as well, with dojo.query, but what Ray is doing is crazy. Because GWT gets compiled, he can turn something like this:
"#foo"
into this:
document.getElementById("foo")
in the source. Here's Ray describing it:
"GQuery is progressing nicely. I implemented all of CSS3 selectors by following ExtJS's DomQuery implementation, only I added the ability to parse at runtime as well as via a generator at compile time. The compile time generator turns a CSS selector into 100% inlined code. That is, a selector like "#foo", will turn into "return document.getElementById("foo");", no parsing step involved. I've still got a bunch of optimizations to make, add support for XPath and native getElementsByClassName, but even now working with the library in GWT is very cool. I just started looking at DomAssistant as well, to incorporate (i.e. steal) the best algorithms from each."
One of the comments sums up the benefits of this nicely:
"You have an unfair advantage; since your selectors are compiled you can do any number of optimizations to them, and basically beat any other selector engine out there."
GWT itself does some interesting optimizations like this around what code is sent to specific browsers. I'm seeing numbers that blow me away, that because you can only send down the code needed for a specific browser you can really slim things down. For example, something like Dojo GFX has code paths for IE (VML), Firefox (SVG), and Safari (Canvas). If we could just send which one you need then the code would be 1/3 the size.
How can we get these kinds of benefits in Dojo? We already have a build time that runs through a JavaScript interpreter; can we start to do magic like this? The performance and size benefits I'm seeing in the GWT-world seem to indicate that it is useful.
Labels: ajax, dojo, gwt, jquery
Dojo SQL Ported to New Environments + Russell Leggett's Fight for the Open Web Work
Two new bits of news today.
First, Jean-Baptiste Boisseau has done some great work porting Dojo SQL to work not only on Gears, but in a Java and AIR environment (and HTML 5 when that appears). His work is in alpha and can be seen here, including a demo here. He has setup a blog as well to track his progress. Just in case you don't know Dojo SQL is an easy-to-use SQL layer for JavaScript. Under the covers it uses Gears to do the actual storage, and now Java if available thanks to Jean-Baptiste Boisseau.
Second, Russell Leggett was inspired by all the talk around the Open Web and Gears. Russell likes the Open Web, but wants to see JavaScript, HTML, CSS, etc. not just evolved but replaced by better layers that can help with web applications; he just wants to see these new layers remain open, just like HTML. I told him that Gears could potentially act as a way to deploy some of his ideas, and challenged him to write up his ideas and create a blog. Russell accepted the challenge and setup a new weblog, named www.fightfortheopenweb.com, as well as a Google Group here. Join the group and join the discussion!
Some excerpts from Russ's first few blog posts:
"I believe there is an alternative solution [to Flash/Silverlight/AIR/etc]. I believe it is possible to fight fire with fire. If Flex/Silverlight/JavaFX threaten the open web, is there a way to compete on the same playing field? If the w3c technologies can't compete, can we take a different route? I propose that one very real solution to the problem would be to create an open source plugin technology to compete. It would allow a few things. First of all, it could ignore backwards compatibility because there would be nothing to be compatible to. Secondly, the cross browser issue would be resolved by being a plugin instead of a single browser implementation."
"I recently had a conversation with Brad Neuberg about the concept of using a plugin to have an Open Web competitor. Brad suggested that this was precisely what Google Gears was trying to do (sort of). In a recent post of his (which has since sparked a conversation across the blogosphere), Brad discussed the definition of the term Open Web and its importance, but also how Gears can help to push the web forward. In our conversation, he asked, "If you were to add functionality to Gears that doesn't enhance the web's existing technologies, but rather creates new ones that live in the browser through Gears what would these look like?" The following was my response:"
Russ wants better data-binding primitives and a refactoring of CSS to include variables, better layout management, and hooking into some kind of new component model for the web.
Russ also isn't gung-ho about JavaScript 2:
"I'm in the group of people that isn't totally gung ho about JS2. I understand the motivation, but its looking like a bit of a kitchen sink language. I think JS needs some improvements, but I'm actually looking at Erlang for inspiration instead of Java and Python. In my vision of a future JavaScript, I see a few things. First of all, I think there are some functional language features that would be good to add considering JavaScript is already a very functional language. I would like to add overloaded functions that use matching and guards for differentiation. I would also like to steal some aspects of the big Erlang feature of concurrent processes. Here, I think, is a perfect convergence with Gears. The Gears worker pools are a lot like Erlang processes (which I'm guessing you knew). No shared state, separate process, and no access to the dom. As I'm sure you know, this can be extremely helpful when trying to stay secure doing mashups, offload intensive operations from the main thread, and communicate with the server. Additionally, I think that there needs to be a little more in the way of modularizing code, allowing private data members, and facilitating better code reuse. I think prototypal inheritance and mixins are definitely better than classes for the language, and I'd like to add some more syntax to encourage them."
As they say in open source, code rules, so I told Russ to grab the Gears source and build it. We can have lots of discussions about how the web should be, but nothing speaks like actually getting a Gears module out that rolls some of the ideas above, at least in prototype form.
First, Jean-Baptiste Boisseau has done some great work porting Dojo SQL to work not only on Gears, but in a Java and AIR environment (and HTML 5 when that appears). His work is in alpha and can be seen here, including a demo here. He has setup a blog as well to track his progress. Just in case you don't know Dojo SQL is an easy-to-use SQL layer for JavaScript. Under the covers it uses Gears to do the actual storage, and now Java if available thanks to Jean-Baptiste Boisseau.
Second, Russell Leggett was inspired by all the talk around the Open Web and Gears. Russell likes the Open Web, but wants to see JavaScript, HTML, CSS, etc. not just evolved but replaced by better layers that can help with web applications; he just wants to see these new layers remain open, just like HTML. I told him that Gears could potentially act as a way to deploy some of his ideas, and challenged him to write up his ideas and create a blog. Russell accepted the challenge and setup a new weblog, named www.fightfortheopenweb.com, as well as a Google Group here. Join the group and join the discussion!
Some excerpts from Russ's first few blog posts:
"I believe there is an alternative solution [to Flash/Silverlight/AIR/etc]. I believe it is possible to fight fire with fire. If Flex/Silverlight/JavaFX threaten the open web, is there a way to compete on the same playing field? If the w3c technologies can't compete, can we take a different route? I propose that one very real solution to the problem would be to create an open source plugin technology to compete. It would allow a few things. First of all, it could ignore backwards compatibility because there would be nothing to be compatible to. Secondly, the cross browser issue would be resolved by being a plugin instead of a single browser implementation."
"I recently had a conversation with Brad Neuberg about the concept of using a plugin to have an Open Web competitor. Brad suggested that this was precisely what Google Gears was trying to do (sort of). In a recent post of his (which has since sparked a conversation across the blogosphere), Brad discussed the definition of the term Open Web and its importance, but also how Gears can help to push the web forward. In our conversation, he asked, "If you were to add functionality to Gears that doesn't enhance the web's existing technologies, but rather creates new ones that live in the browser through Gears what would these look like?" The following was my response:"
Russ wants better data-binding primitives and a refactoring of CSS to include variables, better layout management, and hooking into some kind of new component model for the web.
Russ also isn't gung-ho about JavaScript 2:
"I'm in the group of people that isn't totally gung ho about JS2. I understand the motivation, but its looking like a bit of a kitchen sink language. I think JS needs some improvements, but I'm actually looking at Erlang for inspiration instead of Java and Python. In my vision of a future JavaScript, I see a few things. First of all, I think there are some functional language features that would be good to add considering JavaScript is already a very functional language. I would like to add overloaded functions that use matching and guards for differentiation. I would also like to steal some aspects of the big Erlang feature of concurrent processes. Here, I think, is a perfect convergence with Gears. The Gears worker pools are a lot like Erlang processes (which I'm guessing you knew). No shared state, separate process, and no access to the dom. As I'm sure you know, this can be extremely helpful when trying to stay secure doing mashups, offload intensive operations from the main thread, and communicate with the server. Additionally, I think that there needs to be a little more in the way of modularizing code, allowing private data members, and facilitating better code reuse. I think prototypal inheritance and mixins are definitely better than classes for the language, and I'd like to add some more syntax to encourage them."
As they say in open source, code rules, so I told Russ to grab the Gears source and build it. We can have lots of discussions about how the web should be, but nothing speaks like actually getting a Gears module out that rolls some of the ideas above, at least in prototype form.
Labels: dojo storage, gears, open web
Subscribe to Posts [Atom]
