Fog Creek Software
Discussion Board




so after the api wars, what have we got?

Now it's the Browser (HTML/CSS/javascript/Dom) against Virtual Machine (Java/.NET/(Flash ?))

The custom made interpreter vs. byte code interpreter + Big Native Support library.

Anyone is betting on the outcome? Who wants to be the bookmaker?

Michael Moser
Wednesday, June 23, 2004

.. and the aim of the war is to become the predominant client platform, a war has to be about *something*.

Michael Moser
Wednesday, June 23, 2004

The virtual machine appears to be the way to go on the server side (J2EE, ASP.NET) which is serving applications to a browser-based client side.

Ultimately, for sanity sake, I see a unification of the client and server-side technologies.  The browser won't be taking over the server (although Netscape tried that back in the day with server-side Javascript) so I think VM technology will eventually take over the client.

Almost Anonymous
Wednesday, June 23, 2004

There's nothing native about JavaScript, DHTML, SVG, a DOM, or XML. Indeed if you stick to the standards the platform is, in effect, a virtual machine.

Regarding the whole ".NET is going to take over once they get XAML figured out" (This is not your point, but rather has been hashed out countless times elsewhere), I'd point to Java as a historical lesson - the Java runtime was on virtually every PC, has tremendous benefits over .NET (it enables you, or your company, to choose virtually any platform as they all have Java runtimes), has "one-click deploy" technologies, yet still it has been largely relegated to the dustbin of history on the client end. I think the .NET extremists (living in their caves) should ponder that long and hard, because ultimately they are missing why we moved to web apps. [As an aside - XAML, from everything I have read, is nothing more than a precompilation step - the compiler takes the XAML and builds the GUI elements and connects the events and code accordingly. How this aligns rich clients with web apps is an absolute mystery to me...]

Dennis Forbes
Wednesday, June 23, 2004

I think they will both win in spaces most relevent to them.

Flash / VM etc will win on sites that are on-line brochures and games, ie all the car sites and the like, any site that is trying to "build a brand, give the user an on-line experience", and html will win for news sites and sites where content is the primary reason for visiting...

I think this also applies when you think about the coming mobile revolution (for want of a better description), the content driven sites will have their text only xml etc versions and the "brand experience" sites will have mini movie clips and mini flash players...

Giles Gregg
Wednesday, June 23, 2004

Virtual Machines have been around since at least the sixties, and they have been getting faster and more powerful the whole time.

Browsers are VMs, .Net runs on a VM, Java runs on a VM, Python, Perl, and others all run on VMs. Some C/C++ will be around for low-level stuff like device drivers, writing VM interpreters, and operating system kernels, but that's about all.

I don't see native code for most application software because the only advantage it has is speed and that's not going to be true (or enough better) for much longer.

Tom H
Wednesday, June 23, 2004

Oop, didn't mention web apps :-)

same thing though.. the technology that best suits the purpose of the application will win out...

collaberation tools - html

video editing - windows api

small games - flash..

you get the idea...

Giles Gregg
Wednesday, June 23, 2004

Isn't the browser a VM, though admittedly a really poor one at that?

Just me (Sir to you)
Wednesday, June 23, 2004

Of course x86 on any modern processor is just IL running on a VM...

Dennis Forbes
Wednesday, June 23, 2004

"Virtual Machines have been around since at least the sixties, and they have been getting faster and more powerful the whole time"

Well, no.  The hardware has.  The software is more bloated than ever.  Moore's law will never outpace software developers ability to negate the gain.  It reminds me of something Philip Greenspun said about comparing the early years of web serving to today's.  Something like in 1995 we struggled to get 10 pages per second on circa 1995 hardware and today in 2004 with our app servers and frameworks to be fashionable we struggle to get 10 pages per second on today's hardware. 

Yes you can argue that productivity improvements by not managing memory are important.  This is probably the most important in business software.  If you are writing apps for home user or some such they want the quickest apps they can get on that new 3ghz machine.  Granted the computer is usually waiting for them not the other way around. 

If I make an app and you make an app, but I chose a slow ass swing ui and you do something native in a compiled language, all other things being equal the user likes my app better than yours.  Speed is a selling point for ISV's more so than their coder's being able to turn out a product marginally quicker.  The ISV will put more monkeys on the project to get it out to market quicker.  The key is to have the faster product out quicker or by the same time as the slower one.  If you can do that, you will eat the slower ones market share.

Why do I like office over open office?  Speed, not features.  There isn't anything in any version of office that I need that open office doesn't have - BUT open office is too slow because I'm used to the speed of office.

Software Assurance
Wednesday, June 23, 2004

"being equal the user likes my app better than yours"

should be "being equal the user likes YOUR app better than MINE"

Software Assurance
Wednesday, June 23, 2004

"Why do I like office over open office?  Speed, not features.  There isn't anything in any version of office that I need that open office doesn't have - BUT open office is too slow because I'm used to the speed of office."

You made your point, loud and clear. What you are basically saying is that choice is good and empowers the user. Should we jump in the latest bandwagon just to help out a vendor? Is it in our best interest to do so? Choice: live by it; die by it.

Dewd
Wednesday, June 23, 2004

Swing isn't that slow.  JVM startup time is slow.  If your Swing interface is slow after it's been started, you're probably doing something wrong.

I'm happy to hear that speed is the only thing keeping you from Openoffice, though -- I happen to be working on OO performance at the moment.  :-)

X
Saturday, June 26, 2004

*  Recent Topics

*  Fog Creek Home