[PW] standard web development tool for managing service oriented websites

[John Franklin]

On Aug 23, 2007, at 1:39 PM, Anne Marie Barter wrote:

> Have not found much in the current literature on this topic, any  
> suggestions
> would be greatly appreciated. annemarie.barter at statcan.ca
>
> Question: whether there is any development of a defacto standard web
> development tool for organizations managing large service oriented  
> websites
>
> is javascript becoming that standard?
>
> are organizations moving away from tools such as dreamweaver, front  
> page and
> visual basic programming?

Here's a stab at answering these questions from someone who's done a  
lot of tinkering with such things. (Apologies for the length of the  
message!)

There is no single de facto standard for web development tools,  
period, whether for organizations or individuals.

[Related Note: There are, however, quite explicit standards for web  
pages, which are maintained by the W3C (World Wide Web Consortium).  
You can test a page to see if you're doing it right using the W3C  
validator, which is found at
http://validator.w3.org/
If a page fails validation, then purists won't like it, and more  
importantly it is more likely to look "wrong" when viewed in new web  
browsers (either new versions of the ones you have tested, or other  
browsers entirely). And note that even if your audience is running  
only one web browser, a site which fails validation but still "works"  
may fail if the browser is updated. Validation doesn't just please  
purists, it helps future-proof your design. Most tools support HTML  
validation in some way, so it's a good idea to incorporate it into  
the standard development process. This message brought to you by the  
Coalition of Web Users Standing Against Important Design Errors.]

Javascript is not a web development tool. (Well, okay, there are  
server-side Javascript implementations, which could technically be  
used to create a web development tool, but as far as I know there are  
no widespread products that do so.) Javascript is a programming  
language and API which allows web pages to run programs on the  
viewer's computer. As an analogy, "Javascript" is roughly to "web  
development tool" as "paint" is to "paintbrush" -- the terms are  
related, but the one is not part of the other.

If you mean, on the other hand, "is Javascript a standard system used  
to provide services to users on the web" then the answer is a bit  
more complex.

Javascript is not a good language for producing services directly. It  
is (intentionally, for security reasons) limited in its features, and  
(unintentionally, for many reasons) very slow compared with other  
options. For example, you might build a Javascript-based phone  
directory, where a script would pull up the information directly.  
This would be quite possible, but all the data would have to be in a  
format understood by Javascript and embedded in the page (or pulled  
in by reference). Every time the user loaded the page, their computer  
would have to download Javascript containing all the information  
(slow, and possibly not secure), and depending on how the Javascript  
parts were written, the program might become very slow when there  
were many numbers listed. And in addition, most browsers have a limit  
on the amount of script allowed in a single page; it's the main  
reason nobody has developed a serious Javascript-based graphics program.

[In particular: you should never attempt security through Javascript.  
Since all data and code used by Javascript has to be explicit on the  
user's computer, if a password is authenticated by Javascript, then  
the user will be able either to see the password, or the system used  
to encrypt the password and the desired target value, thus clearing  
the way for a brute force attack.]

