ECMAScript Harmony has been the big news of the week. It isn’t hard to see why, the next version of JavaScript is going to affect us all, for a long time (even more than a presidents term!)
The podcast is over an hour long and goes into a ton of detail covering a lesson on language design, politics and process, a lot of history, and hopefully the path to a positive future.
Did you know that you can use Gearsto do fast, client-side searching of data, similar to a client-side search engine? Gears bundles Full-Text Search (FTS) abilities right into its local, SQLite database. MySpace, for example, uses this feature with their MySpace Mail application, downloading all of a user’s messages for fast, client-side search. Because all of the data is local, you can do nifty things like search over the data in real-time as the user types, something that is much harder if you have to query over the network to a server to do the searching.
Would you like to add the same kind of fast, local searching to your own web page and web applications? This article introduces you to PubTools Search and the Gears features that power it, namely Full-Text Search and Workers. PubTools Search is an open source JavaScript library that drops a client-side search engine right into your page. You configure it with basic HTML plus a list of URLs to index. Once loaded, a search form that uses the local Gears full-text search abilities will appear in your page to quickly and locally search over the documents in real time as a user types into the search field.
Brad sat down with me to discuss the project, some of the best practices, and his use of Dojo.
Last, but never least, is Alex Russell of the Dojo Toolkit and SitePen. In Alex’s five minutes of video footage for our JavaOne talk, he explained how Dojo enables you to built fantastic, responsive applications for everyone. The everyone piece revolves around accessibility too, which is core to Dojo thanks to work from Becky Gibson and others on the team.
The Dojo grid and charting packages are very rich these days, and continue to get better. Alex also noted in a separate discussion how there are subtle advantages to the charting package such as being able to print the darn things out nicely. Other flashier products may not allow that minor feature.
John Resig got in front of the camera, and the projector, as he gives us his thoughts on the state, and future of Ajax.
He starts out by discussing jQuery Core, and the features in the near term (1.2.4), short term (1.3) and beyond. He then delves into the UI side of the house with jQuery UI 1.5. He segues from jQuery to the future of browsers and JavaScript in general.
Today we have Bruce Johnson of the GWT team talking to us about GWT 1.5. He discusses the new features, such as the long awaited Java 5 language support, performance improvements, and much more.
It is very nice to take an application, run it through the new GWT 1.5 compiler, and get an instantly faster running application “for free”.
We are having a special week at Ajaxian. Ben and I are giving an Ajax talk at JavaOne this week, and decided to put a little video from Ajax pioneers. As we worked out what we wanted to do, we asked the pioneers for a little time to do an interview. Although only a piece of the interview will be used in the live presentation, we wanted to get the full interviews for the community here.
During the week you will hear from:
Sam Stephenson of Prototype
Bruce Johnson of GWT
Alex Russell of Dojo
John Resig of jQuery
On Wednesday, we will have a special video that features Ben and I having some fun with a new type of Ajax application.
Let’s cut to the chase, and listen in to Sam Stephenson. Although we couldn’t get to him in person, he kindly recorded himself via his laptop. My voice quality is poor, but we are all hear to listen to his thoughts on:
The future of Prototype
What excites him about new versions of Prototype, and what problems are they trying to solve
Thoughts on the current crop of browsers, and what he wants to see
In the interview he discusses pdoc, a new inline documentation tool, Sprockets, a tool to help package Prototype, and new event delegation techniques.
I got to interview Ben and Stephan, the creators of a new Flex/AIR application that was shown off at JavaPolis in Belgium.
The application gives you access to the library of talks that Parleys has available, and it includes features such as:
Being able to take video offline to watch later
Comments in the stream itself
Rating system
Much more.
In the interview I got to ask the guys about the technical side of Parleys, their experience, and what they have planned for the future. At the top is the interview, and below are screencasts of the various features. Check it out.
I had the pleasure of finally meeting Didier Girard. I seem to run across Didier’s work every week or so, but for some reason we haven’t had a chance to meet face to face, until JavaPolis.
There was a day when Web development was in a sad state of affairs. The majority of developers laughed at JavaScript, and were focusing on a killer new server-side web framework, or a new ORM library. The consensus was that that browser was dumb. The modern TN3270 if you will.
A few renegades were actually building fantastic dhtml experiences. We could look up to Erik and Arv, and the many others who pushed the boundaries.
We were giving some talks on “Building killer web sites with dhtml†and we enjoyed surprisingly people with what was available, but the majority still didn’t care. Then Ajax came along and the revolution started. Finally, we could get back to thinking about the user interface and general usability of Web based applications. We could care about the user again!
This is from a post on the new devphone.com, a new community site that hopes to do the same for Ajax, for mobile development. We believe that it is the time of a mobile development renaissance. The iPhone has pushed the boundaries, and Android is joining in the fun. People are already using their mobile devices to do so much, but it is time for really great interfaces to come to life as we have platforms that enable them.
To kick off the community we got to sit down with Joe Hewitt to discuss the iPhone Facebook app, how he develops on the platform, the iPhone in general, and what he would love to see from Apple. We also got to talk about the upcoming Android release and what he is looking to see out of that mobile platform.
Watch and listen to the interview below:
If you are interested in mobile development, check out devphone, subscribe to our feed, and let us know what you would like to see. It is very early days, so who knows which direction it will go.
Kaazing Corporation and Terracotta, Inc. today announced a strategic alliance to deliver the software industry’s most scalable and advanced real-time Web 2.0 technology for financial systems, online gaming, online sports and news broadcasting applications. The seamless integration between Kaazing’s real-time Rich Internet Application (RIA) solution, Enterprise Comet, and Terracotta’s Network Attached Memory software enables Kaazing customers to create and deploy scalable mission-critical real-time Web 2.0 solutions, such as trading system clients, online betting applications, performance monitoring, RFID/GPS tracking systems, and sports and news broadcasting applications.
Jonas Jacobi of Kaazing was at a conference that I am at in Oslo, so I cornered him to find out what this is all about. The video discusses how Kaazing has a GWT-like ability to take Java bytecode and produces Comet-enabled JavaScript that runs cross browser. Jonas demonstrated a JMS application, entirely written in Java, that runs in the browser itself. They will be showing off an online gaming application in short order.
Andreas Ecker, project lead of qooxdoo, sat down to have a chat about the state of the project, how it works, what it does, how it compares to other frameworks like GWT, and how it integrates with third party development environments from Borland and the Eclipse Foundation.
Isn’t debugging generated Javascript going to be messy?
Wouldn’t the large size of the generated Javascript make it’s use infeasible?
Where is all of the cool stuff, like effects libraries, etc.?
Is generating “assembler” in Javascript really the right level of abstraction?
Now that a year has passed and people have had a chance to experiment and develop with GWT, I thought it would be a good idea to revisit these questions. I interviewed GWT practitioners Dr. Adam Tacy and Robert Hanson, who — aside from working on commercial projects featuring GWT — have just finish their first book on the subject, GWT in Action: Easy Ajax with the Google Web Toolkit. They were kind enough to answer a few of my questions.
Q: Has debugging with GWT been a nightmare akin to the early C++ compilers (or RJS), or has hosted mode solved most of those problems?
Debugging GWT code is as easy as debugging any other Java application. Just open up the Eclipse IDE, and launch the application in debug mode - the key is to really harness the power of the Java IDE and tooling to ease debugging. There may be some quirks here and there, but in general it is a very pleasant experience.
An issue that is sometimes raised by newcomers to the tool is the lack of a “debug window” component for the JavaScript (think of YahooGUI widgets, etc.) - but that basically misses the point of GWT where 99% of debugging can be applied to application logic in your Java IDE. If you want to hang onto the “printf/println” style of debugging, then in hosted mode it is possible to log to the hosted mode console. For client side code, GWT could be improved to allow for Log4J style log levels. But why would you do this in general when you have access to the powerful debugger in your IDE?
Once you get out of the hosted browser and deploy the project to your site, if there is still a need for debugging you can use the same debugging techniques as you would with any other JavaScript application. Some of our favorite tools include Web Developer and Firebug, two add-ons for Firefox.
One of the initial complaints from JavaScript developers was that the JavaScript code generated by the GWT compiler is obfuscated, and impossible to debug. To quote the Ajaxian story from a year ago, “I can’t imagine how scary it will be to have a JavaScript error show up in a browser talking about line 2123 which has “a[b] = push(c)” in it”. The author of that piece missed the rest of the story.
On the few occasions that you have an error that can’t be debugged from the Java IDE, GWT gives you the ability to alter the output of the GWT compiler. You can select from two levels of verbosity (”pretty” and “detailed”) that will emit JavaScript code that can easily be mapped back to the Java source. Once you have your “pretty” or “detailed” JavaScript, you can easily insert debugger commands to be picked up by a JavaScript debugger. You could use this verbose version of the JavaScript code when you deploy your application to production, but it is usually desirable to use the default mode of the GWT compiler, which is to compress the code as much as possible.
At another level, GWT has a powerful concept called Generators, which effectively auto-generates code for you (GWT itself uses them for its RPC, i18n, and JUnit integration approaches). Generators do get a hook into Log4J style log levels, and when running hosted mode or compiling for web mode you can follow the compiler decisions that led to the generation of code you are using - this leads to an easy way of debugging that, for example, could detect that GWT hasn’t picked up the latest locale you added.
We have never had any problems debugging a GWT application - and don’t forget, unless you are trying to do something really at the edge of the underlying technology (DOM, HTML and JavaScript), using GWT lets you concentrate on debugging your application logic rather than on browser differences.
The other benefit of GWT is of course the use of a strongly typed language - which reduces the probability of introducing errors in the first place. In our development experience so far, there has only been one occasion where we’ve had to drop down to JavaScript debugging - and that was really to understand what Opera was doing under one particular circumstance with the underlying DOM!
Google has announced some big news for Ajax developers at Google Developer Day. The announcement is Google Gears, an open source runtime to allow you to build Offline Web applications.
Some may think “hmm, what about Dojo Offline?” The great news is that the Dojo crew were in the loop wrt this project, and Brad has ported Dojo Offline to use Google Gears as the base platform.
This is fantastic news, as it means that Dojo and Google are working together, instead of fragmenting. The end result is that the open Web will end up with a much better offline solution.
We interviewed Brad Neuberg, who is working on Dojo Offline thanks to SitePen.
The discussion was a lot of fun, and covered Brad’s thoughts on the offline problem, and how Google Gears and Dojo Offline fit together.
I can’t wait to see what the community comes up with, especially to solve the tough syncing problems.
ps. I apologize for the un-produced feel of this podcast. We got to do the interview at the last minute, and wanted to get the content out there for you in a timely manner.
Presented by the Silicon Valley WebBuilder, this event brought together Mike Shaver from Mozilla, Chris Wilson from Microsoft’s IE team, HÃ¥kon Lie from Opera, and expertly moderator Douglas Crockford from Yahoo! to talk about the current state of the browser landscape.
At first, each person got a chance to say their peace. Here are some core items that each person said:
Chris Wilson
We are not about to enter another browser war. This isn’t about destroying each other. This time it is about building the standards based web future, which means we need to work together. This isn’t 1995, so let’s not build that platform. The problem that we have is that as soon as you improve something, you break the web. This is especially hard since Microsoft has ~500 million users.
Chris queried the top 200 web sites and 50% of them are in strict mode. When he did this in IE 6, only one of them was like this. He hinted at having developers opt-in to standards mode in a different way.
Mike Shaver
Mike also said that he doesn’t consider it to be a browser war….. but rather a “mindshare struggle”.
The new “war” is having cool applications being built on the web itself. If the next flickr/gmail/… is built on the web, it is winning.
Don’t look to the W3C for the future.
HÃ¥kon Lie
“If you need a good browser for Windows 98 we have it”
Ajax is bad. We need to add HTML, CSS, and the like, and he had some funny acronyms.
He then discussed the ACID 2 test and had a lot of fun with IE 7 showing how it compared to Opera 3.6 from 1998.
The Wii (which uses Opera) is going to change the web. More people are trying to get their sites rendering correctly with the Wii than “who cares about that Opera browser”.
We need to support video as a first class citizen (and sound). “We can’t leave it to plugins anymore”.
What video formats should we support? There aren’t many open formats, so they use Ogg formats.
Where’s Apple?
They refused to send someone saying that “we are busy writing software”.
We at Ajaxian have long been hoping for a JIT compiler inside of the browsers’ JavaScript interpreter — so we were pretty stoked when Adobe donated their excellent JIT-compiling JavaScript virtual machine to Mozilla back in Nov. ‘06. The new open-source codebase, maintained by the Mozilla Foundation, is known as Project Tamarin.
In this episode of Audible Ajax (~14 MB, ~27 min.), we look into Project Tamarin in a bit of detail, analyzing what kind of an impact this will have on the Ajax community. Special guests include Brendan Eich (CTO, Mozilla), Kevin Lynch (Chief Software Architect, Adobe), Alex Russell (Founder, Dojo), and more. Let us know what you think!
, JavaScript
