6

The web platform is hip these days. But the web platform consists of many parts that are conceptually separable, developed at different times and paces, and (most important to me) could be useful on their own. Basically the web platform is "a browser", but the browser lumps together several things:

  • HTML/CSS renderer
  • DOM
  • scripting on the renderer and DOM (JavaScript)
  • sandboxing (including cross-site scripting restrictions, limited access to local files, etc.)
  • the browser itself, which is a GUI app with its own look and feel

My question is, am I really the only one who thinks it would be useful to have each of these as separate components that are usable on their own, mixable and matchable with different versions of each other and with other programming tools? The renderer/DOM are the ones I'd really like to see abstracted, because HTML/CSS is a very nice way to describe interfaces, but it's annoying that it can only be used to describe interfaces on a web page.

Most notably, the link between the rendering engine, JavaScript, and the browser GUI seems almost impenetrable. This makes it really annoying to use HTML/CSS for interface design, because your interface is always going to be running inside a browser that you don't control, and you have to use JavaScript. Compare that to other interface toolkits (like Tk, Qt, Wx), which often have bindings to multiple programming languages and can be leveraged in standalone apps that you have total control over. (This means, for instance, that browser-wide user preferences for things like fonts can interfere with your presentation, and it means any menus, keyboard shortcuts, or other UI doodadssyou create have to compete with those of the enclosing browser.)

In similar fashion, it's very tough to write something that has an HTML/CSS interface, but stores data on your local computer, because browsers think it's an insecure web app, even if what you want it to be is just a "regular app".

I know there are historical reasons why people did all this together, but I find it baffling that at no point have people thought it would be worthwhile to make a separate, pluggable rendering engine that could be used with multiple programming languages, or a "browserapp maker" that would run a single web app in its own window, or anything like that.

Or, do such things already exist? I'm aware of things like the web widgets in GUI toolkits, and XULRunner, but as far as I can see these still seem to be embedding a browser-like amalgam of several components. (In particular, there does not appear to be a stable, mature rendering engine with DOM-access bindings for languages other than JavaScript.) This makes them more heavyweight and less integrable into an application than it would be if you could just grab an HTML rendering library the same way you grab Qt or a PNG library or anything else.

Improve this question
3
  • The 'javascript' part has certainly been modularized. Its used as a query language in some NOSQL databases (e.g. couchdb), it is a server language (node.js), or on the command line (jsc from webkit).
    – user40980
    Sep 16, 2013 at 2:35
  • 1
    @MichaelT: It exists separately, but it hasn't been "modularized out" of the browser in the sense that you can use something else there instead.
    – BrenBarn
    Sep 16, 2013 at 2:41
  • As browsers compete, they also compete with javascript engines. Allowing one to put webkit engine into (say) IE would diminish webkit's market share - that would be a bad thing for webkit. People have enough headaches with 'IE engine' vs 'webkit engine' for glitches. Picture the nightmare of 'IE with webkit' vs 'IE with Caraken' vs 'IE with SpiderMonkey' vs 'IE with JScript'. Ghads, please no.
    – user40980
    Sep 16, 2013 at 2:46

2 Answers 2

Reset to default
1

So, you know the historical reasons. And your text suggests that you have experience in matters of modularization and the technologies involved around the web subject. So I guess you probably know all or some of the following:

  • given the sad state of affairs, it is very hard to change in a way that doesn't break existing software.

  • Those things are so widely deployed and in such a "difficult to modularize" fashion that it seems (but is not necessarily known) that it is cheaper to build on top, than to adapt the platform.

  • Way too many people depending on too many idiosyncrasies to work as they are working right now and way too many people required to agree before moving forward (hence, the existence of standard committees and so forth, involving people who may or may not have the qualifications for the task of defining high quality designs to solve yesterday's problems in specifications that will be half-baked implemented and used for decades to come).

  • Marketing and market competition can rule over technological merits.

I probably shouldn't put a question in an answer, but here is, in the name of thought provocation: have you tried what you propose? Of course, constraining the hypothetical solution to the obvious limitation that it should interop well with what already is there, keeping the existing portability properties while improving significantly the design.

Improve this answer
3
  • 1
    I haven't tried it, no, because I know it's way beyond me. One main reason I ask the question is because I am a puny programmer of dinky apps, not a mighty programmer of the things you use to make apps. I certainly see the truth in your answer, but I'm always resistant to believing such answers, because they basically amount to "people prefer to dig themselves deeper and deeper into holes instead of building ladders", and that's an uncomfortable aspect of human nature. :-) (Also, at this point I'd be fine with breaking a lot of existing software just to get something better.)
    – BrenBarn
    Sep 15, 2013 at 19:36
  • Consider that there are a lot of people in the field that do not see the modularization problems you mention -- there is not even an accepted definition for what a "module" is to this day, since David Parnas made his shot at it in the early seventies -- most people when asked what a module is begins with "to me, a module is...". I think it is not so much that people prefer to dig themselves, but they have different thresholds for pain -- and most of us are just fine with being comfortable where we are instead of find better ways of doing things.
    – Thiago Silva
    Sep 15, 2013 at 19:49
  • @BrenBarn amen to breaking it. At some point, someone eventually will come up with better ways. There are people trying. Personally, I've been dwelling with these problems and possible directions for years as well.
    – Thiago Silva
    Sep 15, 2013 at 19:58
0

There's indeed been an attempt, FireFox tried to open up its GUI toolkit for non-browser applications under the label "XulRunner". We tried it, not a success.

For starters, XulRunner competes with far better toolkits such as Qt. The C++ interface is downright horrible. You're also tied to Javascript for a lot of tasks. Performance isn't great.

It's also documented up to the usual Open Source standards. We never figured out how to remove the spelling component.

That said, you're mistaken if you think Qt is lightweight similar to a PNG library. However, it is far better designed, and you can actually remove bits you don't need. It's really easy.

So, the conclusion is that it's been tried, and did not create a convincing product.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.