Will Iverson's Blog

Rethinking web development, or "Will I be spending the rest of my life writing JavaScript"?

I remember when I first started doing Java development, and the first time I saw a servlet in action - I thought it was awfully cool that the HTTP protocols were so seamlessly wrapped up. Wow.

A lot of folks noticed that writing HTML by hand in servlets was pretty nasty, and so the idea of "flipping the code" was born. Instead of writing nasty HTML in Java code, we would write nasty bits of Java in our now even nastier HTML.

This more or less worked pretty well for a long time. I had to teach a lot of newbie web designers how to find generated Java source files and figure out how line numbers mapped to the originating JSP files. Tools like Dreamweaver MX were helpful for wrangling the HTML, and this model seems to be the inspiration behind Java Studio Creator.

But... and this is a big but... all of this has gotten a bit out of hand, and it's well on the way toward turning into an absolute nightmare with Ajax. The underlying theory here is that there is a "web designer" who does a bit of futzing with JavaScript, and there is a server-side developer that does the "hard stuff."

Let's conduct a little experiment. Go to http://maps.google.com/ and view the source. Now, let's check out the Ajax examples for J2EE from the Blueprints group. There is a lot of JavaScript code there, stuff that needs to work on multiple browsers, on multiple platforms. Portability across browser platforms is still a bit of nightmare.

How do you think they test Google Maps?

Is the newbie web designer supposed to be the guy writing and/or tweaking all of this complexity? All of the JavaScript? All of the custom JSP and JSF tags in the monstrous XHTML file?

The answer, I think, is to stop viewing web applications as "tweakable" lumps of DHTML or XHTML, the same way that we don't really view class files as "tweakable" lumps of bytes to be edited by hand. If I handed you a class file and told you that you could "tweak it" if you had any problems, only the very, very, very geeky among you would think that was a good idea.

Instead, think of a web application as an application like any other, but it happens to render (under the scenes) to DHTML & JavaScript, instead of a native graphics toolkit. For the vast majority of applications, it's a much, much more efficient model for building an application (it also happens to be much easier to debug). For a very interesting example of this, check out the programming model underlying Echo.

That's all for now, but I do want to follow up with one last thing - we are looking to hire good Java developers here at work. If you live in the Seattle, WA area (on the Eastside, for those of you keeping track), and are interested in working in an agile environment with a really, really great team of Java developers on a long term basis, please drop me a line at wiverson AT gmail DOT com. We're doing a mix of web applications, web services, Swing... all sorts of interesting things.

Comments

• I agree that there another layer of abstraction will help for many of the typical apps that want to implement ajax for standard things like autocomplete or form validation. I think there will always be a role for more manual Javascript coding, however, for the more complicated apps that simply can't be done using something like Echo2. I haven't had a chance to play with Echo2, yet, but if you can take its generated javascript/DHTML and modify it w/o breaking things, there will be some great potential there for an extendable ajax framework.

  Posted by: rsanheim on July 11, 2005 at 07:24 PM

• Hi rsanheim - so, who do you think would be wanting to tweak the JavaScript/DHTML? The "server-side" developer or the web designer? For what end?

  Put another way - is it the server-side developer who wants to tweak the behavior or add some custom JavaScript (for example), or the "web developer"?

  Posted by: wiverson on July 11, 2005 at 07:50 PM

• Will, you have a point that requiring page developers to twiddle all this JavaScript is a non-starter. But I think your suggested approach (think of a webapp as something that has to render xxx) is too coarse grained. Instead, you should look for components (in whatever component technology you like) that do all the grunt work for you, at a fine grained level. Just as one example, there was a keynote demo at JavaOne that showed how you could encapsulate typing autocompletion (like what Google Suggest does) in a JSF component; this was later covered in more detail at a separate session. The code is available in the BluePrints Catalog project at Java.Net:

  https://bpcatalog.dev.java.net

  With a tool like Creator, of course, it's quite pleasant to be able to drag and drop components like this :-). But, even if you are editing your JSP pages by hand, the only thing you need to do is type in a typical JSP custom tag (just like a Struts HTML custom tag). JavaScript, what JavaScript? Using AJAX is easy, if you delegate the complexity to component developers, instead of application developers.

  Craig

  Posted by: craig_mcc on July 11, 2005 at 07:52 PM

• Nightmare?

  What on earth could you mean?
  We've got browser-dependent multi-lingual distributed presentation logic. We've got some client side logic and some server side logic. The client side logic is written in JavaScript, and is very dependent on the foibles of the specific browser and the nuances of dealing with the DOM, and the server side logic is written in Java, and our data exchange format is either XML or JASON.

  What could possibly be simpler? ;-)

  --John

  Posted by: johnreynolds on July 12, 2005 at 06:14 AM

• A bigger problem is that XFORMs or similar efforts are taking way too much time. Until the browsers can agree on better standard extensions we'll have JavaScript/Applet addictions.

  Posted by: smartinumcp on July 12, 2005 at 08:33 AM

