OSNews

The article was interesting. I am sure some of his points were valid and perhaps some of his predictions will be as well.

Not sure what else to say about it tho'.

RIA indexing? I am sure ideas are being worked on now... a way to expose the applet content to search engines. I don't know... I guess wait and see how things pan out. HTML will not go away any time soon, either.

The article is a little too wordy and its points could be summed up in a piece a third of its length. The writer is subtle but insistent on painting html as outdated, boring and not "cool", but the truth of the matter is that html is the very heart of the web.

This does not mean that the means by which we build html will not change to make easier or that html itself will not change to accommodate needed features, but by and large the web remains a library of interconnected "books" and "pages", which by design must be simple and viewable in a host of devices and platforms.

To me, proprietary technologies like Silverlight and Flash introduce more problems than they solve. First and foremost, they are proprietary, slow and their wider acceptance would turn the web into a series of private channels controlled by a very small number of companies.

HTML is far more democratic and is a format which will continue to evolve, but whose simplicity is the reason why it has done so well.

Every so many years those companies that are slowly becoming irrelevant need to remind us how important their proprietary technologies are. While a few years ago, I couldn't do most of my work exclusively on the web, today I can, and that is a testament that those who bet on a web-centric future are essentially correct.

Nice article Thom, but you could use some less words

It's an interesting POV, and as a programmer, the sole mention of HTML+JS-based desktop applications gives me chills.

Let's see how your crystal ball fares

I agree with some others, this could've been said in one page. But the article is interesting. One thing I think the author doesn't get: the other things Google does, besides search, aren't just to fool the investors and increase the stock value. They want to create a huge ecosystem where everything is connected. This will increase their add revenue, and ensure ppl use, know and trust Google. Some of these things don't make money? Sure, and some never will. That's the risk of innovation - they have a clear strategy to innovate, and are willing to take that risk.

If I understand the crux of the argument in this article is that google released chrome to protect itself by encouraging developers to use html and js...

They could have waited for mozilla's new js engine (which is already in FF 3.1 alphas) which supposedly is even speedier than v8, this would have saved them a whole load of effort and would have done the same thing (at least if following the rationale of this article)

XAML can be indexed very easily, swf is more difficult but google already accomplished it. We can't really index java applets, but nobody really uses them anymore for anything outside of intranet or private webapps.

The reason people aren't using them is that they are inherently still a box on a page, and that goes directly against the web paradigm. Until they can leverage the back button (with everything that entails), they will only really be appropriate for rich widgets.

Javascript is ubiquitous, and with a good engine can easily rival what any RIA can currently accomplish. More importantly, it does not break the web paradigm, and fully integrates into the existing technology.

Case in point, go to http://280slides.com/Editor/ on chrome.

Edited 2008-09-09 18:57 UTC

Don't take my word for gospel, but I have other thoughts on why Google releases Chrome...


1. Google is "omni"present. If you surf the web, chances are pretty darn high you hit a google ad. They don't need a browser for that, and infact, the browser doesn't force Google search on you in any way.

2. Several Norwegian newspapers use google maps to show the location of events. I'm pretty sure they pay for that usage. Google maps is free for "end users", simply because that increases awareness and spreads the application.

3. A *very* good reason for Google releasing Chrome is Android. Infact, I suspect that's one of the two main reasons they released it (and has x86 and ARM instructions in the V8 source). The mobile browser market will continue to grow, and grow a lot, in the next few years. Google would be stupid not to take a share in that. The other reason I suspect is making (Googles) webapps faster and more stable.

4. There's a number of reasons for Google using WebKit instead of writing their own. WebKit is well-suited for mobile use (unlike gecko), and is easy to program. They have already released tons of modifications back to the community. They win, and we win. Isn't that good enough?

5. One reason for Google to use JavaScript is really simple. It Just Works (tm). Really. It might be buggy, slow and insecure, but Google is working on that too. JavaScript is a language that is supported by almost *any* browser, unlike Silverlight/Flash/Java/.Net/etc. Google wants to be able to reach *all* of us, not just a few.

6. Google Gears for disconnected apps is great. Not so much for the desktop, as for Android. Need application X? Go online, fetch the necessary app, disconnect, work.

... and that's that HTML and Javascript are "inferior" to RIAs.

