The whole rich/dynamic interface pendulum swings widely and often. Rich is where commercial vendors want us to go, because rich front ends require vendor-specific run-time software, dev tools matched to the run time, books and classes, support contracts, consulting, coffee mugs, and so forth. Not to mention the specialized developer skills that might prove useless in their next job.
With rare exceptions, a rich interface is static. We don’t have static work habits, static job descriptions, static database layouts, or static connections between servers and services. If everything we do is dynamic, what room is there for static interfaces or static client-side programming languages?
The swing toward static richness isn’t just a Microsoft thing. Apple’s Xcode, as fine a development environment as it is, also squeezes developers into rich, static interfaces. In a way, Apple’s shortcoming is more egregious because Unix developers take for granted that applications will work remotely with minimal client-side requirements. Xcode can’t (or won’t) manage that, despite the uniformity of the server software that ships with every Mac. At least WebObjects, Apple’s flexible Web application development and deployment suite, provides a true Web app environment, albeit at a cost.
Visual Studio 2005 doesn’t send Web developers to external tools, and Microsoft has taken advantage of its new Web-friendly toolset. Internet Explorer is a prerequisite for many of Microsoft’s recent and upcoming releases. Visual Studio Team System, SQL Server Reporting Services, Windows Server 2003 management tools, and SharePoint use IE as their presentation engine. SharePoint makes heavy use of .Net Web Parts technology. Web Parts are very cool — dockable, resizable windows inside a browser look great. But their use is not mandatory. You still have a browser back there. Microsoft’s use of XML and Web services to feed data to Web Parts takes some of the proprietary sting out of this .Net rich front-end approach.
My greatest source of delight is the restoration of Visual InterDev, Visual Studio 6’s sweet and brutally murdered Web application IDE, to Visual Studio 2005. Of course, the name has changed to save face, and Microsoft didn’t give in to all of the developers’ demands. If Microsoft is holding out on Web dev tools, it should fork them over. IIS has always been a crown jewel of Windows, right up there with SQL Server and Terminal Services. IIS is Microsoft’s app server, and it’s useless without tools that create dynamic, scriptable interfaces.
I wrote a fat, marriage-straining book, Windows 2000 Web Application Development, that clarified my philosophy: Browser technology — DHTML, CSS (Cascading Style Sheets), DOM, and JavaScript — has no equal in the rich world for flexibility, interoperability, and rapid development. The only thing missing, and it irks me to no end, is a fast browser. Mozilla’s got some lightweight browser work under way. Maybe Apple will put the spring back in Safari’s step, which has gotten slower and fatter of late. But I am encouraged and amused to find that Microsoft’s own application developers are refusing to let Internet Explorer and Visual InterDev die.
Tom Yager is technical director of the InfoWorld Test Center.
Brak komentarzy:
Prześlij komentarz