JavaScript and "serious" programmers

For at least a year I've been worried about the total lack of relation between JavaScript and "serious" programmers. Unfortunately it seems as if JavaScript is still beneath their notice. That starts to annoy me.

The advent of Ajax makes a solution to this problem mandatory. Who will create the Ajax applications? Those who don't know how to write an application, or those who don't know the language the application will be written in?

Who will create the AJAX apps?

For the past few months I've been thinking about the gory production details of the Ajax hype. We'll get a brave new wave of web applications that leverage the power of XMLHTTP. However, before these applications appear online, somebody must create them. Who?

Basically there are two options: Ajax applications are created by client side programmers (XHTML, CSS, JavaScript, accessibility, usability), or by server side programmers (Java, PHP, .NET, Perl, databases, SQL). Neither option suits me.

Client side programmers: no

Now that I'm getting more and more requests to create complex scripts that run into the thousands of lines, I'm increasingly starting to notice that I don't know much about application design. Obviously, I'm going to have to learn the basics of designing applications, or run the risk that my complicated scripts fall apart at the slightest pressure.

In July I was requested to review a book about Ajax. Although I couldn't make as much time as the book required (publishers should start paying serious money if they want serious reviews!), I was immediately captured by the few chapters I read about application design. It was, quite literally, a new world. I had already laboriously discovered some of the design principles the book described without outside help, but others were totally new and exciting. I want to know more about this topic.

Can anyone recommend a good, language-neutral book about application design principles?

More in general, I think that client side programmers can use a bit of education in application design and software development. Typically, our scripts are rather small, both in extent of user interaction and in number of lines, and they don't constitute a serious design challenge.

For this reason, I doubt whether client side programmers are most suited to create Ajax applications. They just don't have enough experience in application design and serious programming.

Server side programmers: no

On the other hand, I feel that server side programmers are unsuited to create Ajax applications, too. Sometimes I get the feeling that they don't want to learn JavaScript, with the possible exception of the ones that visit this and other standards aware sites.

Besides, the unthinking nonsense reflex that "this applications is so advanced that it's never going to be accessible anyway" starts to work on my nerves.

In my opinion, server side programmers should learn modern web development techniques and theory if they want to write Ajax applications. But they don't. (OK, OK, I'm exaggerating. No doubt there will be server side programmers that want to learn. The majority doesn't, though).

A beautiful example of server side disdain for JavaScript is given by the practical chapters of the same book I referred to earlier. Although, as I said, I loved the theoretical chapters about application design, I was shocked and awed by the raw disinterest displayed in the other chapters. Apparently the writer had taken a few days to read up on JavaScript, and then just started to write stuff.

Apart from detail errors like using the item() method that is unnecessary in JavaScript, the writer entertained curious notions about CSS (font sizes in points?), DOM trees (the <body> as the root element?), and the W3C DOM specification in general (the getElementByTag() method?). Unfortunately for his readers, he was a new amateur who didn't have the faintest idea what he was doing.

The worst is: I don't think this is an isolated incident. I'm afraid it's an accurate indication of the way some (many?) "serious" programmers think about JavaScript. It's just that simple client stuff, right? It doesn't even need any objects, right?

Even if I'm exaggerating, I still feel that the average server side programmer needs to know something about modern web development theories, especially those related to accessibility, and has to take the time to actually learn JavaScript. Without these crucial knowledge components he's not suited to create Ajax applications.

JavaScript libraries - substitutes for knowledge?

In response to my previous entries about the New Amateurs, more than a few people said that one of the big problems with JavaScript development right now is the lack of good libraries. I've got mixed feelings about these remarks.

As some of you will know, I dislike JavaScript libraries. Despite this, I'm willing to take a second look at them if "new amateur" programmers who'd really like to do JavaScript right maintain that good libraries are a necessary tool for their trade. I'm willing to extend my hand across the gap between client and server side.

Nonetheless, before doing so I'd like to ask two questions and make one remark. The first question is:

Suppose you're my boss and order me to write a Java application for you, despite my abysmal ignorance of all things Java. I buy a technical reference book, ask around for the best libraries in town, and with these aids start to create my application. Would you, being my boss, consider this a healthy situation in which I'm guaranteed to deliver a quality product to our clients?

I feel that libraries are sometimes regarded as substitutes for knowledge. Without knowing a programming language you can't use it. Libraries are just tools, not magic wands. Besides, the true geek reflex would be: "Are there no good libraries? I'll write my own, even if I have to learn JavaScript ten times over!".

Would hiring or becoming a JavaScript professional solve the problem? It's odd, really, that a software house that uses a certain language refuses to employ experts for that language.

The study of browser incompatibilities is a necessary part of learning JavaScript. You must at least once experience the frustrations of trying to manage a herd of obnoxious browsers by hand.

You don't have to know all incompatibilities by heart, that's what sites like this one are for. However, no compatibility table or library will ever teach you the same lessons as actually managing live browsers. Once you can identify and avoid common causes of their little head- and heartaches, you can revert to libraries, especially since you yourself can now check and maintain them.

Knowledge sharing

