Don't try to re-invent the browser, please.

I saw several "Is IE dead?" blogs and most recently DonXML's blog about this subject and I really think this discussion is not focussing on the real issue.

What's the problem with current browsers? It's not that they can't render version ABC of a given HTML, XML or XSLT variant. The problem is that they are used as application-GUI hosts while they are intended to be used as stateless viewers of information. Through an evolutionary process, Andreessen's tool to view hyperlinked texts has become an interactive viewer of a GUI for applications but still does that using the same old techniques. Which is a result of the way HTML works, and all mark-up languages in that respect.

I read all kinds of thoughts how and why IE should evolve but it really shouldn't. It should be put to rest, and the focus should be moved to an application which is already at our desktop: the CLR itself. It's a waste of energy when you are trying to re-invent the wheel that is already available: winforms. The majority of web-applications use cumbersome HTML-forms to try to build a workable GUI, while a winforms developer can do that with ease using the winforms glyphs and controls. If there was a way to run a GUI using winforms on the desktop of the website visitor, you can build a rich and powerful GUI with common technology which doesn't suffer from the fact that there is no scripting available, all HTML form glyphs are text based and other nasties related to HTML (or XHTML for that matter) which are totally avoidable when you use a decent GUI framework, like winforms.

I've been developing websites and webapplications since 1994 (ah, those good ol' days without images on pages) and I never understood why on earth a browser is used to host a rich GUI, because HTML is not meant for that, it lacks serious building blocks available in every GUI toolkit on the planet (even the console library Cursus has them!). Trying to keep it alive for webapplication GUI's is not the way IE should be evolved, IMHO.

The problem is platform independence. When Mono sees the light of day, a CLR with decent winforms is available everywhere. It should then be possible to run any decent winforms GUI frontend for any webapplication out there on every decent system and OS. IE as an application is then not needed anymore, the browser is then obsolete.

HTML, or its markup successor, will not go away of course. It will be rendered by components embedded in other applications, like helpviewer, blog readers and other tools. Such a component can be embedded in winforms as well, as a control.