For one, I have more lock ups and browser crashes caused by Flash (or Silverlight), than with HTML/JS/Ajax. In fact, I never have browser crashes due to HTML/JS/Ajax. But Flash can really suck up the CPU like there's no tomorrow, especially with sites that are all Flash based.

Two - speed. In my experience, HTML/JS/Ajax based sites are much faster than Flash based ones. For every change in page on a Flash based site, there's a big-ass, slow download. With HTML/JS, it just goes to the next page.

Three - ease of development. HTML is not good for presentation. But that's what CSS is for. Any half way decent web developer will use CSS to control presentation, and just use HTML for anchors, and then Javascript for dynamism (and Ajax calls). And add to that the plethora of open source Javascript/Ajax libraries (Dojo, Prototype, JQuery, YUI, etc). These libraries make JS development much easier, and they abstract away the pain of browser incompatibilities. And for Flex or Silverlight development to be truly easy, you need their respective very expensive tools (Flexbuilder, Expression Studio). With HTML/JS/CSS/Ajax, there are tons of both free and for-pay tools out there.

Four - ubiquity. While Flash has gotten fairly ubiquitous, it's deployment is uneven across platforms. HTML/JS/CSS/Ajax will work anywhere there is a browser.

Five - if you want traffic, you gotta get good indexing with Google (and others, but mostly Google). HTML/JS/CSS/Ajax is very easy to index, and Google (and others) has it very highly optimized. Sure, MS might do some sort of RIA indexing (particularly with Silverlight), but it will never reach the effectiveness of HTML/JS indexing.

Six - as was already said, HTML is democratic, and fully open, and not controlled by one company or entity. When you go Flash/Flex, you're at Adobe's mercy, when you go Silverlight, you're at MS's mercy. At least with Java, it's GPL'd and there is the JCP. But HTML, Javascript, CSS, and Ajax are all open.

Seven - Javascript is actually a nice language, with full OOP, Functional programming support, RAD, big libraries, and a familiar syntax. It's only pain has come from inconsistent browser implementations, particularly inconsistent implementations of the DOM. But all browsers are becoming more and more standards compliant, and the aforementioned Javascript libraries do a good job of abstracting out the inconsistencies. Besides, to those that think developing Flash is so awesome - it uses ActionScript, which is based on ECMAscript, which is also the basis of Javascript.


So, I have to say, I'm not a big fan of RIAs (Flash/Flex, Silverlight). I really don't like Flash based websites - I find them really slow, and huge CPU and memory hogs, and they don't behave well. Plus, Flash is so badly over-used, and used heavily for stupid, annoying advertisements (I love the FF extension FlashBlock). The only things I like Flash (and Silverlight) for is movies, music videos, kid games that my daughters play, and YouTube. But for regular web sites and applications, I'll take an Ajax based site any day.

And because of that, I love Google Chrome, and the fact that it's Open Source (BSD license), and can easily be copied and extended.

Thats good, because it will extend the live of the democratic web, and avoid the proprietary lock-in web channels of RIAs.

The long article, and my long post , both failed to mention the new V8 Javascript VM, which has incremental garbage collection, and compiles to machine code.

So with V8, and Mozilla's TraceMonkey, Javascript goes from simply running in a browser embedded interpreter (that's where the slowness and bugginess comes from), to a full VM runtime environment, that's safer, less buggy, less memory consuming, and much much faster.

The popularity of Ajax techniques has helped Javascript shed it's "toy" language reputation a little bit. Full VMs like V8 and Tracemonkey will make that reputation dead and buried.

At first, thanks for taking the time to write that article. I found a lot of conclusive threads.
I do not agree however on your conclusion about the feasability of indexing RIAs.
Javascript or Ecma-Script or ActionScript or whatever name a derived interaction oriented language will have fills the role of a modern basic.
Underestimated by many, way too tolerant as a programming language and burdened with the lack of IDEs.

Building a RIA today on the other hand, definitely does not involve HTML as a markup language. Starting with HTML and pimping it with interactive javascript methods will die a sudden and painful death.

Providing content to be indexed on a large-scale (to bring light into the so-called dark web) is easy enough for everyone that actually cares. Standards for semantically based markup of pure and simple data are plentiful.

So what's missing? The right budget in the right hands.

Money is a key driver for complex web based projects. And in most cases its motivated by means of marketing or reaching out to masses.
That's where projects are forced to either compromise in technology and implementation or semantic content.