As we've seen, client side programmers know little about application design, and server side programmers know little about modern web development theories. But both sides know a lot about the topics the other side needs to learn.

Serious knowledge sharing between client side and server side programmers would seem to be the obvious solution. Unfortunately, in order to have serious knowledge sharing, we must have mutual respect, first. After all, if you don't respect someone you won't take his knowledge and opinions seriously.

And it's here that we encounter the problem. I cannot avoid the impression that many "serious" programmers look down on JavaScript, and don't want to learn it because it's too simple. Instead, they tell an intern to go download a library.

This arrogant and condescending way of thinking annoys the hell out of me. Worse, it's unprofessional. This blatant piece of New Amateurism stands in the way of the true two-way knowledge sharing client side and server side programming so badly need.

No doubt there are companies that understand the ins and outs of both modern web development and application design, and give them equal weight. You may even work for one, lucky you. Nonetheless, the overall pattern seems to tend towards arrogance rather than cooperation. That has to change.

(And no, I'm not going to give the name of the book I reviewed. After my review the publisher seems to have decided the practical chapters needed to be reworked. I haven't yet seen the final version, so I can't really judge it. It might be much better than the draft I read.)

Comments

1 Posted by Jacob on 29 November 2005 | Permalink

I think you've hit the nail on the head. Despite being an amateur (and probably not very good) web developer, I also have a limited background in C++, Assembler, *Proper* BASIC, PHP, whatever, and so I found that aspect of things less of a problem (although I would encounter difficulties in making a complex or large web application). However, the majority of programmers I've spoken to will shun me for even thinking about mentioning Javascript, and similarly most Javascripter users that I've spoken to won't touch server-side scripts. I have no idea why. The two really aren't that different. Ok, so if you're writing server side scripts you know what interpreter version etc you're using (to an extent), and if you're using client-side scripting you have different browsers to accomodate, but the actual languages and methods aren't that different. I don't really understand the animosity (for want of a better word), but I suspect it's because these people have become experts in their fields and don't like the idea that they might not be good at something that's frighteningly similar. This is all speculation of course, but it seems a likely explanation.

2 Posted by Michael Schuerig on 29 November 2005 | Permalink

The distinction between client-side programmer and server-side programmer is too superficial. There are programmers who take their job seriously and programmers who don't. There surely are programmers who specialize in client-side or server-side technologies and know their respective quirks inside out. Notwithstanding, any serious programmer ought to be able to understand these technologies and put them to use after some learning.

Are "serious", server-side programmers looking down on client-side programmers? They may look down on 1990s DHTML gimmickry. Also, every now and then someone complains about how certain tools are dumbing down programming. The later is actually a curious complaint. What's wrong with making things easier? By itself -- nothing. But the problems begin, when these tools enable people who are (still) ignorant of good software development practices to produce systems that quickly grow over their heads. Good software development is in large part about managing complexity. That's what gave us object-oriented programming, libraries(! -- Don't Repeat Yourself), and Design Patterns.

3 Posted by Tim Walker on 29 November 2005 | Permalink

Bring back telnet/green screen applications I say! You wouldn't have any accessibility problems then would you?

Seriously though, as a server side developer I do resent the extra complexity introduced by what is essentially a presentation layer only language. It just seems like overkill. I personally consider it neither simple nor beneath me, it's just yet one more thing to deal with. Please bear in mind that we have to be focussed on functionality - it's difficult not to feel that processing a database update correctly is more important than whether a mouseover effect works. That is not to trivialise the part that presentation plays in good application design, it's just that with web based applications it's so pervasive!

4 Posted by Michael Schuerig on 29 November 2005 | Permalink

Re Design Principles:

For a very thorough introduction, I highly recommend "Agile Software Development. Principles, Patterns, and Practices" by Robert C. Martin (Prentice-Hall, 2003).

See
http://www.objectmentor.com/resources/bookstore/books/AgileSoftwareDevelopmentPPP

5 Posted by grumpY! on 29 November 2005 | Permalink

Well there are now a torrent of Ajax books coming out, so you can filter them by author, rating, or publisher. I've been flipping through one from Manning (Ajax in Action). Its okay.

In terms of programmers...clientside, serverside, webdesigners? Not sure. The client coders are probably making good money/extracting enjoyment milking their toolkit of choice (Windows, GTK, Cocoa, etc). Maybe they'll take up Ajax, but its not clear their skills are that portable anyway. The server side folks don't care, they're focused on performance and resource efficiency. Totally different skillset. The web designers, or as I like to call them, the "crayon crowd" will try very hard and release very broken, possibly terribly insecure apps. I think you'll just have to see new types of coders emerge. The "but" here is that the platform itself is still somewhat weak, and its not likely that the world will be recoded in AJAX, not until we have much higher capacity networks and better development stacks...and lord knows the last thing the world needs is another website. So you may not see as much action as you had thought.

As for the toolkits...what do you expect? They address real weaknesses in the platform. Step one is to make client side coding language neutral. No platform can take off if tied to one language. Maybe a secure parrot runtime or something like that in the future repacing Rhino. This stack cannot grow with only one (quite broken at that) language option.

6 Posted by Brian LePore on 29 November 2005 | Permalink

Perhaps a way to help JavaScript to get rid of its stigmatism would be to promote how it is used in places BESIDES a Web browser. I believe Adobe allows JavaScript inside a PDF. It might just serve a need that they have. If you do that, they'll want to learn more about the language so that they can adequately add it to their personal toolbox of languages.

7 Posted by Ytanium on 29 November 2005 | Permalink

I like JavaScript... but often webdevelopers and programmers hate or dislike it for various reasons:
1) is not (easily) accessible and/or futile to use it in a accessible site (like great companies, states sites...). So big webdevelpment houses usually don't use it
2) is really annoying that ugly feature of JavaScript... browser differences and incompatibilities! I also hate them... and I avoid JavaScript for many years for that reason... Is really stupid a language that needs tricks and conditions to implement also some easy and common tasks...

