Slashdot Mirror
Joel On Microsoft's API Mistakes
AceMarkE writes "Joel Spolsky of Joel on Software has posted an article entitled "How Microsoft Lost the API War". He covers why the Win32 API is important to Microsoft, what they've done to keep it working, why Microsoft's switch to the .Net platform is both a good and bad idea, and why he feels the browser will be the real future of application development. Definitely worth a read no matter what your opinion of Microsoft is."
A closed set of poorly documented APIS
Say what you like about MS's evil ethics but *do not* mock their API docs. They're very good.
It's not exactly sockets, but you can do an awful lot with the XmlHttpRequest object. Microsoft did it first, I think, and Mozilla has a complete clone. Check out the XulPlanet documentation, the Mozilla documentation, the Microsoft documentation or this tutorial called Using the XML HTTP Request Object
The XmlHttpRequest object is poorly named. Really you're just making an HTTP request, and if the response happens to be XML, there are convenience functions for getting a fully-parsed DOM view of the document. If the response is anything else (plain text, JavaScript, Perl, HTML, etc.) you can do what you want with it, including calling eval() on it from a JavaScript script. You can do synchronous (blocking) or asynchronous (non-blocking) calls to your web server, and either be notified of completion by a callback for non-blocking calls, or just treat it like a function call for blocking calls. It's quite handy, and we have a project at work that makes extensive use of this technique. We have a "thick" or "rich" client application that runs in the web browser. Our client looks like a native application--it has table widgets, with clickable headers that resort the columns, it has a tree widget that looks like the tree in Windows Explorer, it supports drag-and-drop and custom context-menus, and if you open our application in a chrome-free browser window, it's almost possible to forget it's not native (the speed is usually what gives it away, the GUI is a little sluggish...). It works equally well in Mozilla, Firefox, IE 5.5+, and Netscape 7.1+ on Windows 9x, 2000, XP, and many flavours of GNU/Linux (tested on Gentoo and Redhat 7.3, and 8.0 using GNOME, KDE, and some kind of *Box wm). Well, "equally well" is a bit of a stretch. IE's implementation of the DOM is dog slow, so some things run a bit faster in the Gecko-based browsers, but all functionality is equally available in all the configurations listed above. We've managed to stay standards-compliant for the most part, and have abstracted away the quirks in IE, so as soon as Konqueror, Opera and $YOUR_FAVOURITE_BROWSER fully support JavaScript 1.5, DOM 2.0, and CSS 2.0, our app will work in your browser, too. (I don't know which parts these browsers are missing, so maybe our app already works there.)
The only remaining hurdle is to convince management that it should be open-sourced so that other people can use it, too. If you can't wait, you might want to check out SourceForge. There are some other widget kits available for building browser-based apps. We chose not to go with them because, at the time, they were too Alpha-ish, and we disagreed with some design decisions. Our decision not to use those projects has not been revisited for a while though, now that we are rather comitted to our in-house implementation, so things may have improved significantly since the last time I had a look.
Also, if you're going to actually build any significant JavaScript apps (we have more than 40k loc that turns out to be more than 1 meg of JavaScript to download), I highly recommend JSDoc. The main developer, Gabriel, has been very responsive and helpful, and the documentation that his scripts produce is excellent. Especially considering he builds JSDoc in his spare time, I can't compliment his work enough. Now that our codebase is too large for me to keep it all in my head, the API has saved a lot of my time.
Ian