Now, knowing what we want, we can think about how to achieve all of this, and now we can come back to the browser. We never want to hear our support staff tell a user "we can't reproduce that problem." If we have to let a developer go, we want to know that he can't lock up his code on the way out, and that anyone of comparable skill can take over and be up to speed in a couple of days. Code has to be ultimately reusable, and we need the capability to easily reach out to legacy back-ends. We need to adapt to specifications that are altered while the project is underway. We want applications that can be QA'd in situ at the operational level, patched remotely, and updated automatically. We want a cross-platform, cross-architecture development platform that can take an app from behavior-accurate prototype to full functionality in stages and with minimal skill.
It's a matter of adjusting our priorities and perspective.įorget about trying to make projects fit browsers and focus on higher objectives. That is not too much to ask it's all within reach, right now. All that keeps your browser from being the perfect client app environment is speed, stability, strict adherence to standards, and offline capabilities. Browser-based apps don't require specialized development tools, or any tools at all. There's the best dynamic, object-oriented, loosely typed programming language, bar none (JavaScript), transparently bound to an idiot simple yet extensible presentation layer (DHTML, CSS, XML, DOM, SVG.). Inside every browser is the core of the ideal client-side application environment, incorporating everything that I'd estimate half of commercial applications need.