Well... just my 2 cent...

Finally I used it with my thesis work... I use JavaScript to exchange XML records edited through a HTML form generated from a XML Schema.
Great JavaScript after all... Now it needs only a great unification and standardization (but an effective one... not a "paper" one ;-) )

Thank you for your great site!

note: sorry for my poor English!

8 Posted by kirinyaga on 29 November 2005 | Permalink

I am an application developper. When I first discovered the true versatility of JS (by reading sites such as quirksmode), I was amazed. Until now I avoided it at all cost. Thus I started digging deeper.

Then I hit a brick wall.

It is incredibly difficult to gather _useful_ information about JS.
The language reference itself is wrong (eg the Array.sort() supposed to be stable is in fact not). Info about what happen behind the scene (why this loop is so slow ?) is even more elusive.
Browser incompatibilities are the most evil I've ever seen (and I write apps in C/C++ that have to run on Windows/Netware/Various unix/embedded devices, so I know about plateform incompatibilities).
Info about libraries and environement are hard to gather (eg the exhaustive list of objects you can access in _a_ browser). Not mentionning the total lack of documented and optimized libraries (I'm sorry but I don't believe you if you say you never copy&paste portion of JS code).
Finally, there is just nowhere you can find a comprehensive list of JS design patterns, a necessity to quickly use a language professionally.

In a more general way, googling for JS info usually bring you useless monkey-written code and tutorials about add banners ...

9 Posted by Simon Proctor on 29 November 2005 | Permalink

I have to agree with you on this one. I'm a server side coder by trade who also loves the client side of things and over the last few years I've come to like Javascript again (in no small part due to quirksmode). This puts me in the minority in my team though, the client side coders seem to think the stuff they learnt 5 or 6 years ago is still good and the server side guys just ignore the issue.

I'm sure all of use working together will be able to get something done.

10 Posted by Nick Fitzsimons on 29 November 2005 | Permalink

Excellent analysis, Peter. On the application development books front, you might want to look at Steve McConnell's "Code Complete" (second edition): it covers a multitude of good practices for "big" application development.

I've always felt my position to be anomalous, being a long-term applications developer (assembly language, Forth, Delphi, Java, C#, many others) who actually likes doing client-side web stuff. A number of big intranet projects I've done over the past few years allowed me a mix of server-side and client-side coding (why would I write a server HTTP request handler if I'm not capable of writing the client that makes the requests?), but it never seemed that there were many other people out there who could cope with that mix.

Hopefully the whole "Web 1.9 Beta" thing will make my preferred way of working more commonplace. Having taught myself from scratch over the last 30 years, I just never got that hung up over which technology is more elite; I've made so many utterly idiotic mistakes in every technology I've ever used that I'm not going to scorn a language like JavaScript just because it's simpler to use - or "not a real language" as the clueless Slashdot types would say.

11 Posted by Andreas Wahlin on 29 November 2005 | Permalink

I can only speak for myself, but I have (soon) a university degree in Informatics (which could mean software engineering) and have coded assembler, C and other things.
However, I find the web and JavaScript much more fun because it's faster and involves more "art". I tend to dislike server side becasue I usually end up dealing with a database *shudders*
I'm probably one of the new amateurs, coming from the "real" programming world but now reading up on all I can on the web. I'm also writing my master thesis on Ajax, comparing it with existing Software Engineering theory. So some of us are willing to learn :)

12 Posted by Jeromy Irvine on 29 November 2005 | Permalink

You make some good points. My current job has me doing all server-side work, and all of the other programmers that I work with know little to nothing about client-side technologies like CSS or JavaScript.

That being said, I have done extensive work on both the server- and client-side, and I make an effort to ensure that all of my work is standards compliant on both ends. I was also doing "Ajax" back when the only way to do it was IE + MSXML. My biggest problem with JavaScript in general and Ajax in particular is that the payoff is rarely worth the extra effort it takes to write a decent app. Most of the server-side technologies have good development tools that make them far easier to use and debug. I have yet to find a JavaScript/Ajax dev tool that didn't cause more problems than it solved in the development process.

I find all the hype about Ajax to be laughable at best. The way that it is currently implemented will probably be rendered obsolete by future browser tech before anyone is able to come up with anything more interesting than a fancy web-mail client. The only truly impressive tool that I've seen so far is Google maps.

