The gulf between web site and web app has never been so severed. At one end, there’s a stateless informative web page, at the other, a fully fledged, rich, interactive and stateful application. They both can benefit from the same magic ingredients of HTML, CSS and JavaScript, but depending on your (user) needs, you can adjust the potency to suit.
The right flavour?
For an event that’s grown over the past three years (dubbed “… one of the globe’s foremost conferences for web designers and developers”), I’m a little disappointed at the overall lack of useful technical information for developers. It needed more chili, more hot-stuff. Yes, there is a conflict of interest between designers and developers; perhaps this is something to consider when organising such an event. I attended Future of Web Apps earlier this year, which in comparison contained more cowbell than I saw at my @media debut. Personally, @media lacked inspiration and insight for me as a developer. A little bland.
Tasty – JavaScript with Yahoo!
I’m definitely a JavaScript nut. Yahoo’s openness about OO JavaScript and best practices have influenced the way I develop my JavaScript; understating both its limitless potential and inherent pitfalls. Nate Koechley is one of the Yahoo champions and I was happy to hear him speak at the conference. Nate gave us 12 rules on how to increase site performance (based on testing carried out at Yahoo), which will be discussed in detail back @ the office.
Bones to pick – web applications built on JavaScript?
Jeremy Keith made his point that JavaScript/CSS isn’t the right technology for building a web application, in comparison to something like Flash or Apollo. Google Maps/Mail/Calendar/Docs & Spreadsheets, YAHOO Pipes, Flickr (organiser) and myself totally disagree. The support for JavaScript is ever increasing, browsers are improving and the forementioned web applications have reached mainstream proportions. There’s no denying they’re doing something right – all with technologies natively supported by the browsers.
Aftertaste – unit testing JavaScript?
Dan Webb raised some questionable points about testing JavaScript. He recommended Selenium, an end-to-end testing tool for automating browser testing. He said “… Selenium can be used for testing your JavaScript…”, where really it’s for testing your UI workflow that might not rely on JavaScript (e.g. form completion and tab order). Also, he stated there is no need for unit testing JavaScript (i.e. with JsUnit) – if you felt the need to do this then your code is doing too much.
First point, APIs such as the YUI library are cases for unit testing, along with useful formatting/utility methods you create for your project (e.g. you might have a wrapper DOM method that can be tested standalone). Secondly, if your JavaScript is so simple that it doesn’t require unit testing, then Selenium would also be overkill for testing. Selenium is a powerful tool, but setting up regression scripts consumes time upfront and for maintenance. JSUnit is a fantastic port of Java’s JUnit; if you write good modular code then you can definitely unit test it. When your JavaScript code is UI workflow specific, then Selenium is the way to go (providing resource allows it).
@hh…
So, a few things to think about after the conference. The mushroom curry (day two) was spot on, along with the berry dessert.
weiyen said,
16 June, 2007 @ 5:28 am
What apps do you write under Javascript? Have you developed for the Konfabulator at all? Thats using Javascript as its main engine.
Here is a link to one such resource to learn how to program those widgets.
Just a thought.
weiyen said,
16 June, 2007 @ 1:45 pm
http://fb2.hu/x10/Articles/ProgrammingWidgets.html
Dan Webb said,
17 June, 2007 @ 4:31 am
I stand my comments on testing JavaScript bearing in mind I was talking about JavaScript in the context of a browser and not JavaScript in general.
Your right – Selenium is an acceptance testing tool which is meant for full stack testing of a web application but what I was saying is that it can also be used for testing of JavaScript elements of an application in isolation and I’ve found testing with it to allow much more coverage than unit testing because DOM scripting essentially is a behavior layer so simulating events is the only way to test this whether your code is modular or not. After all, the essence of browser JavaScript is handling events and showing some kind of feedback – exactly what selenium gives us the facility to test. Browser JavaScript is really difficult to unit test effectively. For example, you may assert in a unit test that after running a certain method a DOM element has a certain property set but can you ever rely on that meaning that it’s actually doing what you need it to do in all browsers? Selenium allows you to pick up on this stuff along with all kinds of other things like how you app response to keyboard controls etc. It tests you code in the actual context that it’s running in rather than the isolation of unit tests.
There are cases when you can (and should) unit test parts of browser JavaScript (such as string methods etc in libraries) and, yes, you could test a fair bit of library code using JSUnit but not any of the event stuff. This leaves you with a pretty crippled test suite – a problem which Prototype’s test suite has had. I guess there is a case when testing something like a library that you might want to use both JSUnit and Selenium but, as I said during questions, the way I build browser applications is that JavaScript is a dumb waiter to the server so there’s I’m hardly ever left with any unit testable logic at all (given that the library Im using is suitably unit tested). Everything is the response to an event. If I find that there’s complex logic within my behavior layer that feels like it should be unit tested it does feel like a code smell. Sometimes it is necessary of course, but for me its definitely a sign I might have designed my app wrongly.
Jonny said,
17 June, 2007 @ 11:06 pm
Cheers Dan :)
Guess it does comes down to the type of site we’re building. Agreed, JavaScript events are a beast to test since they have the most disparity across browsers, which makes web development so “special” :P I understand what you mean by the code smell… It would be good to acknowledge those developing larger sites geared up for a rich user experience, however.
So there’s a couple of things to take away from this…
1) Testing the browser event layer is tricky – Selenium is recommended for testing the JavaScript event layer across all browsers, to establish consistent behaviour.
2) Applying Unit testing is dependent upon the complexity of your site. If your site is geared up to be a web application, then Unit testing is viable for your library and API code.
PS: I’m interested in knowing more about the issues with Prototype’s test suite, might be helpful for the points raised here.
paranoid agent chih said,
2 July, 2007 @ 1:04 pm
CSS FREAKS!!!!! What is the difference between Java and Javascript HMMM??????