Google has not much to fear but itself at the time being. When trying to make a strategy out of its tactical moves, I see a playful, curious and un-egoed business entity. The strong hold, if not monopoly, in the online-ad industry waits to be succeeded by the next big online-business. But without trying everything possible within the ressources, finding that would be by chance. By diversing and experimenting with every possible technology, Google tries to buy as much lottery tickets as possible.

But even if it increases Googles chances to win, it doesn't necessarily decrease everybody elses chances.

I take that as a good thing.

RIA or plain HTML - or whatever - I don't care, as long as it is based on open standards and fair play and doesn't bury the real useful web content under some useless non-standard proprietary gimmicks that add nothing useful to the real content but often do more harm actually.

Internet today is what it is because it is still mostly based on open standards - like HTML. It would be a nightmare if we didn't have HTML and JavaScript but only some competing proprietary technologies like Flash and Silverlight instead.

I don't get your point. I could understand that, if you are, for example, an ambitious and talented web developer, you might like to develop technologically advanced web sites using the most advanced technology out there that makes the work easier and funnier. But you should probably calm down a bit and look at the Internet from the point of view of an ordinary Internet user, not from the developer point of view. Most useful web content online is still just plain textual information.

(X)HTML and databases - plus PHP or something similar - are often all you need to make information easily available online. Flash? Does someone really need it - besides of advertisers?

How many times have you been frustrated with those supposedly advanced flashy websites that didn't work correctly?

If you ask me, there are still all too many web developers out there who want to put all sorts of blinking lights, whistling bells, mooing cows and other such "rich Internet applications" (ok, I admit: kids might find those mooing cows on your website very amusing and might not even look for any more serious information) to their websites instead of concentrating on making the real (usually textual) content easy to find and use - and all too many ignorant customers buying such flashy but often unusable web design.

There are good reasons why the "interface" of a book (a paper book) has stayed the same so long. It does its work well. No need to add a button with a blinking light or even a grip to a book to make opening and reading it easier. It can be a bit same in web design.

Of course RIA does have lots of useful potential, but often the KISS principle is worth keeping in mind too.

Edited 2008-09-09 22:29 UTC

There is one point to be appreciated in the HTML+JS solution, when compared to Flash/Silverlight/Java Applet. And that is "right click -> view source", which is an immensely more profound statement than "right click -> flash player settings".

Although no longer completely true with all this recent minify/obfuscate frenzy, I think it's still a fundamental example of openness. As search engines are probably better at indexing html+js rather than swf, so are developers. It is text, you can read it. You can learn from it. I don't have numbers but I bet countless current web developers refined their skills by looking at the code of some other site. And this is a self sustaining behavior.

And even if Chrome doesn't succeed in getting a reasonable market share, it will still push existing browsers forward on the html+js path, ideally on a convergent path, hence saving developers (both in Google and outside) countless hours to support an app for 5 different DOM implementations. As someone else said, js is not bad, the discrepancies between current solutions are.

Regarding the unlikely availability of a Chrome+Adblock solution cited in the article, I still don't get why. If the code is open, what is preventing any developer from forking it and implementing such solution?

I don't think there's any danger in Flash/Silverlight becoming the dominant RIA tool. Why?

1. Developing XHTML/JS solutions is now and always will be completely free. All you need is a text editor.

2. XHTML/JS solutions are intrinsically cross platform.

3. Website visitors do not need to install any tools or VMs.

4. There are so many university courses and online tutorials and books covering javascript development (in conjunction with ruby or php) that there's just no way it's going anywhere anytime soon.

5. Search indexing and positioning is critical, and it will be *very* difficult to provide efficient indexing of Flash/Silverlight that does not give the developer of the RIA the opportunity to spam the hell out of the search engines. Google struggles enough with stopping blackhats injecting keywords into non-visible areas of pages, imagine how hard that's going to be to detect in the likes of Flash! And until it's nearly impossible for developers to spam like that, Google will have little trust in the indexing of those movies. Besides, as they say, content is king when it comes to SEO, and by content I mean just text.. lots and lots of good quality text. Why would you put 10,000 words of text in a Flash movie? You wouldn't, so HTML will still be used for good indexing, as text markup is what it was designed for.

No, the biggest challenge that's presented to web developers wanting to provide an application "service" is data access and ownership. When you use Google docs, who owns the data? How do you give users the guarantee that they will always have access to their data, and portability of their data between one service and another? Right now, there's no such peace of mind that I'm aware of, and I'm waiting for some kind of popular "open data" initiative, where *your* data can be easily shared between services (imported, exported, backed up, whatever). Once users have that, one of the biggest and legitimate concerns for the use of web apps will be removed.