13 Posted by Chris Boden on 29 November 2005 | Permalink

ppk, you are saying what I've been thinking for some time.

I started as a client designer (HTML, CSS, JS), turned server side (PHP/MySQL/Perl) thinking that was "better" only in time to find out I needed both to do my best. I now take my time on both sides, and using AJAX I'm pleased with my quality of work.

Advanced PHP Programming
http://www.amazon.com/gp/product/0672325616/002-4525440-4575269?v=glance&n=283155&n=507846&s=books&v=glance
I believe this is the book you're looking for.
It IS NOT a book on PHP
It IS a book on writing quality code in any language, but it's examples are in PHP. It's first few chapters are about syntax, styling, consistancy, code structure, best practices, etc. Very nice book.

14 Posted by Mat Findlay on 29 November 2005 | Permalink

I don't think the lack of knowledge sharing between client and server side coders can really be referred to as "New Amateurism" since it's not new. It's just a variant of something that has been around for decades. For as long as I can remember, there has always been a rift between back end and front end developers. Even in university, I saw team members working on assignments referring to front end work as "Not real work" even though the interface sometimes ended up being the larger part of the project.

I'd say it's just a facet of the mentality many people have in our industry. A little bit of "knowledge domain patriotism," maybe. What I know is superior, and all else is beneath me. I've never understood it, because I always assumed the whole goal to this game was to try and learn as much as you can about as many things as possible.

If anything, I have found that in my experience, client side work is more difficult. There's a lot _less_ room for error, and the obstacles to overcome for working code are far greater.

15 Posted by Alan Bram on 29 November 2005 | Permalink

I think you're right: this is a problem, for exacly the reasons you cite.

I am a "serious" programmer who eschewed JavaScript for many years. Probably the biggest reason was the sloppiness, or lack of rigor, with which it seemed to have been designed and defined. And this was not on some high moral ground; it's just that trying to use it drove me crazy: I couldn't get stuff to work if I couldn't hold a concise mental model in my head.

Then a friend recommended Douglas Crockford's JavaScript pages:

http://crockford.com/javascript

especially the first article listed. It was from reading those articles that I not only began to understand some of the fundamental ideas underlying the language, but also discovered that it has some quite advanced language features (e.g., closures).

As Crockford says, there's a lot of bad documentation out there. You have to wade through a lot of junk to find the good stuff. But if you do, it's worth it.

16 Posted by Greg Reimer on 29 November 2005 | Permalink

Are there such things as language-neutral application design principles, and can they be applied to client-side JavaScript? I posted this question to the Joel on Software forums. There are a couple interesting responses so far.

http://discuss.joelonsoftware.com/default.asp?design.4.259168

17 Posted by Philip Hazelden on 29 November 2005 | Permalink

I'll admit it: I look down on Javascript. But don't worry - I look down on C, PHP and Java even more. There isn't a single language that I don't look down on, but Javascript is one of the better (most powerful at the language-level) ones.

The reason people don't think it's a real language is that it's only a standard. Perl, Ruby and PHP are implementations. Scheme, C and Java are standards, but they have implementations. There aren't any (well-known?) Javascript implementations that aren't tied to something else. You can't just use Javascript, you have to do complex stuff with the DOM, set up stuff on the server to parse XMLHttpRequests, etc. Which makes it appalling for the kinds of things that server-side programmers are usually doing, because Javascript basically exists in a vacuum. Fix that, and the stigma will go away.

18 Posted by Bruce Kroeze on 29 November 2005 | Permalink

I used to look down on Javascript, based on terrible experiences in Netscape 2.0 days. However, the modern implementations in Firefox and to a much lesser extent, IE, have made me change my mind.

I am a 20 year programming veteran, largely heavy network programming and "server-side" things, and yet I found myself having fun with Javascript in a program I wrote for a client at work just the other week. It is an AJAX app, which assembles slides into Powerpoint applications. Very interesting, and not really something I could have pulled off in a couple weeks without the aid of the very good Javascript libraries such as Prototype.

Javascript still has warts, and working with IE always remains a pain, but the fact is that it is a fun language with many interesting features. I had a ball on that project, and I am looking forward to using it much more in the future.

Things to improve, from a veteran's perspective:
- packaging/name-spaces. This is the worst "wart", IMHO. Javascript needs a widely supported system for this. I should not pollute the namespace unless I want to do so.

- standalone "reference" implementations. Rhino is close, but not all there yet.

- A core set of "best-practices", well-documented and supported.

19 Posted by Cory Burt on 30 November 2005 | Permalink

Thanks for your insight. You make a good point. I have been doing "serious" Perl for about 7 years and "serious" PHP for about 4, but I am quite intrigued by the power of Javascript. It is amazing what can be done with a stodgy old brower. I am surprised at the idea that javascript is considered to be, somehow, "light-weight." I find it rather daunting. My intuition seems almost useless in the pursuit of competence; I have a hard time seeing how to solve anything in an efficient way. I certainly claim no expertise in anything here, but the general notion of "best practices" never seems to be mentioned in the context of javascript. I hope experienced codesmiths like yourself can continue to remedy that situation.

