The Yucky Parts of Web Development: Examples

My OPI Tech Talk, on the Yucky Parts of Web Development, is available as a Powerpoint presentation.

In the talk, I spoke on how a few techniques can give you a jumpstart for the Web side of your applications. The focus was on using these techniques and patterns as a way for those whose main experience has been on back-end technologies to create good-looking pages with a minimum of effort and fuss.

Typically, actual code works better than bullets in Powerpoints. You can run the examples live, or download them, starting with the Examples Index.


Some of the resources mentioned in the talk include:

  • Text spacing example – this example uses extra text spacing beneath your text to create the illusion it is
    evenly spaced.
  • Grids are Good (PDF) – provides an excellent background to using grids for layout. Read this!
  • YUI grids layout – describes using the reset-fonts-grids.css file that comes with the YUI toolkit. Even if you choose not to use the full YUI toolkit, this one CSS file provides a simple way to create a CSS-based layout for your Web pages.
  • Color Blender – use this site to create variants of colors such as lighter (blend with FFFFFF) or darker (blend with 000000) shades.

In addition, two of the better free Web designs include Leaves and Neuphoric. Remember to always check the licenses prior to using designs like these.

-Eric Foster-Johnson

One thought on “The Yucky Parts of Web Development: Examples

  1. Sam Buchanan says:

    Good stuff, Eric. I confess that I’m still puzzled by a couple things.

    This is not the first time that you and others at OPI have asserted that JavaScript development takes about 3 times as long as Java. I don’t understand what you mean by this or where you get the number. Aren’t you comparing apples and oranges? If you’re comparing JavaScript and Swing for UI code, or server-side JavaScript (e.g. Phobos) and Java servlets, then I could at least understand (though I would debate the conclusion). But I doubt that you’re referring to either of those, so where does “3 times as long” come from? Do you mean that a JavaScript-enabled web application takes longer than a plain ol’ unadorned web app written in Java? If so, then again you’re comparing non-equivalent code. I can understand that both the development and deployment environments are different and that balancing the two can be frustrating, but… I just don’t understand where you’re coming from. Can you explain what you mean and where you get that number?

    Second, I remain puzzled about an apparent reticence to using unobtrusive JavaScript. You use CSS to good effect but continue to litter your HTML with unnecessary event-related attributes. Not only does this make the HTML less clean than it could be, but by tightly coupling behavior to structure, you limit re-use and your ability to flexibly manage events. With very little JavaScript, you can instead attach event listeners to elements in your HTML. Here’s one way to do it in jQuery:


    In one swoop, you eliminate the need for all the onmouseover and onmouseout attributes from your HTML. Similar code is possible in YUI, Dojo, or other frameworks – and yes, I know there are ways to make the example more efficient.

    None of this is meant to detract from the otherwise pleasurable and informative presentation. I’ve just been perplexed by these things over the years.

  2. Eric Foster-Johnson says:


    I’m glad you liked the talk. I hope I can clarify some things.

    First off, I’ve been using the basic estimate that JavaScript development
    takes three times as long as corresponding Java development for a number
    of years (since well before I came to OPI, so this isn’t
    an OPI thing). This is based simply on
    observations and mostly has to do with debugging and tooling.

    And, I’m not comparing Swing or extraneous factors like that.
    From my experience any particular task, say processing input
    strings, will likely take three times as long to develop working
    code in
    JavaScript than in Java. For Java, I have a nice selection of
    IDEs and other development tools. I have runtime environments
    and very nice unit-testing frameworks. (By the way, I have
    used JavaScript JSUnit and other tools. They can help, but
    tend to take more time to use than the corresponding Java

    In JavaScript, and particularly for running JavaScript in Web
    browsers, you face a number of issues:

    * On errors, the browser may fail silently, or may present
    an error message. Silent failures take longer to identify, track
    down, and solve.

    * Browsers are different. Little quirks can really bite you and
    take up time. IE, for example, is normally far pickier about
    trailing commas on lists or map items. Firefox is more forgiving.
    Safari has a much smaller limit on recursive code walking
    through the DOM tree than IE or Firefox (an order of
    magnitude smaller limit). This really hits the Dojo toolkit
    hard or any code you would write to walk the DOM.

    Toolkits such as YUI or jQuery go a long way to dealing with
    browser-specific issues but they do not take care of everything.

    * It takes time to exercise your JavaScript code. You need to
    run the Web application, and then navigate in the browser
    to the location where you changed your JavaScript to ensure
    everything works on the page. You also have to address
    browser caching issues to ensure the browser loads your
    changed JavaScript code. This is similar to testing changes
    to, say, a JSP, but exercising the JavaScript tends to
    be even more involved (in terms of time).

    * JavaScript has some quirks in the language that can
    add time for developers primarily focused on Java. The
    way JavaScript converts types to strings is one area.

    * Java’s standard library is far richer than JavaScript’s,
    and far better documented. This helps deal with some
    of the quirks in Java, such as String.split() using
    a regular expression.

    * JavaScript toolkits, while usually quite helpful,
    each have problematic areas. On a recent project, for
    example, I spent a lot of time working with the YUI data table
    to work around bugs in that component. Furthermore,
    even the popular JavaScript toolkits tend to be fragile. It
    isn’t that hard to break apps that use Dojo, YUI, and so on.

    All of these boil down to about three times longer for
    development, based on real-world experience. It is useful
    to know this when planning, especially since many developers
    can estimate the time to develop Java code better than
    estimating JavaScript development.

    That said, there are some very cool things you can do in
    JavaScript. The prototype-based model allows greater
    flexibility in designing libraries than, say, Java’s
    class inheritance model.

    Second, I used a very simple example for mouseover highlighting
    to show that with very little work, you can get some nice
    effects. My goal was to show something completely in the
    talk with very little dependencies. Your example using
    jQuery, while nice, requires also at least introducing
    jQuery, which complicates the example. After years of trying
    the other way (my book Advanced X Window Applications Programming,
    for example, creates an object-oriented widget framework in
    C as part of the examples), I now tend to try to make
    examples as simple as possible and make them stand alone
    as much as possible.

    Furthermore, learning some of the basics really helps you
    understand how the various toolkits work, as well as their
    quirks. Writing an AJAX call by hand isn’t that hard, and
    knowing how AJAX works can really help you get better
    results from using any of the popular JavaScript toolkits.
    By the same token, learning about Java servlets helps
    developers understand JSPs and all the variety of Web toolkits
    such as Wicket, Spring MVC, JSF, and so on. Personally, I
    found that prior experience writing Perl CGI scripts really
    helped me learn how to make Java Web applications.

    Anyway, thanks again for your comments.

  3. dkartio says:

    While using listener can reduce the written code you need to produce, you also put yourself at the mercy of the designers of that particular code. Everything is good, if the code works perfect, but the designers of these js frameworks don’t have the ability to test their code in every conceivable way. So if you have errors, not only do you have to spend the time debugging your code that calls the 3rd party methods, but also (if you have access) the source code from that 3rd party. With a lack of good javascript debuggers that emulate ALL browsers properly, your debug time is a major factor in development

    There are many instances where “littering” you file with event code is beneficial to deadlines and even this litter can be added to the file in a unobtrusive way.

Leave a Reply

Your email address will not be published. Required fields are marked *