I'm writing a CSS book
JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH
QuirksMode
PPK contact

Amsterdam JavaScript meeting

Last Sunday the Amsterdam JavaScript meeting was a moderate success. Among others, Bobby van der Sluis, Anne van Kesteren and Faruk Ateş attended, and we had some interesting discussions.

See the following blog entries for a description of the meeting:

A few hurried points that haven't been mentioned yet but merit attention.

Empty text nodes are useless in JavaScript. They don't serve any purpose (apart from enabling white-space: pre, but that's CSS, not JavaScript) and they complicate matters for beginning scripters, since they make the DOM tree much more complex than people expect. We should get rid of them. How? Dunno.

Gerbert Kaandorp, the man behind Backbase, made us change perspective by speaking at length on problems application programmers encounter when they use JavaScript. He gave some performance optimization tips, which I hope he'll repeat somewhere because I can't remember them. He was adamant on the trouble browser incompatibilities cause, while most of the rest of us tended to downsize these problems, especially when compared to similar problems in CSS. Nonetheless, once your code goes beyond, say, 2000 lines, browser problems start being a real pain.

As I did in London, I presented my idea for dividing JavaScript into several areas:

  1. Core. The part of JavaScript that makes it behave like a programming language. Also called ECMAScript. This covers basic building blocks like functions, strings, for-loops etc.
  2. DOM. The part of JavaScript that allows us to access and change the document.
  3. Events. The part of JavaScript that allows us to notice user actions and read out information about them.
  4. Viewport. The least well defined area. Currently it encompasses both windows and frames and properties like offsetHeight which say something about the rendered page, and not the document structure.

Any script uses the first three areas. The fourth is optional, and not always used.

This division can be useful in JavaScript education, to give a sort of general overview for newbie scripters. More advanced scripters will have less use for this subdivision.

One point of critique in London (Dean Edwards) and Amsterdam (Bobby van der Sluis) was that Viewport is (ought to be) a part of DOM. I'm not sure if I totally agree; my Viewport doesn't say anything about document structure, but instead considers the windows the documents are loaded into, and the rendering of the documents as specified by CSS. Nonetheless this is an area that's very much open for discussion.

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?

Categories:

Comments

Comments are closed.

1 Posted by Tino Zijdel on 30 June 2005 | Permalink

I would have loved to attent, but last Sunday was my 7 year wedding anniversary. I hope to be able to make it some next time :)

2 Posted by Alex Lein on 30 June 2005 | Permalink

If I may be so bold, I'd like to suggest that Events encompass more than just "user actions". Events should also consist of application events, or custom developer-created events that get raised when the javascript does something.

Currently I'm having enormous trouble with this in IE (which is I think a limitation of their createEventObject() method) but I would like to see more custom events using the standardized createEvent("eventclass").

3 Posted by Jacob on 1 July 2005 | Permalink

My opinion is that viewport and events could both be described as being part of the DOM as they can be accessed through it. Neither of them are part of the DOM in the sense that page elements are, however, I would say that viewport is part of the DOM. A document is described by more than its internal structure, and so the viewport helps to describe the document. For example, a popup window may have just a small notification, and may be resized using viewport functions. Without resizing, the document would look quite stupid, and so IMO the viewport is an important part of the DOM.

Having said that, I agree with you that "More advanced scripters will have less use for this subdivision". In essence, it doesn't matter how you regard things like viewport and events, but as you say, dividing them up would be useful for tutorials and the like.

4 Posted by Small Paul on 4 July 2005 | Permalink

Aw, heck, I'll throw my 2 pence in. DOM = "Document Object Model'. As the viewport is independent of the document, I'd agree it should be independent.

I guess that does fall apart a bit with framesets, as you've got an HMTL document that sort of defines different viewports.

Ah well. Separate, I say. I like separation.