The more I hear about the ongoing efforts to revise the leading Web standards, the less convinced I am that we're approaching Web-based applications the right way.
But while large-scale application development might sound good to Adobe, guaranteed it wouldn't have worked for everyone. The history of traditional systems programming languages is evidence enough of that.
For every methodical, disciplined Java programmer there's a Perl hacker who would much rather play everything by ear. Strong typing, packages, and namespaces may make it a lot easier to maintain large applications, but they're virtually useless to any Web coder who just wants to bash out a little bit of UI glitz.
In fact, the very concept of an all-purpose programming language that's designed by committee is questionable. Once before, a bunch of very smart people got together to write the specification for what was supposed to be the ultimate programming language. It was secure, robust, and so standardized that nothing was left to interpretation. Remember Ada? No? That's probably because, once the specifications became available, the language was so strict and inflexible that most folks preferred to code in C.
So if nobody ever managed to come up with the ultimate, perfect language for systems programming, what makes us think we can do it for the Web? If anything, the more we talk about building large-scale Web applications, the more we should recognize that a single style of programming will never suit every job.
I'm a big fan of the Model-View-Controller design pattern. It doesn't work well for everything, but it can often provide invaluable guidance in the application design process. In a nutshell, one of its core tenets is to separate the View -- the presentation of data -- from the data itself (the Model) and the underlying logic that manipulates it (the Controller).
So here's an idea: Your Web browser window is a View. Maybe it's high time we stopped trying to force it to be a Controller, too.