I started ranting this morning on Marc Palmer’s blog in response to a post he made about the implementation of JavaScript UI frameworks as plugins to web frameworks. Marc and I have an amicable professional relationship (even though he went through a strange Toto phase), and I think it better to post my response as a blog post of my own. So if you want to get some context for this rant, take a look at his post first, although it is not required to understand my points.
Today’s “Web 2.0″ UI requirements are complex, yet developers still think they can install a UI plugin framework and use the widgets as-is without having to learn any JavaScript, or how the underlying JavaScript frameworks operate. I understand why developers want something they can install and configure with unlimited options and extensibility — something that automatically adjusts to all their requirements — without them having to write a line of JavaScript, but that’s just not possible.
And not just enough JavaScript to get your widget communicating with the server, either. I think we all know that when you write cludgy code in a language you don’t truly understand, you’re creating major maintenance problems for folks down the road. Especially when you’ve just trial-and-error’ed yourself into a volatile UI solution that works at them moment… but you’re not really sure why or how.
JavaScript is a lot different from Java, Groovy, Ruby, etc. It is weird, at times poorly implemented, and just a very odd language — so bite the bullet and start wrapping your head around it. There is no classical inheritance, so you’d better try to understand prototypal inheritance. There are no classes. It is dynamic and weakly typed. Get used to it, because your UI is going to suck if your JavaScript sucks.
If you’re creating rich-client UIs using JavaScript, you’ll want to start thinking about your UI as not just the “view”, but an application container for your JavaScript applications. Each page you render with rich content is in itself a JavaScript application with a lifespan. Think about it like this: The UI is your web application; the web server is a middle tier that serves up the markup, data, and code the UI needs to run, and database serves the middle tier with persistent data:
Rich JS Client page life cycle
Obviously, there is a need for middleware plugin frameworks that help incorporate JavaScript libraries into our web frameworks. This middleware can help “serve up” the UI application to the browser by providing shorthand markup to produce the necessary JavaScript code. The reason I started working on GrailsUI was because I needed extensible, reusable baseline components that operated in the same fashion throughout my web application.
Too often, the UI implementation is poorly envisioned, poorly designed, and poorly estimated. It seems like the backend functionality is usually treated as a “critical component” within an application requirement, leaving the UI as somewhat of an afterthought. By the time the developers have licked the “real” problems (database transactions, server-side data manipulations, etc.), then it is time to “whip together” a UI that allows the user to interact with the new functionality. Most java developers seem to dabble with JavaScript in this capacity, treating it as a curious and fascinating oddity, a side show language that no one really knows how or why became so integrated with the DOM.
Well, if you find yourself in this role right now, and you are feel a little uncomfortable because JavaScript isn’t doing what you think it should be doing… my friend, it is time to step up to the plate and make a concerted and diligent effort to learn JavaScript before you really screw something up with your web application. If you don’t know what you are doing, you’ll not only slow down your site, but you’ll open up security issues, clobber global variables, tie your view logic in knots, and leave a legacy of filth and tangled debris in your wake. If you don’t understand why it is better to add event listeners apart from the markup instead of adding an ‘onclick’ attribute with inline JavaScript to your HTML elements, programmers coming behind you will curse your name, remove you from their LinkedIn contacts, and add your email addresses to spam mailing lists.
Do yourself a favor: Treat your rich UI as a first-class application in itself. (You wouldn’t knowingly write crappy code on your middle tier, would you? So why would you in your UI client?) Understand that you cannot install a plugin or a third party middleware product that will give you every JavaScript widget you will need. Know that it matters much less what JavaScript library you choose to use (YUI, Ext-JS, Prototype, Scriptaculous, jQuery, etc.) than how well you know the JavaScript language.
13 Comments
Another way to say this is that if you don’t take the time to learn javascript, you’ll be forced to learn it piece-by-piece as you debug and modify the UI. Something else for old-time web developers: it may be worth your time to re-learn javascript. A lot of the stuff I did way back when (yah, like including onclick attributes in the HTML) would be awful for maintainability/robustness in complex Ajax interactions that target Web standards/multiple browsers.
I insanely disagree with this blog post, it’s not only “possible” to do Ajax without knowing or using JavaScript, it’s in fact *easier* and *more-flexible* depending on which Managed Ajax Framework you’re using. An example here would be Ra-Ajax which samples (at http://ra-ajax.org/samples/ ) are featured completely without *one-line* of custom written JavaScript. And stuff like this; http://ra-ajax.org/samples/Ajax-Forum-Starter-Kit.aspx is probably so difficult to implement in JavaScript you would effectively end up *not-being-able* to deliver it at ALL…!
Disclaimer; yes, I work with Ra-Ajax…
@Thomas I understand your argument, because I have worked on an Ajax plugin framework for web applications as well. But here is my case-in-point… Looking at your Calendar example, how hard would it be to include time selection within it? Or to allow a date range to be selected within one calendar? Or enable conditional row coloring in your data grid? If you could do that without writing any real JavaScript, then I would be impressed with your framework.
There are an infinite number of things our users might want to do with our ajax frameworks, and we cannot present an easy option for every possibility. If they are happy with the basic components, then that’s great, but they probably aren’t designing their pages correctly if every component satisfies their requirements as-is. In order to create sharp, custom UIs, they’ll need to write a good amount of JavaScript (even when using our frameworks), so they’ll want to learn the language they’re writing. All we can do as framework developers is make it easy for them to access and/or configure the underlying JavaScript components.
I agree with the post wholeheartedly. For what it’s worth, Ra-Ajax seems to be either incredibly slow, or break terribly in Safari.
Unfortunately, this blog post describes me down to a tee at the moment :) The bullet will have to be bitten at some stage i know, but GWT can create some pretty amazing looking web-apps, even more so with GWT-EXT, some of the stuff my colleagues have created using it looks amazing!! It is definitely worth a look to any Java developers that may not have the resources to start from scratch with JavaScript! It does have its own learning curve, especially if you have no swing experience! (I just wish I could develop GWT in groovy……. some day! :-) )
Completely agree with the blog post. I don’t know a single ajax framework that doesn’t require expert Javascript knowledge at some point. The majority of them TRY to tell you that their framework is the only thing you will need, but it’s simply not true. As for you team leads who just expect your server side devs to pick up js as they go- you’re in for a world of hurt. Learn it, and learn it well.
I also agree with the post. Knowing JavaScript is very important. What happens if something goes wrong in a framework? You need to be able to figure out why things are happening.
Sorry Thomas but I have read your blog. Unfortunately attacking John Ressig or saying things like “JavaScript is the Assembly Language of the 21st Century!!! Nothing John says or creates can fix that…” really detracts from your Framework’s credibility.
I’m hoping GWT is going to be my route into creating robust JavaScript UIs without having to re-invent every wheel (and every newby mistake along the way!) for myself…
@John Rellis: Check out:
http://code.google.com/p/derjanandhisblog/wiki/GWTGrailsTutorial
Thanks for an interesting post. Are there any JavaScript resources that you would recommend to someone who wanted to brush up on their JavaScript skills?
@DK Douglas Crockford has an excellent presentation series on Yahoo! Theater about the JavaScript language. Here is the first of 4. They are all good. He also have several further presentations there about advanced JavaScript, JS and the DOM, and AJAX. All great stuff.
Amen! UX (user experience) matters immensely. Frank Lloyd Wright said it best “Form follows function-that has been misunderstood. Form and function should be one, joined in a spiritual union.”
One thing I don’t see enough is TDD and unit testing with javascript. It seems that we will spend enormous amounts of time and put in as many lines of code to test the server side but then throw the whole concept out the window when we get to JS and the front end. I have seen some really nasty JS front ends that were held together with bubble gum.
So when you learn javascript remember to use one of these.
docs.jquery.com/QUnit or http://www.jsunit.net ( google for others)
Hum… I don’t know if I agree that you need to know Javascript to write an Ajax based application. At least on the Java end, I know Echo from nextapp, I know thinwire and I know zkoss. Those frameworks don’t require you to write a single line of Javascript. So, it isn’t totally true.
I think it is beneficial if you are using something like GrailsUI, Prototype, JQuery or any other Javascript based library, because the models used by thinwire and echo are the same used by swing developers, which is quite a pain in the arse to work with. But we can’t assume with 100% certainty that you can’t right ajax based apps without javascript. Yes, you can. Now, in Grails context, are those frameworks really useful? How well do they integrate with Grails? ZK (I don’t know about echo2) allows you to write code in Groovy, and the plugin allows you to access the models, but does it really fit the way MVC works in Grails? Nope, it doesn’t. So, I think that by using GrailsUI or any other Javascript library, would best fit the bill here, and in that case, yes you would have to learn Javascript.
Those are just my 2 cents.
All the best,
Fidel.
2 Trackbacks
[...] UI Developers? LEARN JAVASCRIPT! (tags: javascript) [...]
[...] I’m not going to pull any punches when I tell you to learn JavaScript. GrailsUI can only do so much for you by setting up components with sensible defaults. But for [...]