• Well, I think that « The underlying theory here is that there is a "web designer" who does a bit of futzing with JavaScript, and there is a server-side developer that does the "hard stuff." » is wrong in many cases. There is someone else in between that does all the XHTML and Javascript and integrates it into the backend system. This person receives Dreamweaver code and basically adds seperation between structure, presentation and behavior and makes the code standard compliant, accessible and basically friendly for Google. Stuff that designers and backend programmers might not be knowledgable on and that Dreamweaver does not do perfectly. That person knows enough Java and object oriented methods to be able to program the renderers, taglibs, JSF, tiles definitons etc and will do the XSLT and integration to the CMS if there is one. Those people tend to be forgotten and I have been told numerous times that their job will disapear because everything they do will be automatically generated (almost 10 years now actually...). Right now, when you go from the Designer directly to the Java programmer, it tends to make the resulting HTML awful and generaly the resulting system will work only on one browser and be unfriendly to Google.

  If you take into account this person, AJAX is quite simple and there is no need to hide the Javascript code to the "evil designer". Also, the designer will also have no need to try to hide his/her HTML to the "evil Java programmer". :-)

  Posted by: bpiette on July 12, 2005 at 10:02 AM

• Hi Craig!

  Actually, I'm in complete agreement that the overall model needs to be component based. No single web app framework will have all of the functionality in it out of the box, so ipso facto you need some way to extend it. That's one of the reasons I'm very bullish on JSF in general in fact - there is a robust component model and there are a lot of vendors supporting it (that GIS example at JavaOne was a very compelling example).

  My biggest concern with JSF/Creator is the reliance on the JSP pages to stitch everything together. Even with the tool operating strictly in visual designer mode, it's very easy to get to a point where either the in-IDE visual designer gets confused and/or when you try to view the page it blows up in the guts of the JSF expression evaluation runtime with no stack trace and no way to tell where or what the error was. Even if you are an experienced Java developer, a typo in the bowels of a monstrous XHTML file with no real error reporting or line numbers is a bit daunting. I can post several examples if you'd like...

  Ironically, I was looking over the JSF 1.2 spec, and it looks like simply adding a ViewHandler and some naviagtion standards for a pure-Java component assembly would basically eliminate the need for the JSP pages. Then, a bad component assembly would (presumably) throw an exeception with a proper (ordinary) stack trace.

  Even more ironically, NetBeans already has support for JavaBean application assembly for Swing-based desktop apps. You could probably mock up and prototype JSF app assembly as non-visual JavaBeans in the NetBeans form designer pretty easily to get a feel for how that would work.
  

  Posted by: wiverson on July 12, 2005 at 10:03 AM

• Hi bpiette!

  What do you call that person? We've had a few openings for folks with somewhat odd skills sets mixes lately (e.g. an "Object-oriented Flash Developer"), and I've found it hard to find people with the skill set you're describing - most people tend to self-describe as either "web developers" or "Java developers," but the people who know both the gory ins-and-outs of JavaScript and understand solid OO-development seem to be hard to dig up.

  Posted by: wiverson on July 12, 2005 at 10:08 AM

• Will,
  Check out the java.net facelets project. It builds on Hans Bergsten's thoughts.

  If we can chip in and help the facelets effort, we might get consensus on a non-JSP JSF methodology.

  --John

  Posted by: johnreynolds on July 12, 2005 at 11:10 AM

• john/everyone, I would more than appreciate contributions to Facelets! I've gotten lots of excellent feedback so far on the framework.

  I've been emailing back and forth with Kito Mann on Facelets and some ideas revolving around JavaScript support within the JSF EG. I'm also working on getting a series of short articles ready for Kito's JSFCentral.com. The articles will be on the ideas behind Facelets and some of the features-- Introduction, Using Facelets, Templating & Re-use, and Tag Development.

  Posted by: jhook on July 12, 2005 at 11:51 AM

• Pertaining to JavaScript support itself with JSF, there should be 'clientScript' support with the rendering process. Too many times developers treat their components (custom JSP tags) as being a singular instance within a document. Since components can be replicated 40 or 50 times within a document, it's not really practical to tie JavaScript output within the scope of a component's rendering process.

  In terms of web standards, the goal is to create maintainable separation within the view. On one hand you have your structual XML markup as provided by the renderer, and on the other hand, you provide external resources that define the style and behavior of your structual markup.

  The common example of this is CSS use. Facelets includes a demo of a project that I'm starting for work (which actually should be removed) which uses CSS to do amazing things while keeping the semantic structure of the document both clean and simple.

  The next step moving forward is enforcing the externalization of behavior through JavaScript. A use case would be an AJAX component that gets rendered 50 times on a page. You don't want to duplicate the supporting behavior (JS) 50 times in the page, just the XML structure. There are new approaches where instead of replicating JS behavior, you place a single generic call within the document that gets invoked at initialization by 50 components. This may sound a little confusing, but the idea is that 50 components share the same blocks of JS within the page and simply pass in their xml:id as a target for behavioral decoration. This also benefits bandwidth use as repetetive bytes are removed from the document.

  Only once 'client scripting' is supported within the render cycle for components that encourages 'decoration style' JS, will I ever consider AJAX 'support' within JSF.

  Posted by: jhook on July 12, 2005 at 12:03 PM

