I always hated Javascript, because it seemed like web pages that
made heavy use of it never worked. And they did things in
Javascript that could be done in straight HTML, more easily,
more portably, and more reliably.
So how come I’m so happy with Appia,
when it currently has 5826 lines of Javascript in it? (Compare that to
the only 22,611 lines of Perl in today’s Appia source for what I
always call a “Perl application”!)
Molly Holzschlag brought this
topic back to mind in her recent post, asking
is
Javascript the new black? Things have changed with Javascript,
and it has become a great tool even for web developers who insist
on standard and reliable technology.
That’s because, though Javascript hasn’t changed (much) since the old days,
the objects we’re using it to manipulate have.
Back in the 90s, Javascript code on web pages operated on browser
objects. The browsers were constantly changing, trying to one-up
one another, and made little effort to be compatible with each
other (or even with other versions of themselves). So you couldn’t
really count on your Javascript program working right.
Nowadays, in Appia and many other web systems, Javascript is used
to modify objects in the Document Object Model
(or DOM). The DOM is the logical data structure of your web page,
and it’s standardized.
Not that browsers always follow the standards perfectly, but the
situation is so much better than it used to be that using Javascript
to modify the DOM can be done reliably and usefully.
What do we do with Javascript in Appia? Well, we started with
some simple things that made many of pages more comprehensible to
the user. First we used it to change the CSS style
display property, hiding and revealing parts
of the page on the fly. This reduced navigation, because we could
give the browser a pretty large page without swamping the user
with information. Clicking on an icon would reveal deeper details
about parts of the page without actually fetching a new page.
We also made it possible to sort tables in the web browser, again
without fetching a new page, making Appia more responsive.
Then we started realizing how powerful this was, while still being
controllable. Sure, there were little quirks from browser to
browser, but we could create Javascript code that worked on all
recent, standards-based browsers. (And that’s without
having the code figure out the browser it’s running in and performing
different operations depending on the result.)
The biggest benefits to using Javascript to manipulate the DOM
came from changing forms on the fly. Want to fill in information
about several sites in a project? Just click a button to add
(or remove) a row at a time in a site editing form. The form
changes instantly; no web page fetches and refreshes. And we
can also calculate totals for project bids
as the item bid data is entered, without having to wait for the
user to finish, click “submit”, and wait for a new web page to
come back from the server.
Because of how Javascript was used in the past, for small snippets
of what was often just glitz, 5826 lines of Javascript sounds like
a lot. But for an application that provides highly interactive
and reliable project definition, bid based estimation, and bid
data entry (among many smaller jobs), that’s hardly anything.
We’re getting an huge return on our efforts with Javascript and
the DOM.
Charles Engelke's Blog 