I agree with others here that Chrome and Gears are more about Android than anything else. The mobile market is still very volatile and there's plenty of scope for Google to come in and be a major player, thus giving them a new market. And actually, I hope they have great success, as I'm just not sold on Symbian or Windows Mobile, and I'd prefer to have more freedoms on something I own than what Apple is ever going to grant me.

You're not good with simple numbers.

Very good article - and I don't mind it's length.

The best on it is the discussion following it. While nobody knows what's the future, we all know what and how to consider now.

I'm SEO, so I know and don't underestimate the importance of indexation in HTML success. But there is a huge other important factor to be considered. HTML and JavaScript ARE Open Source. They don't have a license but once they are released everybody can see their code so it becames impossible to track who copies what. So if expedia has a new cool visual effect, it is implemented all around in no time because everybody can see clearly how was it done. That is not happening in java-flash or silverlight. Any programer with a cool effect in java will submit it precompiled. And flash swf is precompiled by default.

I liked the article very much. I also read all comments here, and I have to say, that while proponent of RIAs, I can understand why ppl prefer html, css, js, ajax methods of development.

But - I would not fear RIAs, really. You need a plug-in? So what? If that exists for your platform set-up, it is going to be downloaded rather quickly. I would like to point out, that some js libraries are bigger than REBOL itself :-)

IOW, what author describes almost exactly matches Carl Sassenrath's (AmigaOS, REBOL) opinions 10 years ago. Not those about Google, but those about better technologies for the Internet.

Pity we are so slow, but once R3/View is out, the world will see another RIA, cool one, under 1MB of code. In fact, REBOL was even first RIA - back at those times, when Flash was used only for advertisements.

If Google is looking for the competition for Flash and Silverlight, they should buy REBOL Technologies :-) Of course we have another ones, as Runtime Revolution, Curl, but those are much much bigger, and not so much better. REBOL language has much deeper thoughts for RIA age than anything I saw so far ...

A sidenote on the mentioned 7.2Mbit/s wi-fi connections. In Sweden a government agency is now investigating if the alleged speed is false advertising, since the possibility of reaching speeds that high is practically impossible even if you stand next to the transmitter.

I learned three things from this article.

The first is that the author really doesn't like Javascript (though it seems to be more than acceptable as long as it's called ActionScript). Not sure why really. It's basically LISP with C syntax. The problem has always been the runtime. But with the likes of V8, TraceMonkey, and SquirrelFish, this will soon be (and as far as I'm concerned already is) a thing of the past.

The second is that the author believes that Google has some grand scheme in mind with its project releases. Possibly, but I think it's far more likely that Google is like a hackerspace with money to burn on anything that strikes them as nifty. Google makes its money by drawing attention to itself, and as long as it keeps doing things that result in such, the goose will continue laying those chrome eggs.

