I’m willing to bet it’s a relevant statistic of the software industry that somewhere, at any given time, some poor schmo’s Web browser is crashing. It doesn’t matter if you use Mozilla, iCab, the latest version of IE or some other hunk of code: Sooner or later you’ll run across an errant page that brings the whole shining mess down upon itself. Browsers are still rather flaky pieces of software, perpetually sprouting features while what lies beneath remains a tottering mess.
Over the years, projects like Mozilla and Konqueror have organized the complex process of developing a modern Web browser, integrating the different teams that work on a browser’s many components. But the results are still poor. No browser has the kind of failsafe architecture that characterizes many operating systems and database software packages.
That’s a problem, because browsers and other Web-based technology are fast becoming the centerpiece of modern business applications. If the future of corporate computing is going to compute at all, a kind of Marshall Plan is necessary to make browsers truly reliable, starting now.
The End of Featuritis
It is true that Web browser development has improved from the days when Netscape and Microsoft were locked in combat, but that is mostly because development of new features has slowed to a crawl. Whereas it once seemed that features were added on a weekly basis, it has taken several years for the current crop of browsers to get behind the idea that blocking pop-up windows is generally a good thing to do. Back in the day, on the other hand, you got the feeling Netscape executives didn’t want to discuss the humongous, tangled ball of yarn they were creating when they introduced something like whiteboarding features.
These days, Mozilla, OmniWeb and other efforts have clear road maps with lots of disclosure about bug fixes, outstanding problems and the like. The great wars to define new formats, such as Dynamic HTML, are, blessedly, behind us. Feature introductions also seem less capricious and more like a conversation. Tabbed browsing, for example, is pervading browser after browser in a slow, relentless march toward a new, as-yet-undefined vision of what browsing is.
But where is reliability? None of these browsers yet has the kind of protected memory structure one might expect from a modern operating system. So when an errant Javascript confuses the browser, all those tabs of Web pages, not just the offending page, go down the tubes as the browser crashes. Nor do browsers have the ability to preserve user input in Web forms during crashes. Just spent half an hour writing a message in a Web-based e-mail program? It’s history if you happened upon a page your browser couldn’t swallow. Browsers cache Web pages, but they provide no infrastructure for recovering data temporarily buffered while you’re filling out a form.
Reliability Is Job One
Instead of pursuing reliability, the various browsers seem enraptured by the quest to define what a browser is supposed to be. Mozilla’s statement of branding says the program is sometimes only a browser of Web pages, sometimes a suite of applications and sometimes two separate programs — a browser and an e-mail program. Konqueror is a file browser and a Web browser, a document viewer for PDF files and other content, and a spreadsheet previewer. And did I mention it’s a dessert topping?
There’s nothing wrong with this browser renaissance. The competition between the half-dozen most prominent browsers will be productive, but developers need to start talking about the enterprise features these programs need to be really reliable.
The stakes are high. With the advent of .NET services, Java distributed applications and other Web services programs, browser technologies are becoming the platform for the next wave of software development. The day is coming when Web browsers will support true mission-critical programs. For the classic so-called “three-tier” Web program, much of the reliability will be buried in tiers two and three — the Web server and the back-end content store or database. But that doesn’t exempt the client, the browser itself.
As virtual runtime environments, such as the Java virtual machine and the .NET environment, become key pieces of infrastructure, issues of multithreaded operation, protected memory and user state management all deserve new attention. If the present level of reliability endures, Web services will never get off the ground.
Working on It
Fortunately, browser developers have been grappling with these issues for a while and seem genuinely intent on providing solutions. The improved performance and code simplicity of the Mozilla project’s Phoenix browser are welcome signs of things to come. Mozilla developers also have sweated over individual issues, such as how to restore user session state after a browser crash. And some browsers, such as Opera, have moved even farther toward solving some of these issues.
The desktop browser wars are thankfully behind us. Technologies developed through standards bodies are the driving force now, rather than arbitrary agglomerations of features. Programming standards, such as XML, RDF, SOAP and the entire Web toolkit, have ensured a level playing field for developers. It’s time to seize this enlightened moment to focus on the unfinished basement of the Web browser.
Note: The opinions expressed by our columnists are their own and do not necessarily reflect the views of the E-Commerce Times or its management.
Loading ...
No! What we need is to totally start over. The whole problem is the original design. Both Netscape and Microsoft bought that core code. It wasn’t intended for this Media. That is why Opera is so good. The instability is in the caching. It’s all those 1k icon files and the cookie monsters. One again, it’s those marketers at Microsoft…. Jeff are you out there… He is a Stanford boy you know… who invented the Spread Sheet according to him… Spawning the entire PC industry. <g><g> News Factor should really Interview this unsung genius who came from Apple…. You know what they say? One bad Apple spoils the whole barrel.
You see, Microsoft had this wonderful strategy for preventing you from running Linux in a dual boot. Make only one drive. That’s one of our biggest problems. Stupid…. There are limits to what the hardware can do. The disk fragmentation in your cache happens very quickly. The file system in Windows totally a mess because of the huge size… Software has its limits too. One solution I have is to partition your drive and make a separate one just for your Internet Temp folder and delete all those cookies and offline files every day. Then to make things even work better you can move that directory to another drive and that destroys all the hidden files. Then reboot. Then move it back and reboot again. This is what the engineers know to do. 🙂 Partitions make it possible to defrag quicker too. I keep most of mine about 4G and never delete a file unless you run out of space with my Temp drive about 2G. I keep one drive for Windows and its associated files, one for applications, one for my working data, one for archives and my Temp cache.
Another thing NOT to do is run a screen saver or have your e-mail checked unless you do it manually. Now those are the REAL killer app. Like I said, there are limits to what your hardware can do. Just learn to be conservative. All the marketing hype is just that! Get a CD player if you want to listen to music and use a radio to check those game scores while you are working. It could save your job. Does anyone know a salesman who doesn’t lie? <g><g> What do you think the iPod is all about? Apple still has the best engineers. Buy an Apple. They make both the hardware and software. Jobs gets the Work Done.
Jpony~
While some of the points are well-taken, overall I’ve got to respond with a "bah".
1. Browsers are not nor will ever be the "centerpiece" of business applications. They are of course used often (and very usefully) as the thinnest of clients over a business’s applications, but the centerpiece will still be the database and the server-side application layers.
2. Of course browsers can fail and generally… so what? Very few serious business applications actually rely on the browser to store application state or (worse) depend on Javascript for business logic in any way. It’s relatively trivial to preserve all application state so if a user’s browser crashes, that user just logs in again to the same location in the app.
3. Actually, usually the TCP/IP connection that the user connects over is much more faulty than the browser (think about how many times you have been stalled because of a dropped connection). That’s where the work should really be focused.
4. Honestly, I have had much less crashes, etc… with browser/web applications than with most standard client-server business applications (by far). One reason for this is that there is such a clear separation of client and server. Almost all the crashes one will encounter happen on the server side, with logic flaws, bad validation, etc… And _please_, losing form data because the browser crashes? Exactly how many other client front-ends preserve your unsubmitted form data when they crash? I haven’t seen any. And really, this depends more on the integrity of the desktop platform as a whole. Get rid of Windows and 95% of the problem is gone.
5. Yes, there ARE interesting new developments in formats, with XForms and — even better — Mozilla’s XUL platform. This is a big advance, and goes a long, long way towards making the browser a more robust application environment. This is not all just a big mess of incoherent frills; this is a major step that no commercial vendor has been able to envision (Imagine–an actual innovation coming from Open Source…;-0).
6. "The fault, dear Brutus, lies not with our stars, but ourselves…". The fault is usually in the web-based application _architecture_, not in the faultiness of the client. Since, as I said, the TCP/IP connection is usually the weakest link, especially over long distances, the real focus should be on how to make the central architecture truly fault-tolerant. Not an easy task always, but this is much better than allowing client faults to corrupt an application.
Thanks for articulating something which has been irritating me for years. Because I can still remember Netscape 2, one of the most unstable pieces of junkware ever written, I tend to put up with modern browsers with little complaint. You’ve just pointed out why I *should* complain.