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.
Resources
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
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:
$(“tr”).hover(function(e){$(this).addClass(“highlight”)}
,function(e){$(this).removeClass(“highlight”)})
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.
Sam,
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
equivalents.)
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.
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.