• Yeah, that's why Sun created Java Applets ten years ago :-/
  I've passed by these problems before and I realized that deploy Swing based aplications via Java Web Start and Applets sharing business classes using RMI and EJB's are the best solution.

  Posted by: hlalves on July 12, 2005 at 12:48 PM

• JHook,
  It would be great if you'd start some forums over at the facelets project. I'm sure you'd get a lot of feedback and participation.

  --John

  Posted by: johnreynolds on July 12, 2005 at 02:39 PM

• Will,
  I think we could call this person a Web Presentation Developper, as opposed to a Presentation Developper, who will grok SWING, SWT and likes. I am not sure I like this term, but I think it could do. And I think there is also a difference between a Web Designer and a Web Developper, the designer does more Photoshop, Flash and Dreamweaver, and the Web Developper is more into HTML, Javascript, CSS, JSP, ASP, PHP, etc.... I have never met an Object Oriented Flash developper, sounds like an interesting job though... There are so many ways to do bad design with Flash that's it's difficult to create rich applications with it (no GUI standards). And Flash replicates some browser functions, but it does not integrate really well with Web interfaces. AJAX technologies could do well in Internet applications because they can if correctly designed behave really similar to a normal Web page. People expect Internet Web applications to behave within certain rules (including making the back button work). Likewise, in an "intranet", people expect more Visual Basic type interfaces, that's why Java Web start and Swing applications are so much better.

  I'll also check the facelets project, decoration style js is definitely the way to go.
  One last thing, I think there are two reasons why it is difficult to find developpers with the skill set we described. First, the job does not really exists in the minds of project managers. You are either a Java specialist or a Web designer and nothing in between. HTML is considered too easy and Java developpers can certainly do the HTML/Java integration easily [not true right now]. Secondly, in my experience as a consultant, I tend to do the things teams lack in expertise, HTML / back end integration is one of those things. Java programmers (the ones I know) don't like to do HTML and HTML coders without OO knowledge won't touch Java. Also, this skill set makes you a sort of generalist, which is more and more recognized as an important part of a team. That was not the case a couple of years ago, reducing the likelyness of someone doing this as a career move.
  -Ben

  Posted by: bpiette on July 12, 2005 at 06:39 PM

• lol, I actually started out as a web designer for a consulting company, but got tired of programmers messing up my layouts when they dropped all of their server side code in. Because of it, I ended up getting a comprehensive degree in CS and have been working on ways to alleviate the issues I experienced ever since. Facelets is my love child between the designer and programmer :-)

  A lengthy blog on project management with CSS and JSF.

  Posted by: jhook on July 12, 2005 at 07:11 PM

• Hi Will,

  
  As I present AJAX to many web application developer many people have asked: "Will I become a JavaScript developer to do AJAX?" I think for a majority of us the answer will be not much, no, or just a little. I had always pushed back on JavaScript until recently and as I have said many times I spend 10% of my time doing the server-side AJAX stuff and 90% doing the client-side.

  
  So in defense of the BluePrints Catalog I'd like to add to CraigM's comments. There are two types examples which are "nuts and bolts" examples for those curious about "How can I do AJAX with my application today?" and there are component examples which show "How can I use AJAX today in my JSF based application without knowing anything about the internals of AJAX?". JSF provides a great component model which allows AJAX components to be developed that require a page developer to have little or no knowledge of the inner workings of JavaScript. The component examples include a Progress Bar Component, an Auto-Complete Component, and a Dynamic Label Component. All of the components contain very minimal if no JavaScript.

  
  While I don't see all of us going out there and re-creating google maps there is a set of usecases where AJAX can make a better application experience.

  
  -Greg Murray
  

  Posted by: gmurray71 on July 12, 2005 at 11:39 PM

• yes, what is wrong in custom tags that hides JavaScript? Btw, you are even not obliged to use JSF here. Check out ajax tags in Coldtags suite for example: http://www.servletsuite.com/jsp.htm
  

  Posted by: dnamiot on July 13, 2005 at 04:02 AM

• >Since components can be replicated 40 or 50 times within a
  >document, it's not really practical to tie JavaScript output within
  >the scope of a component's rendering process.

  the component itself can take care about own JavaScript code and output it only once per page.

  Posted by: dnamiot on July 13, 2005 at 04:08 AM

This work is licensed under a Creative Commons License.