I believe that AJAX will help. The magic of buzzword power cannot be underestimated. When the books start hitting the selves, the decision-makers (i.e. marketeers, lawyers, and HR wonks) who really run things will take it seriously. Then, we will ALL learn it.

20 Posted by grumpY! on 30 November 2005 | Permalink

>> I am surprised at the idea that javascript is considered to be, somehow, "light-weight.

thats because it isn't

fire up any resource measurement tool (top etc) while running sites like google maps and you will realize that "ajax" is anything but lightweight.

this is another major issue with this platform - it is a resource hog.

21 Posted by Andy Johnston on 30 November 2005 | Permalink

Great points I reckon. It seems such a shame to me that the real momentum javascript was generating in the mid 90's (yeah there were lots of DHTML tricks) got slowly degraded by really wack implementation in the browsers of the time. I read the language specs for js and thought it would be really great to be able to actually manipulate the dom like that! I had similar feelings about the posibilites of css at the time.

It seems funny that it has taken till 2004-05 to finally become a force to reckon with. Hopefully this will encourage better progression in the language. The same types of things have been happening in the flash development realm for the last few years, but flash had a bit of a head start on javascript due to such a large adoption rate.

For some more application development reference I suggest you have a look at all of colin moock's books, they offer very very good insights into the niceness of object oriented programming and basic patterns. As actionscript is a close relative to js you may find them useful.

I know that the knowledge I learned crossing over to flash and through as to as1 to as2 has benefitted me coming back to reexamine javascript.

22 Posted by Chris Wesseling on 30 November 2005 | Permalink

@Philip Hazelden
SpiderMonkey is an implementation of JavaScript.

@ppk
JSUnit can help managing a herd of obnoxious browsers on several OSes, whilst you can bash away by hand. Coding, testing, refactoring. It enables you to refactor aggressively. And that, IMHO, bring s back the element of fun in hacking JS.

23 Posted by Leonardo Soto M. on 30 November 2005 | Permalink

Javascript can be powerful at language-level, but it's very anoying in general to a programmer already exposed to better languages.

You have no strong namespace support in JS. JSAN is a step forward, but as too many things in JS, is tricky.

OOP in JS is extremely difficult. Hey, you can't even always rely on 'this' keyword without doing some extra work.

Debugging is hard, typically requires creating a iframe, frame or popup to have something to write into and look later. You have some debuggers (venkman is pretty good) but obviously they are browser-specific.

IMHO, programming languages are suposed to provide the developer a solid base to concentrate as much as posible on the problem to solve. But JS also presents sooo many problems on his own.

Sites like this helping you to know all the obscure javascript 'features' (BTW, a big thanks!) just demostrates how anoying is the language and his implementations.

Being said all that, it doesn't matter how much JS sucks. It is just what is used in browsers today and we, the web applications developers, must learn it and stop looking down.

24 Posted by James Petersen on 30 November 2005 | Permalink