The concept of the 'browser' is a concept of the past. Let it rest, let it die in peace, it's about time users move on to richer environments and technologies which truly connect user with application, no matter what type of connection (local system pipe/lan/wan/Internet via modem/ADSL/WiFi, you name it) is used and whatever flavor of browser and client side settings.


  • The 'browser' as an application should go away, iexplorer.exe should not live anymore. That's the idea I was talking about. This will not be possible with a flip of a switch (unfortunately ;) ), but if you ask me, I really do not see the relevance in the future for 2 'forms' namespaces, there is one gui: the desktop (or handheld or whatever).

    I hadn't read your blog about serialized guis nor read about avalon (I only saw some screenshots on the windows supersite). What triggered me to write this blog was your remarks on how it should be rendering XML using namespace engines and the like. All neat, but that's not the problem, because with another rendercontrol it can be embedded in IE now. The concept should change, not which rendering engine should be used. (because to me XML is not about visualization, but about datastorage following a structured definition). But perhaps I'm missing something essential which will cause that what I think should be done will never happen :)

  • We are on the same page, but our definitions aren't exactly the same. This is a new world, and until we get a standard definitions behind the ideas, that's bound to happen.

  • Hmm I think you're right.

    I hope that the W3C isn't involved in next-gen webapplication gui definition standards though.

  • What the hell are you talking about? WinForms and HTML share something in common - developers must control the positioning of various UI elements, i.e. controls. IE *does* have them - the HTML Common Controls. You can even use them in your own apps...including WinForms. IE6 on XP with Visual Styles enabled does, however, bind to CC6, in which case the controls are actually the Windows Common Controls.

    Why did GUIs starting hosting in web browsers like IE and Mozilla - because graphics representation has long-since evolved and the methodologies to do them really hasn't. IE already takes care of all the rendering with very little work by a developer to re-invent the wheel to display nice-looking GUIs. Comparing the easy layout capabilities of HTML to Curses is a joke! Sure there are problems when using HTML for your only GUI (InstallShield Developer and Microsoft Money come to mind) but those are overcome by writing simple ActiveX components and implementing your own hosting interfaces, which is still a *lot* easier than rewriting everything like that yourself.

    The web is an evolving thing and if browsers don't evolve with it, then *we'll* be the ones re-inventing technologies. Isn't it better than a single organization does it, tests it, supports it, and basically implements a "standard" that everyone uses?

  • This sounds eerily similar to the Java-applet view of the future we heard in the mid-90's.

  • Heath: yeah yeah, but I'm not talking about the LOOKS, I'm talking about functionality known for years in f.e. win32 and now winforms which are not possible (or better: are much harder to develop) in HTML if ever possible. I'm not talking about Foo Inc. and their 2 page website with a mailform, I'm talking about webapplications with sophisticated GUI's which are hard to develop in HTML using IE and easy to do in winforms. The main reasons: HTML is markup, not a gui definition language and HTML works disconnected, while it shouldn't.

    BTJ: I'm aware of that it sounds familiar :) Java had the disadvantage that the internet was not as connected as it is today: people dialed in via modems, today they have cable or ADSL and are always online, which blurs the separation between apps running elsewhere and locally.

  • Until Microsoft supports or makes an official statement regarding its position on projects like Mono, I would not count on the CLR and .NET to be a viable cross-platform development environment. Remember, the CLR may be an open standard, but the .NET framework is not. There is nothing stopping Microsoft from suing projects like Mono and DotGNU and that is enough to keep me away from thinking about .NET as a solid cross platform solution.

  • See my url, we are on the case!

  • Kingsley, cool :) I read somewhere the HWND issue is/was a bit of a problem with mono winforms, but if that's been fixed, I think mono will have a decent winforms implementation, which opens up a whole new ballgame :) Good stuff, Kingsley, keep up the good work :)

  • You got some points but I don't think you could expect to see Winform support "all over" in some time.

    If you only target Windows user with the latest Microsoft OS then Winforms is great. If you plan to target other users then web might be the way to go.

    Also...the web is no longer meant for stateless applications. You got many ways for implementing persistence in most web application frameworks. However, the applications are much harder to develop on the web.

  • Just for the record, Tim Berners-Lee made the first web browser... not Andreessen!

  • hmm, in that context, what *is* a browser then? since with gopher you also could traverse hyperlinks (sort of). Berners-lee did indeed invent a tool/format to hyperlink texts, however the concept of the browser as we know it today is not made by Berners-lee afaik, but by Andreessen and his team at NCSA.

  • Nope, TBL definitely bulit the first web browser as we think of it today. The team at NCSA just built a better one.

    The reason people like myself are crying out for an update to IE is that it still doesn't support the current batch of standards to an acceptable level. It doesn't even support all of HTML yet (the <abbr> tag springs to mind), it's CSS2 support has a distance to go and the sooner they support alpha transparency in PNGs (which was standardised in 1996) the better.

    I'm interested in the rendering engine, not the browser. As it is, I use Gecko engine browsers (currently Firebird) and can't really see myself moving back to IE even if its end user functionality (tabs, popup blocking, typeahead find and so on) caught up. It's just too convenient having a browser that I can install on any operating system I care to use.

  • Maybe we do not all have the same use of HTML. Said simply: If you think I'm going to develop my web site using web forms, then you are dreaming. I think, you are talking about different things, different needs.

  • Tell me, why should the underlying implementation of a given method be the same on mono as on .net / win32, i.e.: using win32 functions? If a class 'button' mimics a button, no-one should care how that class does that, be it calling into GTK+ or win32 or other widget lib, the bottom line is that it should behave like a button.

    The problems arise when .NET code starts to use HWND related functionality to create 'nice' effects, like style menus, or a treeview control which does more things than it currently can do.

    However, 100% .net code should be runnable on a mono winforms implementation which simply implements the functionality using a native library like GTK.

  • Here, here, Frans. I posted on this topic today (see link), and I mostly agree, but I think there is a real syngery possible (God I hate that word, but it actually applies) combining the browser chrome and HTML/CSS with the CLR. If standalone forms would have been enough, Java would have won long ago, but HTML has a decided advantage in layout flexibility (and widget beauty, but I'll stay away from that). HTML forms and toolbars and really suck, but so does Java and WinForms when you need to design a long form with hierarchal datagrid-like properties. The best solution will be to run both in a seamless browser window (w/ or w/o the browser toolbar, just like pop-up windows now), which will overcome the web issues of limited form widgets, fixed positioning, ugly scripts, and server round-trips without sacrificing the things people *like* about browser interfaces.

  • All pretty windows centric. I cannot see that the imitation of one particular proprietary form tool (that is what mono is intended to be) shall be the bright future. I rather see this as an argument for independant open source form languages. XUL could be it.

    Another question is, how comes that it is often easy to convince use to use the so restricted browser GUI. Concepts like collecting favourites and sending links via e-mail to someone else would all needed to be reinvented by a GUI of the future.

Comments have been disabled for this content.