techno.blog("Dion")

John Reynolds is worried about the idea of having JavaScript run rampant with Ajax.

I totally understand the concerns however, I have a couple of comments:

• JavaScript and Ajax isn’t the problem. It is how you deal with it. For too long JavaScript == ‘for the web developer to hack away’. We do need tools, and we need practices to help manage them. I would love a clean way to declare “this JavaScript wants to import FooModule version 2.3″ and it is all managed for me (for example).
• Don’t use the technology for the sake of it. Compare the effort to your other choices. E.g. look at Google Suggest. Would it be better for them to have a FLASH version to do the work? or use Ajax?
• Frameworks will be here to help. A lot of components can be written to grok this technology so you don’t have to write the JavaScript. We will just have richer widgets.
• XMLHttpRequest isn’t new!

Development is all about tradeoffs. I think that there are situations where the correct tradeoffs mean that Ajax is a good solution.

ThoughtWorkers have released a test tool for web applications named Selinium.

Selenium tests run directly in a browsers, just as real users do. And they run in Internet Explorer, Mozilla and Firefox on Windows, Linux and Macintosh. No other test tool covers such a wide array of platforms.

• Browser compatability testing.

  Test your application to see if it works correctly on different
  browsers and operating systems. The same script can run on any Selenium
  platform.

• System functional testing.
  Create regression tests to verify application functionality and user
  acceptance.

Selenium uses a unique mechanism which allows it to run on so multiple
platforms. Installed with your application webserver, Selenium automatically deploys it’s JavaScript automation engine — the Browser Bot — to your browser when you point it at the Selenium install point on your webserver. Thus, you must have write access to the machine your web application server is running on to install Selenium.

To get a quick feel, checkout an example TestRunner and run all of the tests. You will graphically be walked through the tests, with changing content letting you know what is passing and failing.

How does Selenium work?

Selenium uses JavaScript and Iframes to embed a test automation engine in your browser. This technique should work with any JavaScript-enabled browser. Because different browsers handle JavaScript somewhat differently, we usually have to tweak the engine to support new browsers.

You gotta love adding to “JS?” acronyms. Now we have JavaScript Templates, which, as Aslak talks about, can work well in the new world of Ajax.

Here

          

JavaScript has a bit of a tough label. Many developers think of it as a hackers web scripting language which is good for alert("foo") and document.*.

The language is really growing up now though, and we have good implementations on the Java side such as Rhino.

Rhino even implements the latest and greatest of ECMAScript: ECMAScript for XML (E4X).

Now, XML is a first class citizen in the language which allows you to do some of the following:

Create a DOM from XML

var order = <order>
<customer>
<firstname>John</firstname>
<lastname>Doe</lastname>
</customer>
<item>
<description>Big Screen Television</description>
<price>1299.99</price>
<quantity>1</quantity>
</item>
</order>

Walk the XML tree a la XPath etc

// Construct the full customer name
var name = order.customer.firstname + " " + order.customer.lastname;

// Calculate the total price
var total = order.item.price * order.item.quantity;

Construct a new XML object using expando and super-expando properties

var order = <order/>;
order.customer.name = "Fred Jones";
order.customer.address.street = "123 Long Lang";
order.customer.address.city = "Underwood";
order.customer.address.state = "CA";
order.item[0] = "";
order.item[0].description = "Small Rodents";
order.item[0].quantity = 10;
order.item[0].price = 6.95;

Playing with SOAP

var message = <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soap:Body>
<m:GetLastTradePrice xmlns:m="http://mycompany.com/stocks">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</soap:Body>
</soap:Envelope>

// declare the SOAP and stocks namespaces
var soap = new Namespace("http://schemas.xmlsoap.org/soap/envelope/");
var stock = new Namespace ("http://mycompany.com/stocks");

// extract the soap encoding style and body from the soap message
var encodingStyle = message.@soap::encodingStyle;

print("The encoding style of the soap message is specified by:\n" + encodingStyle);

// change the stock symbol
message.soap::Body.stock::GetLastTradePrice.symbol = "MYCO";

var body = message.soap::Body;

Conclusion

It is interesting to see ECMAScript leading the way in some areas. It is an interesting idea to have XML as such as first class citizen. I don’t remember having “tab delimited data” at the same level, and it is a little worrying to think about XML abuse that could occur because of it.

However, maybe it is time to take ECMAScript more seriously. It is installed in all browser VMs so to speak, and with implementations like Rhino, allows you to script Java in a simple way :)

