I came across the Mix Gestalt project tonight and I thought I’d share some thoughts. It’s a bit of script that effectively sucks code snippets in languages other than Javascript out of your page and converts them to programs running on the .NET platform.
While interesting, it has a number of drawbacks that make it far less interesting than the HTML5-based approach that works in the standards-compliant browsers based on WebKit, Gecko and Opera, as well as the improved IE8.
First of all, it has to bootstrap .NET into Firefox (or whichever browser you are running it in). This adds a few milliseconds to your page’s cold load time if it’s not already loaded. In the day and age of fast websites, any additional page time is just a no-go.
Once it’s up and running, the code that Gestalt compiles has to talk to the browser over the NPRuntime interface. Imagining pushing the number of operations required to do 3D rendering or real-time video processing becomes very difficult. To offer a comparison, the Javascript code that runs in Firefox is JIT’d to native code. When the native code has to interact with the DOM, it gets dispatched through a set of much faster quickstubs. For browsers that run plugins out-of-process like Chrome and the future Mozilla, NPRuntime will be even worse!
One of the other claims about Gestalt is that it preserves the integrity of “View Source”. I’d argue that View Source is dead – and it has been for some time now. I rarely trust the View Source representation of the page.The web is still open, but it’s more about inspecting elements and runtime styles and being able to tweak those. I rarely trust the View Source representation of the page. Dynamic DOM manipulation has all but obsoleted it. Firebug provides this for Firefox, while Chrome and Safari come with an advanced set of developer tools out of the box. Even IE8 provides a basic, though buggy set of inspection tools.
The last unfortunate point for the Gestalt project is that it requires a plugin installation on Windows and Mac, and is effectively unsupported under Linux. You won’t see any of these Gestalt apps running on an iPhone or Android device any time soon either.
So where do I see the right path? HTML5 as a platform is powerful. Between <canvas>, SVG, and HTML5 <video> you get virtually the same rendering power as the XAML underlying Gestalt, but a significantly larger reach.
As for the scripting languages, Javascript is the only language that you’ll be able to use on every desktop and every device on the market today. Why interpret the <script> blocks on the client when you can compile the Python and Ruby to Javascript itself, allowing it to work on any system?
Regular readers of my blog will know that I’m a big fan of GWT – a project that effectively compiles Java to Javascript. For those interested in writing in Python, Pyjamas is an equivalent project. I’m sure that there must be a Ruby equivalent out there as well.
Javascript is the Lingua Franca of the web, so any project that hopes to bring other languages to it will have to take advantage of it if it. I’d hope that the Gestalt project evolves into one that leverages, rather than tries to replace the things that the browser does well.
Not sure why the NPRuntime interface would be an issue for video rendering or 3D as you mentioned… Gestalt can leverage XAML for graphics intensive operations instead. Also, the code running through Gestalt is JIT’d as well, so it is also running as native code.
I don’t know if I’d characterize this as a replacement for Javascript so much, for a number of points you’ve already mentioned (like availability on different platforms). It’s an option for more advanced functionality where it is supported. Who knows, maybe it’ll end up being a bridge to broader language support in browsers in the future. Choice can be a good thing.
Jason,
NPRuntime is far slower than native dispatch. Each browser/plugin call is marshalled across a C function call by string name. As those of us that worked with COM can remember, IDispatch was orders of magnitude slower than the corresponding native calls.
When you also start taking into account newer browsers like Chrome that run plugins out-of-process, you start to see how untenable NPRuntime is for high-performance code.
Choice is a good thing, but the technical hurdles this project face make its current approach untenable. Cross-compilation from Python/Ruby to Javascript is still, IMHO, the only way to go.
Re the Linux part:
It runs on moonlight
http://tirania.org/blog/archive/2009/Jul-22-1.html
Aleksander,
Yeah, I’ve heard about Moonlight, but it’s the same as saying that Gnash is a reliable way to run Flash under linux on other platforms.
They are stuck perpetually in followup, and most distributions don’t even ship Moonlight out of the box. If Microsoft supported Linux, even at the same poor level that Adobe does for Flash, it might be a consideration for Linux.
humm ok you are taking about one aspect only… but there is another one… the rails core always said that “velocity” is not the target… but elegance and “enjoyable” of coding…. i write in a lot of languages (low to high levels) … including ruby… and i can tell you that ruby is so fucking nice and so good to maintain that i give a sheet for “Lingua Franca”. Thankyou.
one more think… i will tell the future now: microsoft (because is a bad company) dont gonna follow the standard and we all gonna pass nights awake trying to make the beatifull html5 page be cross browser…… and soon we gonna need to use another “cross browser library” like jMakeHTML5WorkInEveryBrowser.js
I don’t think I’ve ever heard Javascript described as one of “the things that the browser does well.” It’s an abomination of a language. Any move towards abstracting away from it and allowing developers to use the language of their choice in browsers is a good move.
Every other environment these days supports pretty much any language you like, and combinations thereof: why not the browser?
I have no issues with running other languages in the browser, but there isn’t a standardized VM across browsers (and it’s unlikely there ever will be). With that in mind, the only possible solution that doesn’t involve a 3rd-party plugin (and all of its disadvantages as listed above) is compiling these other languages down Javascript. As I mentioned above, I’m a big fan of GWT which lets me use my language of choice, Java, in the browser without a plugin.
Javascript *is* what the browser does well, because it’s an integral part of the browsing experience, your feelings on JS as a language aside. The browser engine is tuned to communicate with the JS VM more than it will ever be tuned to communicate with external plugins.
My point still stands- while the browser *will* end up getting support for additional languages, it’ll be through external cross-compilation to JS, not fundamentally constrained hacks like Gestalt. If there isn’t a Ruby-to-JS or Python-to-JS or Scala-to-JS compiler that tickles your fancy, there will be at some point in the future.
Matt
I find it funny that you describe Gestalt as a hack and compiling down to JavaScript as an elegant solution.
The reality of the situation is that the evolution of the web has left us with a single language platform with UIs designed on a framework built for documents. If we could start over we would end up with a standardized VM and a better, more well defined UI mark-up and DOM. It would be much more like Gestalt that hacking Java down to JavaScript.
Joe,
If we could start from scratch, there are a lot of items that we could do better on. Unfortunately, that’s all academic and we have to work with what we’re given, which is a single language common to all browsers, JavaScript and a single markup language, HTML.
Since we don’t have a choice of which technologies are available out-of-the-box, they don’t factor in when I call something “elegant” or “a hack”. Gestalt ignores the reality of the situation which dictates that plugins are and always will be second-class citizens in the browser world. They are going to be running out of process in the two biggest browsers soon (FF and Chrome). This guarantees that there will be a major performance loss. Out-of-process vs. in-process communication can give you a 10x-100x performance hit.
My point still stands: Gestalt is an “interesting toy”, but it will never be useful as a practical development tool.
Good day, great site. Want to get cash for blogging? Check out: http://bit.ly/PaidWriting