So maybe a good way to bridge the gap is to promote JavaScript as a server-side scripting language. The folks at JotSpot seem to be working on it (http://developer.jot.com/WikiHome/ServersideJavascriptIntro). The changes to the spec for JavaScript that Brendon Eich is proposing may make JS more appealing for this domain.

25 Posted by Matthew Haralovich on 30 November 2005 | Permalink

You know what they say, "Programming is easy, enginering is hard." There's a big difference between just solving programming problems, and enginering whole applications.

If your interested in object oriented programming consider Design Patterns (the book). Lots of application design books mention design patterns. This book is their source. You may not find anything in Design Patterns directly useful, but you'll at least see what good object oriented designs look like.

The best way to learn application design is through experience. Just do what you have to, while keeping an eye out for better ways to organize your logic.

http://www.amazon.com/gp/product/0201633612/102-5856571-8371349?v=glance&n=283155"

26 Posted by William J. Edney on 30 November 2005 | Permalink

I would like to submit that one can write good or bad code in any language. JavaScript is no exception. My company has written a complete application framework (called TIBET) that implements many of the features necessary to write full-blown, client-side applications in a browser in JavaScript. We have found that a properly layered, well factored architecture (and that means the discipline to do design before coding) can ameliorate many of the problems encountered in 'cross-browser' development.
Another thing that we learned in the 6.5 years (and approx. 40K man hours) since we started building TIBET was that most of the current 'scripters' out there do not have the discipline (or time) required to build code such as this. Therefore, trying to build complex applications using a pure JavaScript approach will fail. We have chosen, therefore, to implement an XML authoring model on top of our application frameworks so that 'less serious' programmers can leverage the existing XML tools that are available to assist in their application construction.

JavaScript is a terrible end point but not a bad starting point. Through a disciplined design and coding approach, amazing things can be achieved.

Cheers,

- Bill

27 Posted by Mike Purvis on 30 November 2005 | Permalink

I'd like to submit that any server-side programmer who doesn't take Javascript seriously should read up on Douglas Crockford's site: http://www.crockford.com/javascript/survey.html

The Javascript object/array model is vastly more sophisticated than the PHP one, but it took me a *long* time to actually find some documentation to explain that.

That said, my favoured approach is still to develop everything to work on the server alone, and then hook on Prototype Ajax fetches Adactio/Elsewhere style. Of course, in the case of something like Gmail or Windows Live, we're talking about more sophisticated functionality than that.

28 Posted by rps on 1 December 2005 | Permalink

For someone trying to bridge the gap from small scripts to larger programs, I would recommend the lecture notes from MIT's software engineering lab class:
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-170Laboratory-in-Software-EngineeringFall2001/LectureNotes/index.htm , and Code Complete from Microsoft Press (which I recommend grudgingly because I'm a Linux using MS-hater, but it's a good book).

The MIT notes are written for Java, and Code Complete should be comprehensible if you know a C-like language. Truly language neutral books on this subject are probably impossible to write, because you need to have examples (but all C-descended languages look more or less the same anyway).

29 Posted by grumpY! on 1 December 2005 | Permalink

@william edney -

yes your statement is valid, bad code can be written in any tool, but this should not be interperted to say all languages are inherently equal (even if turing complete). i offer javascript and php in particular as languages that went out the door long before they had a decent feature set or design review. scoping anyone?

once again, we must separate the domain of web application development from being locked into a single tool. in some domains the language is tied very closely to the underlying platform (sql and rdbms) but this is not the case with javascript - many languages have DOM bindings, its just that only one actually has runtime support in the browser.

this is a flaw that was addressed years ago on the server side: users don't care if i am running mod_lisp or mod_ruby or php5. nor should they care if i transmit client code in that was authored in scheme or java. as long as it compiles to a bytecode supported by the browser client runtime (which enforces security etc), it should run. transmitting bytecode instead of source would also reduce page sizes....many huge ajax apps are transmitting thousands of lines of code, which is already really pushing the sanity point given javascript's nonexistant support for programming-in-the-large.

parrot or a free jvm could provide this support.

30 Posted by Taka on 1 December 2005 | Permalink

Interestingly enough, no one seems to notice that the javascript differences between browsers are mainly caused by differences in the implementation of the DOM.

Javascript itself offers only a limited numbers of objects. In web development, either you create your own objects or you use the objects that are being offered by the browser. The latter are usually DOM objects.

The differences in the implementation of javascript itself between browsers are minimal, they even suffer from exactly the same bugs, for example the rounding bug.

Programming AJAX is a new branch, and some people will specialize in it. It requires knowledge of programming in general: in AJAX many data have to be stored in non-DOM objects, for which usually classes have to be programmed. Another part involves interaction with the DOM-objects (also requires skill with CSS), and a third part is being done on the server.

Javascript itself isn't very different from a number of other languages. It's the DOM-objects that is probably the hardest to get a grip on, because often they are poorly documented and because compatibility between browsers is missing.

31 Posted by Tino Zijdel on 1 December 2005 | Permalink

I agree with Taka (to a point): the core javascript features are pretty much equally implemented in all browsers (IE has some bugs though). Some browsers are lacking some features of the DOM (eg IE is lacking the DOM event model), but I normally don't encounter any serious problems with the javascript implementations within browsers.

The days that you had to cope with different document object models (d.all, d.layers) are far behind us already. My feeling is that the people that think of javascript as 'garbage' here are just showing their own ignorance.

I have however never heard of any rounding bugs in javascript; floating point calculations are never precise, not in any language...

32 Posted by David on 1 December 2005 | Permalink

PPK, I have to take issue with your "anti-library" stance. Perhaps this is because most of my work has been programming in what you term "server" environments--C, C++, perl, etc. These all have libraries, and, frankly, that's a good thing. I'd hate to have to re-write stdio.h every time I need to write a C/C++ program that needs to do output, or DBD.pm whenever I need a perl program that can communicate with a database. I don't know how those libraries work, and, frankly, I don't need to.

And, of course, every programmer I've ever talked to has developed their own personal "toolkit" for the languages they're working in. I'm sure you do, too--or do you re-write cookie handling code for each site you create that needs to use cookies? How would you get anything useful done?

I've got a javascript toolkit that I'm constantly adding stuff to. So far, it includes a browser-independent method of getting a specific object by ID, code needed for xmlHttpRequest, etc. And I've not been doing this that long.

33 Posted by Matt West on 2 December 2005 | Permalink

"Who will create the Ajax applications?". I think it will be the "serious" programmers who do the first Ajax apps; they will probably be functional but look nasty. I know Ajax is a techy subject, but its a big change to how webapps work; a big change to what webapps are. We will need good task analysis and good user interface design for it to work well.

I must admit I considered registering "ihatejavascript.com" a few years ago. Now that the DOM is well established and browser-sniffing is frowned upon, I am starting to enjoy it. I am a Java web developer and use web standards + DOM but did databases before that. For me, there are two problems with JavaScript.

The first is a lack of decent debugging support. My most productive JavaScript way of working is just do a little bit at a time, using alerts to show variable values, and using the JavaScript console in Firefox to see any errors/warnings. My top tip is to throw an Error object rather than just alert() when a serious programmer error has happened. jsTrace looks good: http://domscripting.webstandards.org/?p=28

The second problem for me is its weak typed variables, and its old fashioned scoping. I really enjoy Java with its help strong types and block scope rules.

Matt.

34 Posted by l.m.orchard on 2 December 2005 | Permalink

For some of you looking for debuggers and object references and such: There's nothing like having a logging system and an interactive shell in which to prove out ideas and interrogate objects while looking at a live DOM.

MochiKit [1] has a nice logging system loosely inspired by Log4J. There are others. window.alert() sucks for debugging.

You can find a Javascript Shell [2] bookmarklet for Firefox over at squarefree.com. You could probably wrangle this thing into a debug-include for IE. MochiKit also offers an interpreter [3] as a demo page.

Introducing things like these have really helped raise my JS game in browsers and made it feel almost more like developing with Python.

[1]: http://www.mochikit.com/doc/html/MochiKit/Logging.html
[2]: http://www.squarefree.com/shell/
[3]: http://mochikit.com/examples/interpreter/

35 Posted by brett on 3 December 2005 | Permalink

A schooled programmer shouldn't have trouble with JavaScript or HTML/CSS. These are all standards based on well known computer science principles.

Since JavaScript still often has to be tied closely to the layout, it seems the realm of the designer to me.

36 Posted by Alper on 3 December 2005 | Permalink

Libraries are not substitutes for knowledge. They are abstractions of disparate and complicated concepts and they promote code reuse. Both of these are very much necessary if you consider the quagmire that is current web development practice.
Indeed teams will usually write their own if they cannot find any suitable ones but it pooling these efforts makes sense.

Studying browser incompatibilities usually is inevitable but should really not be necessary. I think that is one of the biggest causes of disdain for Javascript: the creakiness of the environments it is forced to run in. Programmers cherish sane environments to work in.

An alternate library approach which is winning converts rapidly is writing the application in server side code using Java/C# and then passing it through to a rendering engine to display it on the client in whatever form necessary: HTML/Javascript, Flash or Java/Swing or whatever you want.
This puts a heavy burden on the library developers but mitigates the problem completely.

37 Posted by Michele Costabile on 6 December 2005 | Permalink

I read your criticism of libraries and somewhat agree with that. You get often too much weight for the functionality you get.
But if you think of applications on a traditional platform, they are made working with objects. Non always building objects, but reusing objects.
Your typical VB programmer grabs a toolbar, some buttons, a tree control, a data grid and creates an application.
What is the Ajax programmer to do?
The DOM is too low level: a calendar might be a table or some divs stacked in some way or even some lines in a pre tag.
At application level you might want to say something like "calendar: select today".
Javascript libraries try to match the impedance between a useless world of divs with styles and application meaningful objects.
But then, you get the full weight of a calendar control, a tree view, a data grid in the slowest language of the world, on a platform that already has much better widgets in the native toolkit. That makes me wonder why we do not make ad hoc clients and web services.
Maybe a way to solve this is to treat a calendar as just an other div and have some service on the server that can give you the innerHtml of that when things need to be adjusted.
Any ideas on the impedance mismatch problem?

38 Posted by Suketu Naik on 8 December 2005 | Permalink

I'm working in a Software firm where .Net and Java are used as server side languages whereas JavaScript is used as client side scripting for validations and other purpose. We don't have any problem either with server side or client side coding. It all depends on system requirement and client's expectations. We're using AJAX, previously called as remote scripting, for quite long time and enhanced the way we're using it today.

So the conclusion is that using client or server side scripting has no problems if the programmer is aware of any basic programming language.
In our organisation, we've different libraries for diferent objects for e.g. Calendar object which is there on many client's websites and working fine till today.

39 Posted by Olaoluwa Okelola on 11 December 2005 | Permalink

I am a student who has had experience writing cide in C++, C#, Java, PHP, ASP.NET, JSP, JavaScript, HTML, CSS.

I don't look down on either client-side or server-side code. The major advantages server-side code has over client-side code is its debugging environment, strongly typed (C#, Java, C++), error checking and consistent working/deployment environment. I haven't actually decided whether I prefer server-side code or client side code but I'll say it has way more advantages and as a CS major in school, I have no choice but to write way more server side code (strongly-typed code, not everything has been for the web).

The thing about writing JavaScript is that you can do pretty little with JavaScript alone and to effectively use JavaScript, you have to know a host of other technologies such as HTML, CSS, DOM, and something waiting on the server like a web service when using AJAX.

That's where the problem sets in. With the previous advantages server-side code gives you coupled with the consistency of knowing what you are dealing with, it's "easier" to write serverside code.

However, companies like Google and Microsoft which have invested majorly in AJAX have the people who are well versed to write code that can deal with all the problems that client side code gives you.

40 Posted by David Feuer on 12 December 2005 | Permalink

Check out http://cs.brown.edu/courses/cs173/2005/Textbook/index.shtml
(note: the beginning is at the bottom). This is about programming language design, but in discussing features available in different languages, Dr. Krishnamurthi presents detailed programming examples to demonstrate the utility of these features. The text is written primarily from the perspective of functional programming, which you may never have encountered. His chapters on programming for the web provide a good, clear view of some of the basic challenges of web programming and some good ways to meet those challenges.

41 Posted by David Feuer on 12 December 2005 | Permalink

I forgot to mention that the page I suggested has some links at the top to articles that you may find valuable.

42 Posted by Johan Hertz on 16 December 2005 | Permalink

There are a lot of things in your article that rings true to me. But I think there is one thing that you disregard when it comes to “server side programmers”. I think the main two reason why server side programmers or serious programmers have stayed away from JavaScript is the fact that A) If you write complicated programs you need complicated libraries to help you do the job. B) If you write big applications it is hard enough to make it work without having to worry about how different browsers might react to every single line of your code.