Finally, it appears the author has never actually thought about how an RIA gets indexed. Google may use hyperlinks to sort search results, but the only thing it actually builds indexes on is TEXT. An HTML RIA is not a 'text document' however (don't be pedantic, you know what I mean in this context ), and most of the time it makes no sense to index it as such. And PageRank is rendered useless because it makes no sense in the context of a RIA.

So there's no real reason for Google to stick with HTML for RIAs other than ubiquity. In fact, I hope that SVG support is not far behind, and I myself am working on a project that uses Google's V8 and OpenHand's Clutter. The key problem with RIAs have been one of quality, and so far the available tools, platforms, and applications have for the most part just sucked.

...

Oh, and Google hates Javascript too, which is why most of their JS is generated by Java frontends (at least as far as I've been told)

As a developer of RIAs, I have quite a few rebuttals with many of the comments in the article. The author comments that Javascript + HTML is a poor platform and that there are many better options out there... frankly, applications that are written for Java, Flash, Silverlight are NOT inherently better or easier to maintain. The biggest problem up to this point with applications that are heavy with Javascript is that people with little application development experience have been using the language. The same can happen with any platform. Flash is a perfect example. A lot of people that write code for Flash are graphic designers or the like... people without real training in software development. What I find funny is that the author completely neglects to mention that Actionscript and Javascript have their roots in ECMAScript... the core language is the identical. Right now, the slowest thing about Javascript in the browser is DOM manipulation which is constantly being improved (well, it's constantly being improved by every browser but IE, but even IE 8 is better then past versions). Another reason for it's slowness is lack of threading/processes. With multiple cores being standard now, Javascript has no facilities to utilize more than one core. The Mozilla team is changing this though. Running background Javascript threads will be possible in the near future. People seem to forget why features like this are not yet standard though... it wasn't until recently that Javascript has needed to perform well. Only about six years ago, Javascript was basically for doing mouse rollovers, creating annoying pop-ups, form validation. Who need speed or multiple threads for that??? Now that the browser is getting some respect as a true development platform is there a need to improve performance. It's mentioned that JS + HTML is basically a "hack"... I would have to disagree; every language and every platform grows and changes over time. No platform is developed once, shipped, and the developers say "ok, that was perfect the first time out... no reason to improve it". The author also mentions that HTML + JS have poor security. In my experience, it has no worse security than any other development platform; it goes right back to my first point: if you have amateurs writing code you're going to get amateurs results. With a proper application architecture you can have a very secure platform, regardless of the development platform. Yet another issue that is a "problem" according to the author is applications with thousands of lines of unmanageable Javascript. I've written applications with many tens of thousands of lines of Javascript that are quite modular and highly maintainable. Again, it all goes back to having a proper architecture. Without a proper architecture for an application, it doesn't matter if it's written in C++, Java, Silverlight, Flash, or HTML + JS, the application will pretty much be doomed from a maintainability perspective. Something that often times turns off developers to JS + HTML is that, while Javascript superficially looks a lot like languages they are familiar with, it is significantly different to develop for in many cases. If a developer writes Javascript in the same way they write Java, the performance will likely be terrible, again perpetuating the belief that JS + HTML is a poor platform. Another argument that the author poses is that JS + HTML has not been able to keep up with the times, that it is "not able to cope with innovation" and uses Youtube as an example of this. This argument seems a bit ridiculous since EVERY platform has some kind of extensibility... the ability to link to external libraries, use some sort of external resources. In this case that external resource just happens to be Flash. There is no single platform out there that is the end-all be-all platform for development. The single biggest argument that I have a problem with though is that RIAs need to be indexed by Google. This particular argument is complete nonsense. An application in the true sense of the word really can't be indexed. Content is indexed, not an application. An application can contain content, but the application itself cannot be indexed. Even if the application is written in HTML + JS, the only thing that can be indexed is the content in the HTML, which if the application is mostly written in Javascript, there probably won't be much HTML to index. You really need a portal, a website, for the application, no matter what the development platform of choice is. Webcrawlers can read the contents of things like Javascript files, but they certainly can't comprehend them (well, Google's webcrawler can, but only to a _very_ limited extent). At best they can make use of the comments in the file. Most of the application's I've deployed have had _very_ little content in the HTML; what was displayed was usually dynamically driven by Javascript which used a combination of server database resources and XML or other configuration files. There really is very little to index. I have to say that from what I've read in this article, this author needs to back up and see the reality of the situation. Javascript and HTML as a platform is used because it's highly flexible, it's quite easy to reach a large target audience, and it's not nearly as complicated to develop or insecure as the author seems to think. As browsers continue to mature, JS + HTML applications will continue to grow, not because Google feels they must, but because it's no worse a platform to develop for than any other, and in many cases, it's a much better platform for specific applications.

On a side note, the author seems to think that the Mac platform is practically nonexistent. I think some people would say otherwise: http://arstechnica.com/journals/apple.ars/2008/01/01/mac-os-x-marke... current estimates put Mac market share between 8 to 10 percent. I certainly don't know about you, but it seems to me to be a bit foolish to think that having one out of ten people using a Mac as being a failure for the platform. I also find if a bit comical to hear the author state "And I'm sure Google carefully watched IBM and loads of companies (including Google itself) pouring tons of money into Linux just to have a 0.something percent share." While it's true that many companies have poured a lot of money into Linux, very few have made much of an effort in making it a desktop platform. Most for the money/effort spent has been to make it an excellent server and embedded platform. It wasn't until Mark Shuttleworth decided to make a serious effort in that direction that there has been any real movement at all. Keep in mind, that was less than four years ago. For Linux to even have 1% of the desktops out there at this point is pretty impressive, and OEM support only continues to improve.