There has been a lot of talk regarding the amazing new UIs that we can build with XmlHttpRequest, and the like ( a la Google Maps, TadaList, etc ).

Jesse James Garrett has given this set of technology a new name, and talks about it in Ajax: A New Approach to Web Applications.

I am extremely excited about the technology, but can’t agree more with Jason Fried when he calls for some caution.

As with all ‘new ways of doint it’, we need to make sure that we don’t confuse the users. One of the sad truths of UI work, is that you often have to keep your UI in a state that users are used too, even if the purist in you thinks they know a better way.

So, its time for us to get creative, but end up with an interface that is as usable, as much as it blows away the customers! :)

I remember, back in the day, having to write a lot of <noscript> areas, and making sure that the application that we are working on works perfectly for those that choose to turn off JavaScript in their browser (or don’t have a JavaScript enabled one).

Has the tide turned now? Of course, you wouldn’t want to abuse JavaScript just for the hell of it, and when you can give a ‘backup’ to non-enabled peeps it should be done.

But, with the likes of Google Maps, maybe we are seeing the start of the JS/dHTML revolution.

Enable JavaScript to see this site. Enable JavaScript else you will have a poor experience.

As you look at the various languages, and platforms out there, you often see people discussing how much intelligence should go into the parser and runtime.

Java, for example, has a very simple syntax. The parsing stage doesn’t have to do and know too much (although Java 5 did add more).

Compare this to the other extremes. Lisp is incredibly simple. The MOP also makes it very powerful, and the user doesn’t ever really know if the ’standard’ operator they are using isn’t really a tweaked out version. The MOP analagy has been:

It is like juggling with chain saws

Perl on the other hand has to have a parser which is a lot smarter. Larry comes at it from a linguistic standpoint, and wants the language to do the right thing (even if it means having a tougher parser).

I think I follow that pattern. As always, there is a tradeoff, but I would much rather have a couple of guys work on a parser that does what I want, and have the many developers work on a level above of that. I want more expresiveness in my languages. I would hate to write a book with a stripped vocabulary, and a lack of context.

However, there is obviously a tradeoff. The parser will have more bugs. It will take longer to implement, it must be proven that it CAN be implemented, and the resulting code will have more ’style’ and can hence be harder to read.

On a selfish note, I don’t mind spending the time to be a ‘power user’. I spent the time to learn the keystrokes for vi and emacs, and I can do many tasks a lot faster there than anywhere else. As a power user you want the tools that allow you to express your ideas in as simple a way as possible.

So, it isn’t for everyone, but give me the smartest parser in the world, let me write as little as possible, and I will be happy ;)

I am really excited about XmlHttpRequest being available in the major browsers.

One of the main reasons is that I think it really enables componentization.

Take the example of a portal, with 10 components on the screen. In the past the web application would have to round-trip to the server, and rerender everything. What a waste of time!

Now, with XHR, each component can talk back to the server if it needs too, and the rest of the page stays put.

Ok, more efficient, but is it that big a deal?

I think it is. The real power comes in when you think about having plugged in those 10 components from DIFFERENT SOURCES. That works just fine now, whereas it would be a real PITA as the portal software would have to coordinate everything in the past. Now, each component truly is its own component, and our clients talk directly to its server-side representation.

I expect to see a lot more ideas such as Y!Q, that make use of this.

I agree with Cedric.

The “best” programming language, doesn’t mean the one that creates the lowest wc -l.

I actually always found myself writing quite “verbose” Perl code, for example.

However, I do feel that languages such as Ruby, Groovy, and yes… even Perl allow me to get closer to the zen of “expressing everything I want, and need to get across… but not more”. Every operator/method tells me a lot.

For example. Compare the code for taking out some text from a string:

Groovy:

name = “Dion ‘Sick Boy’ Almaer”
name -= “‘Sick Boy’”

and in Java? ergh.

Dynamator 1.5 has been released.

Dynamator is a simple tool that can be used with any page generation technology to completely separate HTML from server code. Dynamator transforms HTML or XML files into server pages or programs. It can generate JSP, XSL, Velocity, and even plain Java.

Dynamator 1.5 features major performance improvements, syntax validation, a documentation refresh, and a large number of minor enhancements and bug fixes.

It looks similar to XMLC. I am always a fan of technologies which leave the HTML as HTML. This way designers can dink around, viewing something that looks like the real thing without having to go through a round-trip.

Using the id=”x” approach definitely gives you this ability (like XMLC, and Tapestry with its jwcid=”x”).

It is also interesting that you can use Dynamator with many page generation technologies and it is “build-time”.