If think this might be about to change or at least be redefined. To be honest I think that it will take a long time before really serious programming tasks will be moved to the client, for a number of reason’s (for two see above). But when users starts to expect more responsive applications the server will have to unload work to be able to make those responses fast enough.

43 Posted by Kurt on 17 December 2005 | Permalink

A good programmer does not limit one's self to any one language! Also a good programmer can write programs in a language they are previously unfamiliar with, they already know structure etc., all they need to learn is the syntax for that language. I would like to think that a good programmer could and would use the best tool for the job.
In my opinion someone cannot be a complete Web Developer using only Server Side programming or only Client Side programming. Both have limitations and features that the other does not have.
If Server Side programmers poo poo Java Script (Client Side Programming) it is not a technology issue but a people issue. So many people resist change, or perhaps they feel that having to learn yet another language negates the time and effort learning the language(s) they already know?
Having more tools available for creating solutions facilitates better solutions.
By the way I do not consider myself a good programmer, although I may occasionally write a good program.

44 Posted by Alex at XQST on 18 December 2005 | Permalink

Javascript may be client-side and it may lack some of the powerful features of Java, C++ or C#, however, it still occupies a central place in web development, and will continue to do so for some time to come. So far, you can not do HTML of any depth or sophistication without Javascript. In my opinion, developers who look down on Javascript are not only being unrealistic, they are also limiting their own possibilities.

