Another article with Cathy Title but No Meat. The author of this article clearly does not understand JVM or what it does and how much it helped in the whole 'WORA' movement. James Gosling is the real hero, thanks for giving us JAVA.
OP here. James Gosling is actually a hero to me. I hold him up there with Dennis Ritchie, Jim Gray, and Anders Hejlsberg. He had a bold, bodacious technical vision and he moved heaven and earth to make it happen. Great things have happened as a result. Billions of $ have been made. Many developers learned to program with a language better than C++ to learn on. Much of his original thinking has inspired others to do more great and bodacious things.
However, his creation also created a faulty mindset. He encouraged that mindset. I know he didn't actually coin the term, but I was around and I heard him speak. He toed the party line. Using his name is relevant to this discussion because, I believe, it highlights the problem: The "write once" approach is faulty because it started with an application of technology, not the customer.
Sorry it is not clear. I tried to express it but obviously didn't do it well enough. Here's another try:
The best products in the world are those created by organizations that start with the customer. Everything they do starts with customer needs, pains, desires. They work backwards from that. Eventually they decide what tools & technologies to use to deliver greatness to the customer.
Write Once... encourages a mindset that doesn't start with the customer, but with a technology. Instead of focusing on the features & capabilities that matter the most to the customer, the focus is on something like HTML5 (or Java).
The best products result from focusing on really delighting the customer by doing a few things really, really well. Given mobile platform fragmentation one axis where this is critical is what platforms to support initially. WORA (esp HTML5) leads to a mindset where it's important to get the experience running on many devices simultaneously; the 'focus' is on doing a crappy job across many things.
I'll repeat what I said in the article here: I don't hate HTML5. I code HTML5 almost every day. The product I launched on Monday makes heavy use of HTML5. But only because our customer value proposition led us to the need to build a website, and we had capabilities that needed to be highly interactive. HTML5 is a great technology that addresses this.
The summary: If you must target multiple platforms, focus on the experience; then try to get code re-use. Don't do it the other way around.
I agree in some parts with you but I think you would make your points much more forcefully if you point to exact technical points where Java got the level of abstraction wrong and where going direct to metal would have been better.
Two problems here worth calling out: even when the forms packages worked, they produced apps that looked like crap. HTML is worse in this regard, you get poor quality mobile apps (imagine if your app needs an interactive map...JS maps are terrible in mobile browsers), and you have a bunch of places where JS/CSS/HTML/XHR differs b/t browsers and it's painful to get them all working.
Second problem, at least initially, I'm sure it's better now, was JVM implementations in the mid-90s were not super consistent and you'd run into runtime issues that were difficult to work around.
Are you arguing WORA with Applets worked and moved the industry forward? Flash pretty much took over this charter but even then getting performance on many devices out of a Flash runtime was pretty damn hard, so even it fell down on this.
Much better to have a shared core (if you can) and write customer-centric, awesome device-native UI experiences.
I think some abstractions are more enduring than others. At one point everyone wrote assembler, then C came along and offered a write once and run everywhere. It so happened that C nailed the performance / expressiveness efficient frontier and created a world where people arent writing assembler anymore.
The question I find interesting in this context is - is it possible to write a rendering pipeline and UI toolkit all the way down in a garbage collected language that is performant. It appeared that we in industry have taken a step back and are now content with the bottom layer being all native. I dont know if its because the Sun UI team didnt have the right people or if the abstraction of a garbage collected high level language does not scale down to writing graphics apis.
- Java Enthusiast