April 26, 2010

Why isn't the browser rendering engine loaded dynamically?

I got thinking this morning after reading yet another blog post about replacing IE6... Actually, this one was veiled as Google trying to oust IE as the market leader, but it got me to thinking about a longer term solution to the problem that will clearly be replayed in corporate environments for... well for as long as I can see.

As a developer and innovator it frustrates me endlessly that we're catering to the worst engine on the market. It also frustrates me that companies like Firefox, Google, Opera and of course Microsoft can't innovate at the rate they want on their own engines without pissing off every developer under the sun because we all have to either pick an engine or only cater to the lowest common denominator or write heaps of extra code to make use of all the neat little extras provided by each individual browser. This is a horrible developer experience. Admittedly jQuery has made this far easier - All Hail jQuery, we love you!

Along comes standardization which has attempted to make developers lives easier, I love this, but at the same time, I hate it. Standardization means that everyone is running at the same pace developing the same experience, or trying to bias the standards to their own ends... and it's all running along at a snail's pace. How long has HTML5 and CSS3 been coming? How long will it take before it's not only commonplace but expected?

Right now we're campaigning to get rid of IE6 which we've already determined is so prohibitive, it's not likely to happen any time soon what with the fact that corporations have spent millions of dollars writing applications that target this environment and don't function properly in newer browsers. 10 years from now we'll be campaigning to get rid of IE9... or at the current rate, maybe we'll still be trying to get rid of IE6. Even if we do manage to get rid of IE6, it'll probably just be replaced with the next standard Microsoft browser... and we're going to forever more be plagued with the corporate environment holding back technology.

So how do we make everyone happy? What if we could allow browser developers to go back to running off at their own pace developing whatever rendering experience they wanted? What if developers didn't have to write cross-browser code? What if we could provide this without corporate I.T. departments having to rewrite millions of dollars worth of code?

This got me to thinking about how to solve the issue in the long term. Why are we held back? It's not specifically the IE6 application that's holding us back, but its crappy HTML rendering engine and corporate applications targeting it that are holding us back.

One potential idea I came up with is [and I'd like to stress that this is really just a seed of an idea just now that hasn't been fully worked through]: Why don't we separate the rendering engine from the browser application and load this dynamically at browse time through a plug-in, in a similar manner to loading jQuery or countless other frameworks from a CDN.

What if our web application were to define which rendering engine it relies on rather than having to cater to them all? - this could be defined through meta data, javascript, some other mechanism I haven't thought about, and the correct rendering engine could be pulled down as required?

This would mean that as new more advanced engines become available, they could be added to a CDN and new apps can come online targeting these engines without affecting applications that target older ones. This would allow creativity back into the web-development process from a rendering standpoint and allow browsers to run off at breakneck speeds again implementing whatever rendering ideas they wanted without affecting everyone else's applications. Developers could target the best engine for their web application without having to write cross-browser code to make it function everywhere else.

All we would need to standardize is the way the rendering engines plug into browsers. Users can use whatever browser makes them feel good about themselves; Developers can target whatever engine they want knowing it's going to be pulled down at runtime specifically for their application; Corporate I.T. doesn't need to replace all their home-grown applications that target IE6.

10 years from now, instead of everyone campaigning to get rid of antiquated IE9 because it's crap, developers could develop for the next engine safe in the knowledge that corporate apps targeting IE9 will still work just fine because they're not browser dependent and the engine is available on the server/CDN for download as it's needed.

  • Browser application developers could shift focus from rendering experience to providing the best application experience.
  • Rendering engine developers could focus on providing the best possible developer experience.
  • Corporate I.T. can keep all their current applications running without having to rewrite them.
  • Web application developers could pick the best rendering engine for their application and code only to that engine without the need for hundreds/thousands of lines of cross browser compatibility code.

Everyone wins.

Disclaimer: This is way outside my realm of expertise of CRUD development, and currently I don't really have the any idea how I'd go about developing this or even at this point if it's possible. That said, I will welcome any input that could help get this idea rolling.

All that said, let's suppose that someone were to do this, what would need to be overcome? So far from the comments I've picked up the following things that need investigated:

  • Would the EULA's of the current engines allow them to be used in a piece of third party software that would do this? This could be a showstopper...
  • Could existing engines be wrapped such that the browser can download the web page code, determine the engine based on some kind of meta-data and fire it into the correct engine? If so, what possible solutions are there for this?
  • Could the whole precompiled engine be downloaded dynamically and installed on demand without compromising security?
  • Could all this be done in a simple manner that would provide the user with a seamless (or as close to seamless as possible) experience?

Google frame has gone part way toward solving this problem with their Chrome frame for IE. What I'm proposing is taking this a step further and making it possible to plug all engines [frames] into a single shell.