45 Posted by Spyros Economopoulos on 21 December 2005 | Permalink

"modern web development techniques and theory" - Do you mean studying web standards and books like "designing with web standards" etc. or there is something more? Please elaborate since I am a former arrogant "serious developer" who needs to catch up :-)

Regarding your question, the best book I have read about design is "Refactoring" of Martin Fowler.

46 Posted by Strangeweather on 29 December 2005 | Permalink

I suppose I'm a "server side" developer from your standpoint, though my specialty is actually in developing reusable framework and abstractions, whether they are used by server applications, inside desktop clients, or in other arenas.

I've done some front-end development in various forms, but it's only been within the past year or so that I've spent any real time learning web development. I quickly discovered that it's vital to learn what's really going on under the hood in HTML, JavaScript, and CSS, and how the various browsers handle things.

Lately, I've been focusing on client-side application development, and I've been surprisingly impressed with JavaScript and the other web environment tools. Contra one of your main points, I believe strongly in libraries. If there's three different ways to retrieve an element given its id, someone should write a bulletproof method that does that, and that's the last time it should ever need to be done.

If no one has written a canonical library, then I suppose all that's left to be done is to research all these things, build them, and put them in files like "utilities.js" myself, so that I can easily incorporate them into my applications.

In that respect, your site is really useful.

47 Posted by jmn on 29 December 2005 | Permalink

I do complicated web apps, so I end up doing both "server-side" and "client-side" code, but I try to keep client-side Javascript to a minimum.

Why? Not because I don't like Javascript or look down on it -- quite the contrary. I really like Javascript.

It's because of the browser problems. As your Javascript becomes more complex you have to spend hours tearing your hair out dealing with incompatible implementations. Finally you get something that does 50% of what you wanted, and it works everywhere -- EXCEPT Internet Explorer. You spend a few more hours digging into the total piece of garbage that is WinIE and finally decide that if it's even possible to make it work in IE and still have it work elsewhere, it's not worth the effort. So you give up and scale your design way, way back.

I'm at the point where I care so little about WinIE that I just strive to "degrade gracefully" in it. Trying to do anything useful that also works for decent browsers is possible, but not worth the time and effort. But, since a lot of people still insist on using it, that means you might as well not write anything serious in Javascript at all.

The current state of Javascript is not an environment a serious programmer wants to deal with.

48 Posted by Justin Falcon on 1 January 2006 | Permalink

Hi,
This is my first visit to your site and I thin kit is really good, and offers a lot of good info on Javascript. I do have one gripe for you though. In your JavaScript libraries - substitutes for knowledge? I feel that libraries are excellent time savers for many programmers. I have an example for you. I am in the an Air Force Weather Forecaster. We have to forecast takeoff conditions for aircraft. One of the items we have to forecast is called induction icing run time. It is the amount of time in minuts an engine can run before it gets ice fod. We have a table we used to compute it ( their is no mathmatical formula just the table) So I wrote a library that computed the run time. I was then able to use that library in at least 10 diffrent applications from web pages to database desktop apps. The library saved hours of programming and man hours.