except in one place: javascript running on browsers in ajax applications. and since that’s the direction almost all software development is moving, that’s a big deal.

a lot of today’s ajax applications have a meg or more of client side code. this time, it’s not the ram or cpu cycles that are scarce: it’s the download bandwidth and the compile time. either way, you really have to squeeze to get complex ajax apps to perform well.

history, though, is repeating itself. bandwidth is getting cheaper. people are figuring out how to precompile javascript.

the developers who put a lot of effort into optimizing things and making them tight and fast will wake up to discover that effort was, more or less, wasted, or, at the very least, you could say that it “conferred no long term competitive advantage,” if you’re the kind of person who talks like an economist.

the developers who ignored performance and blasted ahead adding cool features to their applications will, in the long run, have better applications.

the c programming language was invented with the explicit goal of making it easy to port applications from one instruction set to another. and it did a fine job, but wasn’t really 100% portable, so we got java, which was even more portable than c. mmmhmm.

right now the big hole in the portability story is — tada! — client-side javascript, and especially the dom in web browsers. writing applications that work in all different browsers is a friggin’ nightmare. there is simply no alternative but to test exhaustively on firefox, ie6, ie7, safari, and opera, and guess what? i don’t have time to test on opera. sucks to be opera. startup web browsers don’t stand a chance.

what’s going to happen? well, you can try begging microsoft and firefox to be more compatible. good luck with that. you can follow the p-code/java model and build a little sandbox on top of the underlying system. but sandboxes are penalty boxes; they’re slow and they suck, which is why java applets are dead, dead, dead. to build a sandbox you pretty much doom yourself to running at 1/10th the speed of the underlying platform, and you doom yourself to never supporting any of the cool features that show up on one of the platforms but not the others. (i’m still waiting for someone show me a java applet for phones that can access any the phone’s features, like the camera, the contacts list, the sms messages, or the gps receiver.)

sandboxes didn’t work then and they’re not working now.

what’s going to happen? the winners are going to do what worked at bell labs in 1978: build a programming language, like c, that’s portable and efficient. it should compile down to “native” code (native code being javascript and doms) with different backends for different target platforms, where the compile writers obsess about performance so you don’t have to. it’ll have all the same performance as native javascript with full access to the dom in a consistent fashion, and it’ll compile down to ie native and firefox native portably and automatically. and, yes, it’ll go into your css and muck around with it in some frightening but provably-correct way so you never have to think about css incompatibilities ever again. ever. oh joyous day that will be.

the ibm 360 mainframe computer system used a user interface called cics, which you can still see at the airport if you lean over the checkin counter. there’s an 80 character by 24 character green screen, character mode only, of course. the mainframe sends down a form to the “client” (the client being a 3270 smart terminal). the terminal is smart; it knows how to present the form to you and let you input data into the form without talking to the mainframe at all. this was one reason mainframes were so much more powerful than unix: the cpu didn’t have to handle your line editing; it was offloaded to a smart terminal. (if you couldn’t afford smart terminals for everyone, you bought a system/1 minicomputer to sit between the dumb terminals and the mainframe and handle the form editing for you).

anyhoo, after you filled out your form, you pressed send, and all your answers were sent back to the server to process. then it sent you another form. and on and on.

awful. how do you make a word processor in that kind of environment? (you really can’t. there never was a decent word processor for mainframes).

that was the first stage. it corresponds precisely to the html phase of the internet. html is cics with fonts.

in the second stage, everybody bought pcs for their desks, and suddenly, programmers could poke text anywhere on the screen wily-nily, anywhere they wanted, any time they wanted, and you could actually read every keystroke from the users as they typed, so you could make a nice fast application that didn’t have to wait for you to hit send before the cpu could get involved. so, for example, you could make a word processor that automatically wrapped, moving a word down to the next line when the current line filled up. right away. oh my god. you can do that?