WebKit, Mozilla, and Chrome are seeing some phenomenal gains in the arena of JavaScript and HTML rendering standards and performance. If you bust out your magnifying glass, you will find a one pixel tall bar on those charts: Internet Explorer, the browser with the largest user share, is trailing the pack. And that is causing thousands of tiny violins to play in unison with the cries of web developers claiming that Microsoft is holding back Web 2.0. And that may be true; that is, if Web 2.0 will have HTML, JavaScript, AJAX, CSS, et al championing this so-called revolution. (These technologies will be from here-in referred to as just HTML/JS for brevity)
One of the prominent characteristics of Web 2.0 applications is that many of them are mimicking traditional desktop applications while using the browser as the application platform. The primary benefit to this is that the application is then cross platform, and that your data is available anywhere. A platform agnostic application runtime, eh? That sounds familiar. Essentially, a primary goal of Web 2.0 is to bring web applications to the desktop.
But, HTML/JS was not intended to behave or be used in the manner that it is heading. Every 10 or so years, there have been fundamental changes in application development, and it is beginning to show its age. To paraphrase the past and my vision of the future of development:
1975 – Imperative Programming fundamentals: C, Pascal, Basic
1985 – Object Oriented: C++, Ada
1995 – Rapid Application Development: Java, Visual Basic, Delphi (HTML and JavaScript are born)
2005 – Metaprogramming/Reflection, XML integrated development (LINQ to XML, XAML, XUL): Ruby, .Net, Python
2005 and beyond – Language Agnostic, Platform Agnostic, Web based distribution, Ubiquitous data access
HTML/JS, initially a static markup driven platform, is trying to morph into a desktop application platform tied to the web: the current/next application development platform. I think its time to put that horse down. And apparently so does Microsoft (Silverlight) and Adobe (Air). Rather than try to bring the web to the desktop, they’re approaching it from another angle: bring the desktop to the web. I will dub this movement Desktop 2.0. [0]
My blatant ageism aside, what is wrong with HTML/JS?
1) Everything you write is automatically Open Source
Your offline enabled application will have the entirety of it’s HTML/JS source code available. Thousands of man hours of a company’s IP can be easily inspected and reproduced. And though this concept would probably make GNU Richard Stallman shit his diapers with glee, 99.9% of the time, open source models are not profitable. Money makes the world go around.
2) Performance Blows
JavaScript performance will always and forever suck compared to languages that support strict typing.
3) No Developer Freedom
“If you took every bad thing about C and every bad thing about Visual Basic and added in a few more bad things, it would be almost as bad as Javascript.” Developers should be able to do application and web development in any language of their choice. Being restricted to an eternity of JavaScript development is sort of how I imagine the ninth circle of hell. [1]
4) HTML has no Sex Appeal
It’s just too hard to make HTML sexy. Don’t even get me started on animating said HTML. And yes I know about how awesome Canvas is supposed to be. So following that to its logical end, web pages will eventually just become a HTML hosting a single canvas:
<html>
<head>
<script type="text/javascript">
function drawStuffOntoCanvas()
{
}
</script>
</head>
<body>
<div>
<canvas id=”the_canvas”></canvas>
</div>
</body>
</html>
How is that any different from HTML hosting a single Silverlight or Flash object?
<html>
<body>
<div id="SilverlightHost">
<script type="text/javascript">
createSilverlight("/pathToSilverlight/Page.xaml", "SilverlightHost", "Silverlight Application");
</script>
</div>
</body>
</html>
Well, for starters, Canvas is not markup driven like XAML/MXML. Why is HTML 5 taking a step backwards in UI development? Canvas is a flimsy JavaScript Band-Aid on the bullet wound that is HTML. [2]
To summarize, I can’t imagine any desktop applications of real significance being created with the existing web technologies. Imagine the best attempt of creating a Web 2.0 version of Microsoft Office in HTML/JS. Actually, you don’t need to imagine. Just visit Google Docs. Does anyone actually use that to do real work? The applications themselves are extremely crippled in comparison to their desktop counterparts. The only value it really provides over Microsoft Office is ubiquitous data access. And sadly, I’d rather use Sharepoint, which is no spring chicken either. [3]
Furthermore, as the line between the Web and the Desktop is blurred, you will see developers from one camp bleeding into the other. They’ll be presented with two technologies that are trying to achieve the same thing. Learning HTML/JS allows developers to build great web sites, but clumsy desktop applications. Learning a “Desktop 2.0” technology will allow that developer to build better web sites as well as great desktop applications. What do you think they’ll choose?
[0] Crap, it looks like someone else beat me to it. With a similar article title and thesis to boot. WTF!
[1] Why is it called JavaScript anyways? About the only thing Java and JavaScript have in common anymore is how much they suck.
[2] Someday, someone, somewhere will invent a XML markup that can be converted at runtime into Canvas JavaScript which is then eval’d and consumed by web pages. Files that contain the Canvas markup will have the “.cnvs” file extension. Usage of CNVS will become widespread and ECMA will standardize this format. Soon everyone will write their web pages in entirely CNVS, and browsers will forego the necessity of the HTML host. HTML slowly withers away. </jest>
[3] Live Mesh would also allow you to access your documents from anywhere, seamlessly. I actually prefer that to Sharepoint. It’s pretty awesome, truth be told.
10 comments:
Well said.
I like your blog - but this was a poor post.
1. Not all HTML/JS is "open source". The source code is available, but that isn't what "open source" means (it's a term with a specific meaning).
2. JavaScript performance does not have to suck. Basing that on a single benchmark as you do - or even a mix of benchmarks - is misguided.
Yes, static typing helps for performance. But there is no theoretical reason why JavaScript cannot get quite close to native code, for intensive loops and calculation, as the information static languages have at compile time is available for dynamic languages at run time. Utilizing said information requires a sophisticated JavaScript engine - which late last year we finally started to see appear. As tracing etc. methods are refined, performance will continue to improve.
3. JavaScript isn't *that* bad. Read "JavaScript - The Good Parts" for a good elaboration on the topic.
But I do agree web developers should be able to use their languages of choice.
1) Yeah, by open source, I really meant "source code is freely available". I understand they are not the same thing. The statement about thousands of man hours of work being available to anyone still stands, which was the point I was making.
2) Honestly, no benchmarks are necessary to make the statement that JavaScript performance is anywhere near that of "native" code. Just like how C#/Java will never be as fast as C. And C will never be as fast as assembly. I posted that benchmark mostly out of amusement. Prototyped languages will never be as fast as static languages due to their nature.
I think it is a poor decision to tie HTML to a language, and not a runtime/bytecode (like JVM or CLR/Mono). You are restricted to the limitations of that language.
3) And I'm sure George W. Bush has some fine qualities too if we look hard enough. :)
Joking aside, strict/strong typing vs prototyping is basically a religious argument: I'm sure a lot of people love JavaScript as much as others dislike it, just don't force it on everyone. :)
1. "The statement about thousands of man hours of work being available to anyone still stands, which was the point I was making."
It is just visible, not available for use - you can't use it in your own projects legally. Just like you can't use Microsoft Office .dlls in your own applications without permission, despite them being present.
2. "Honestly, no benchmarks are necessary to make the statement that JavaScript performance is anywhere near that of "native" code. Just like how C#/Java will never be as fast as C."
That is the case *right now*, but isn't necessarily the case. E.g., given the code
x = 0; for (int i = 0; i < 10000; i++) { x += i*i; } print x;
There is no *inherent* reason that a JavaScript version of this wouldn't run as fast as a Java/C# version or a C version. In all cases you recognize that i, x are integers, and do all the work using registers. This is apparent at compile time with C, and can be apparent at run time with JavaScript, using tracing or other methods.
I think you are mistaking the old slow engines for what is possible.
3. I agree that it shouldn't be forced, as I said. I was just saying that mocking JavaScript is out of line - it isn't something horrible and indefensible like VB ;)
"It's not worth doing something unless someone, somewhere, would much rather you weren't doing it." - Terry Pratchett
That quote is similar to the philosophy I apply to what I write.
I'd write something snarky about VB on my blog, but have not found a compelling reason- yet.
I agree with your thesis: Web technologies are not a good way to write desktop applications. (But I do think they're better than Silverlight/Air/Flex/JavaFX for many types of distributed applications - and that's after spending half a year writing a Adobe Flex application for my previous employer, which they're now rewriting in JavaScript.)
Mostly, I'm just going to quibble with some details:
First, let's not make "Web 2.0" any more meaningless than it already is. When Tim O'Reilly coined the word, he was talking about sites like Flickr (which was not desktop-like in any way) and the fact that they aggregate contributions in a way that makes them worth more than the sum of their parts. In other words, Web 2.0 was about how sites interact with networks of users, not about how applications draw content to the screen. The big "Web 2.0" hype started five years ago, when Firefox was at version 1.0 and before "AJAX" was even called that. Let's find a new buzzword instead of endlessly recycling this one.
1) Decompiled JVM or CLR bytecode is just as "open source" (i.e., just as useful to your competition) as de-minified JavaScript.
2) Just look at the history of optimizing compilers for Lisp and Smalltalk for proof that dynamically-typed languages can be just as fast as statically-typed, when they have big industry behind them. The past years' optimizing JavaScript VMs have already produced a 5x-50x speedup, and they're just scratching the surface. Check out these talks by Steve Yegge (who is now working on server-side JavaScript at Google) for more of what to expect from next-generation JavaScript compilers:
http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html
http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html
Also note that ECMAScript dialects like ActionScript already allow optional type annotations, and this could also be true of JavaScript 2 (ES 4, or whatever they decide on).
3) I agree that a platform with multiple languages would be much better. I'm looking forward to Mozilla IronMonkey, which will allow IronPython and IronRuby (and probably other .NET languages) to interoperate with Mozilla and Adobe's "Tamarin" ECMAScript engine.
4) Check out Mozilla Bespin if you want to see the "all Canvas" version of the future today. But I think for most projects Canvas will remain just one tool in the toolbox (just like you wouldn't write a .NET application with just one Windows.Controls.Canvas). For the type of markup-driven layout and animation you're talking about, the CSS3 Animation module (already supported in desktop and iPhone Safari!) and SVG (supported by every current browser, if you include VML translation libraries for IE) are the way forward.
FN1) Actually, I've worked in groups that use Sharepoint and groups that use Google Apps. The big difference is that Google Docs actually gets used for real live collaboration, not just as a shared archive or a slight improvement on passing documents around by email. Google Docs is also way simpler to extend via third-party APIs. And yeah, it's not as great for complex content creation as something like Keynote and Pages (or even Powerpoint and Word).
Web 2.0 was never alive. The web has never had a version number. Nor has "desktop," so PLEASE don't start that silliness.
In any case, while I agree with the problems, but I don't really agree with your solution. HTML, Javascript, and CSS are incredibly annoying. Fortunately, on the server side we have PHP, ASP, Python, Ruby, Perl, and whatever Google just invented five minutes ago and hasn't told us about, so I can imagine there are people working on porting these to the client side.
Yes, Silverlight and Flash are more effective client-side solutions, and I love using them (and by "them" I mean Flash, Silverlight's not my favorite), but their proprietary nature makes it difficult for people without corporate backing to create new systems for viewing the web. Any open source reverse engineering projects of these usually end up quite a few versions behind (i.e. Moonlight). At the very least, the technology should be an open specification; implementations can be as proprietary as anyone likes.
Keeping the web apps themselves proprietary is very possible already if they're mostly on the server side. This is probably where things will be entirely in ten years, with remote supercomputers in "the cloud" handling complex tasks and personal computers will be low cost, low power "terminals" fast enough to handle input, output, and Internet. Until then, judging by how things have gone so far, I get the feeling efforts by Mozilla and/or the W3C to get open specifications like Python or Ruby to run client-side will fare best.
That's not to say that I think any client-side solution will get very far at all. HTML/JS/CSS/etc. have taken long enough to (sort of) get agreed upon by everyone. By the time something gets agreed upon that can run on Windows/Mac/Linux/WinMo/iPhone/Android/webOS/UNIX/PS3/Wii/Augmented reality goggles, we'll already be able to render Crysis on the server side and play it on a phone, not to mention all the processing a web app needs.
So, my proposed solution is suck it up and wait for a long-term solution. Or work on said long-term solution instead so it'll arrive faster.
@Zacqary: I also think Web 2.0 is a ridiculous term. My coining of the Desktop 2.0 phrase was VERY much tongue in cheek.
Interesting post. One thing I will say in defense of javascript is it can be minified and obfuscated.. which is somewhat similar to compiling it. Obviously, it can expanded back out very easily albeit without comments or meaningful variable names.. which will get you about the same thing you'd have if you decompiled a java class file or something similar.
I agree with you too. I dont think the web will replace the desktop anytime soon. And you may have used the wrong impression (open source), but you are right, everything written in Javascript and HTML is easily viewed by the user, even if it is obfuscated.
Post a Comment