18 comments:

  1. Interesting perspective. There's a lot of broad stroke to this idea that I find extremely attractive; I think you'd get some resistance from browser developers but if my recollection serves, many rendering engines often are pluggable from the get-go (as packages, libraries, or other linkables). Trying to settle on which CDN to use, what format engines should be available as, not to mention which OS's and architectures each engine supports... well, ultimately the problem shifts and changes its face. Still, I like this idea; it appeals to the web-developer in me who has, similar to others, waged a decade+ long war against browser incompatibilities. I'd love to see something like this come into play; might be worth looking into further. Kudos to you!

    ReplyDelete
  2. Interesting idea. But it either presupposes that Microsoft will be supine in allowing access to their engine, or their lawyers will allow reverse engineering of the rendering machines in their browsers.
    It would also presuppose that there is enough profit to the third party developers who would 'clone' (for want of a better word) the MS engines of the various versions.

    ReplyDelete
  3. One thing which might be extremely valuable in this case might be webapp functionality vs. content websites.

    ReplyDelete
  4. @Chris Kemp

    In answer to the two key points you raise:

    Q: Would this be profitable?

    A1: Let's suppose this were an open source application for the benefit of web developers everywhere. The simplification of our lives might indeed be motivation enough to get the application developed. Thus it would be indirectly profitable for us [as web developers] to produce such an application.

    A2: I suppose also there my potentially be a profit stream for this - if the shell with the right engines plugged in were to save companies millions of dollars worth of application rewrites - surely the application would be worth a small fee? Thus it may be a financially worth while venture for a company to spend the time to develop it. [Just thinking out loud... I don't have scientifically valid answer to that].

    Q: Would the be doable in a legal sense?

    A1: I don't know for sure, I haven't investigated this yet.

    A2: Could we use a wrapper system to provide the plugins for existing engines rather than reverse-engineering the engine itself? Given that most engines seem to be freely available for distribution/inclusion in other applications, would this fall under acceptable use according to existing EULAs?

    Thanks for your input.

    ReplyDelete
  5. (Not speaking for Google, obviously :)

    I'm sceptical that this is really practical. Consider that as rendering engines become more complex, they're starting to take in things like GPU drivers etc. Do you really want your browser to be able to just download and install code that has that much control over your system? Obviously renderers are (generally) native code - how do you make them secure?

    Moreover, I suspect there would be problems with integrating renderers between browsers. Chrome uses Webkit, but with a single-process-per-tab model which I believe involved various changes within Webkit. Doubtless future innovations will also require all kinds of different models.

    By trying to standardise on one way of interacting between the renderer and the rest of the browser to the extent that they're really plug-and-play so that apps can choose which one they want, I suspect progress would be hampered.

    Better (IMO) to keep competition within renderers for things like speed and standards compliance - and write your app to the spec rather than to one particular renderer.

    Just MHO as a non-web developer, mind you...

    ReplyDelete
  6. @Jon

    Thanks, I was already wondering about a couple of these points and how they could be overcome - if at all they could.

    Part of my motivation for raising this point are covered by my points below:

    1. Standards seem to be stifling innovation... or at least causing it to grind to a halt, but
    2. Lack of standardization between the browsers causes developers nothing but problems and means that
    3. We either don't use all the cool features provided by the rendering engine, using only the common standardized bits, or
    4. We write reams of extra code to make all the cool bits work in a cross browser manner.

    I think these are the key points I'm trying to find a way to address.

    I do agree with your points, but wonder if these are merely hoops that could be jumped through to find a workable solution.

    ReplyDelete
  7. @whileicompile

    I agree, in many cases common garden variety "web sites" don't appear to be hampered as much as the all singing all dancing web applications. However, it's the web applications that have costs millions of dollars to develop that are holding up the termination of IE6.

    As long as companies are unwilling to pay the "upgrade fee" of dropping IE6, we're stuck with the choice:

    Don't support IE6 and thus corporate employees stuck with IE6 can't view your site as you want it displayed.

    Or

    Write tons of extra IE6 specific code to cover all the bugs in its rendering engine.

    There comes a point where the cost to you supporting your IE6 (corporate/government/school) guests exceeds the value you get from supporting them; and you have to ask yourself the question: Do you want that market or don't you?

    I guess it depends on the product/site you're developing. If you're developing a personal use site, like Facebook, YouTube et al, then it's much easier to say that you don't want to support them. If you've got a corporate web application, like a bug tracking system, a source control interface, a project management system, an expense management system - then you don't really have a choice. If you don't support IE6, you're excluding a key part of your market.

    A solution that allows your application to target a specific engine regardless of the user's browser means that you're no longer stuck with supporting IE6. Especially if the browser you provide with your product allows IE6 applications to be viewed as if they were run inside IE6.

    ReplyDelete
  8. This comment has been removed by the author.

    ReplyDelete
  9. Ben, what you're proposing reminds me of using IE Tab on Firefox and Chrome: when a site is "IE only" you can use the extension to render it without leaving your favorite browser. But I guess you're thinking about something more automated? (Now you have to configure manually IE Tab to tell the browser which sites it must render like IE).

    This idea seems like the "Eclipse IDE" of Web browsers, with each "language plugin" being a different rendering engine.

    If I understood you well, the idea is more or less something like this:
    - Have a barebones browser
    - Every web page will tell the browser which is its preferred rendering engine (perhaps in the page's head section)
    - The browser renders the page with its chosen engine

    Sounds good, but... Who will develop this browser? What if two or more of the Web big names try to implement this, perhaps with different approaches?

    More questions are flowing now in my mind, will post them later when they get clear...

    Nice idea!

    ReplyDelete
  10. http://code.google.com/chrome/chromeframe/

    ReplyDelete
  11. @Scottlet If you'd read my whole post you'd not the comments I made regarding Google's Chrome Frame. It doesn't solve the whole problem. It only solves it for Google. We need a more complete solution to prevent the issue for happening again.

    ReplyDelete
  12. @José GD

    Yes, this is somewhat similar to the IE tab but more automated - like Chrome Frame.

    What I'm suggesting is a standardized way of plugging in an engine. The engine can do whatever it wants when called upon to display a page - in the same way that Chrome Frame does.

    Perhaps if it wasn't installed yet a little prompt could come up to say "The X correct display engine this page is designed for is not yet installed, are you okay with us installing it? If you don't install this engine, you will still be able to view the site, but it may not appear or work as the developer intended. [Install][Don't Install]"

    If the user clicks yes, then the correct engine is installed and the page looks and displays as it was intended. If the user clicks no, the page will still be displayed but it's anyone's guess as to whether or not it'll look/function correctly.

    If the engine is already installed, then it would be loaded quietly without harassing the user to select the right one. This could be done with the use of meta data in the page in the same manner as Chrome Frame or some other way - as long as there's a standardized way of calling/loading/installing the right engine it makes no difference which engine is loaded.

    ReplyDelete
  13. Part of the problem has been people unwilling to upgrade their browser. Google's tried to solve this by automatically updating the browser without the user even knowing.. I saw a nice graph showing the usage of each version of Chrome, and how the older ones drop to nothing almost immediately.. can't find it right now though.

    ReplyDelete
  14. @mwarkentin

    I agree, *part* of the problem is people unwilling to upgrade. The other *huge* part of the problem is companies that've invested millions of dollars on development of applications that target a specific browser engine that means the browser can't be upgraded/replaced without a significant amount of further investment. This makes it impractical to upgrade meaning it's not so much unwilling to upgrade as unable to upgrade.

    Fighting the people who are just unwilling to upgrade is a small fight. Solving the problem for those who can't - that's a much bigger problem.

    ReplyDelete
  15. I really can't believe that Microsoft haven't just bought out an official IE6Frame plugin that works just like Google Frame. If they did that, every IT dept in the world would have no excuse not to update to the latest version of IE. Well... apart from their own laziness and unwillingness to create work for themselves.

    ReplyDelete
  16. @AndyW

    They'd still need to bring out a frame for every major browser which doesn't make sense. That approach just causes another maintenance headache - sure it's for them instead of us but it doesn't solve the overall problem.

    We need a simple solution that removes all these maintenance headaches for *all* the developers in the stack but still provides an avenue for innovation at a more reasonable pace.

    ReplyDelete
  17. The term "browser engine" is slightly vague. There are "parts" to a browser responsible for the lower-level calls to the operating system (Network, Video, Sound, Input, etc.), and there are parts responsible for interpreting the site code (HTML, CSS, Javascript, etc). The parts of a browser that interpret web code provide composition. These are the "parts" most often subject to standardization.

    If the engine host app were to implement a common interface, and have platform specific implementations, it could abstract some of the messiness. For example, OpenGL vs DirectX for hardware acceleration, dependent on which platform you were on.

    An "engine" (if that's what we're calling them) developer would write code that targets the common interface, and that interface inside the host app translates the commands to the correct technologies for the platform.

    A per-website downloadable engine would be left to do the work of web-code interpretation, providing composition.

    A website with a new engine could provide the client with support for new versions of web-code (HTML, CSS, JavaScript). It could even go as far as to allow new web languages to emerge.

    Standardization of the interface layer would be beneficial, but could be done in a way that doesn't stifle the innovation of web features.

    This would address some concerns for security (the engine could only do what the interface, and its implementation, allows), and performance.

    What I'm suggesting, however, is a different model than taking current browsers and hosting them in a single app, selecting the best to use.

    It might not solve the current problem of being stuck with IE6, but it could prevent it in the future.

    ReplyDelete
  18. What you are suggesting is essentially a world where going to http://www.cnn.com leads me to download IE9, whereas going to http://www.slashdot.org leads me to download firefox, all transparent to me. The "browser" shell that hosts these 2 browsers is essentially the operating system, or rather, the desktop environment I am using on my PC.

    Ultimately, on a global network such as the internet, every piece of your computing software stack can be considered as a "browser". Your Intel-based x86 instruction set can be thought of as an interpretive engine that is akin to javascript; your win32 /GDI+ / DirectX API can be thought of as your CSS and HTML renderer. What is the difference? What amazes me about the computer industry is how much smart people are willing to continuously re-invent everything over and over again, building abstractions on top of abstractions, ultimately accomplishing the same set of tasks. It must be something in the education.

    ReplyDelete

There was an error in this gadget