That, however, is not the end of the story. Although Javascript is  
not good at data storage or heavy-duty processing, it is an excellent  
way to control the interaction of elements on a web page. A system  
has evolved over time in which Javascript controls the appearance of  
a web page, loading data from a server invisibly and presenting the  
results, giving the illusion that a single web page gives all the  
information at once. This technique is called AJAX (for Asynchronous  
Javascript and XML), and it is becoming very common, but as far as  
standardization goes it is still rather murky; at present you must  
write at least a little separate code for Internet Explorer and All  
Other Browsers. (This should surprise nobody who has done any web  
development, given Microsoft's history.)

[Note: AJAX often -- although not inevitably -- has some undesirable  
side effects. The Wikipedia page "AJAX (programming)" does a good job  
of outlining them at present, but here's a summary: (1) Since an AJAX  
service does not necessarily load a new web page, it can break the  
"back" button, which may be extremely frustrating to users. (2) AJAX  
services may also make it difficult to bookmark specific information,  
since the data is not necessarily related to the URL of the page. (3)  
Search engines may not be able to index information which is provided  
through AJAX-based services. (4) Older browsers (or simpler browsers,  
such as those on some handheld computers) generally cannot handle  
AJAX well, or at all, making AJAX services undesirable in some  
environments.]

Alternatives to Javascript exist, but all of them which come to mind  
involve embedding a program in a web page as a single alien object,  
without access to the content of the page itself. (Examples include  
Java applets, Flash media files, and ActiveX controls.) (The latter  
also has the limitation of working only on Windows, and not working  
on browsers other than Internet Explorer without extra work for the  
user.) The tradeoff is that these alternatives are likely to be far  
more powerful and predictable. A Javascript function may fail  
suddenly if it accesses a feature not present on that specific  
browser, but a Java applet will (aside from limitations of network  
access) either run the same way as it did on the developer's machine  
or not run at all.

A third possible interpretation of your question is "has Javascript  
finally become standardized enough for an organization to want to  
work with it?" The answer to this question depends on who would be  
running your Javascript and what your Javascript would be doing.

All those old browsers which had mutually incompatible versions of  
Javascript -- creating Javascript's bad reputation in the first place  
-- are still out there, albeit in much-reduced numbers. If your goal  
is for 100% of all possible users everywhere to be able to use your  
Javascript, you are out of luck. Try again in about 20 years, when  
hardware failures will have forced practically all of these users to  
upgrade.

On the other hand, you may be developing for users who are reasonably  
up-to-date (as in most higher educational institutions), or for users  
who are required to use fairly recent browsers or the same version of  
some particular browser (as in most corporations with strong IT  
departments). Either way, you can safely ignore the older browsers.

It may also not be important for all users to be able to access your  
site/service/page. If your service is strictly voluntary -- nobody  
will ever need it desperately -- then you can develop for some  
particular browser/version combination or combinations (it's a good  
idea to test in at least two different browsers, just in case), make  
sure it works where you say it will, and just post a notice that all  
other browsers are untested and may not work.

What the Javascript does also determines how compatible it will be:

If you want to read information from form controls, do some basic  
text or number manipulation, and load new pages, then with a little  
care you can support an overwhelming majority of users -- over 99%.  
(And the few users you don't support will be used to things not  
working at this point.)

If you want to do some reasonable manipulation of the page content,  
react to standard events like mouse clicks, and use timers, then with  
a little more care (and careful testing) you can probably support  
nearly as many users -- although you may have to break down and write  
some browser-specific code. (If you do, keep it in a separate file,  
in order to make it easier to maintain if future browser versions  
need different code.)

If you want to do highly specific manipulation of the page content  
(as, for example, most Javascript-driven animation), work with  
anything but the most trivial parts of AJAX, and react to more  
complicated events like mouse drags, then you are in for long  
sessions of debugging and lots of browser-specific code.

The good news is that although there are many browsers and many  
versions of each browser, it is fairly easy at this time to make sure  
that your Javascript supports around 95% of them, as long as you  
avoid browser-specific code. As of the end of July, the top five  
browser/version combinations appear to be IE 6, IE 7, Firefox 2,  
Safari 2, and Firefox 1.5. Between them, according to
http://marketshare.hitslink.com/report.aspx? 
qprid=6&qpmr=55&qpdt=1&qpct=3&qpcal=1&qptimeframe=M&qpsp=102
they have just over 95% of the market, with no single other browser/ 
version taking even a full percentage point. (Safari 2 is listed as  
"Safari 41", that being the first two digits of the build number of  
all releases in the 2.x version. These numbers may, of course, be  
disputed, but probably not much.) Well, any Javascript which runs on  
IE 6 will almost certainly also run on IE 7, and any Javascript which  
runs in both of those which runs in Firefox 1.5 will almost certainly  
run on Firefox 2 and Safari 2. So if you just design for (and test  
in) IE 6 and Firefox 1.5, chances are very good that your Javascripts  
will work in all five, and quite probably others as well. More  
testing is better, of course.

And for the last question:

I can't claim to be privy to any special information about  
Dreamweaver and Frontpage. (Other than that Frontpage has been  
discontinued as such, of course. From now on, Microsoft will not be  
including a web page builder in Office, and will be selling a pair of  
programs which will not be called Frontpage.) But it is worth noting  
that such editors have as their primary goal WYSIWYG editing of web  
pages, not large site maintenance. (There are features to support  
maintaining a large site, but it just isn't the main purpose of the  
program.) If the conceptual simplifications for a large site -- such  
as server-side includes, ASP master pages, or consistent use of  
cascading stylesheets -- are beyond you, then Dreamweaver won't  
actually help you very much beyond making each individual page  
editable in a GUI, which may or may not make sitewide changes any  
simpler. For this reason, many developers never really started using  
graphical editors in the first place. (Not that I consider myself  
particularly exemplary, but I do all my development using nothing but  
a copy of BBEdit, along with a couple of open web browsers and a lot  
of page refreshing.)

Visual Basic, on the other hand, is not a web development tool but a  
language/API (like Javascript, except that VBScript generally runs on  
the server instead of the viewer's computer). There is, presumably, a  
trend toward using VB.NET or C# to generate pages directly instead of  
using in-page scripting, since that's a new technology on that  
platform and the people who want to use it are probably moving away  
from in-page scripting, but in-page scripting is still supported and  
probably won't go away any time soon.

You might also, I suppose mean "is there a trend away from code- 
generated pages, such as produced by Visual Basic scripts?" The  
answer to that is a resounding "no". The only significant long-term  
trend is that the number of ways to generate a dynamic web page is  
growing. Microsoft now has at least 6 ways by itself, and they  
certainly don't hold a majority in that game. (I don't touch their  
stuff myself, preferring to avoid people who try to patent logic  
operators; that isNot something I want to get mixed up in.)

I hope this helps. (I also hope I'm not incoherent from hay fever and  
lack of sleep.)

-John Franklin