Java is short for JavaScript. Not!

Here’s  is a quote from the About page  of the Web site ehow.com: “eHow is your one-stop online resource for life’s challenges. Professionals in every field come together to offer expert advice, backed by the additional support of a can-do eHow community.

Experts are also human beings and sometimes they make mistakes too. But when I’ve read the following article I was stunned:

javaisjavas

Guys and girls, I’m not an eHow-grade expert, but I’ve been doing both Java and JavaScript for while. Trust me, the above description is absolutely wrong! Please ignore. Also, if you know any of the 35 people who found this helpful, get in touch with them and tell them the truth!

There is well known statement that “Java is to JavaScript as ham is to hamster”. So I’m looking forward to a new article at eHow that will be a creative interpretation of the Wikipedia definition:

“Hamster, aslo known as ham for short, is processed pork foodstuff, which undergoes preservation through curing, smoking, or salting. Hamsters are traditionally made only from the hind leg of swine, and referred to that specific cut of pork.”

HTML5 book. The Eplogue. Take 2.

Even though this book is about HTML5, the authors would rather work with compiled languages that produce applications to run in virtual machines. Such software platforms are more productive for development and more predictable for deployment. While writing this book we were often arguing about pros and cons of switching to HTML5, and so far we are concerned that the HTML/JavaScript/CSS platform is not ready for developing of the enterprise applications just yet. We live in the era when amateurs feel comfortable creating Web sites and that JavaScript provides flexibility and customization the Access and Excel provided in the old good PC times.

Till this day Microsoft Excel is the most popular application among business users in the enterprises. They start the application locally, it has a local storage that enables work in the occasionally-connected scenarios. Both the data and the code are physically located close to the user’s heart. Microsoft Excel allows the users to have her own little pieces of data and amateurish-but-working-code (a.k.a. formulas) very close and personal. Right on the desktop. No need to ask these IT prima donnas for favors. No dependencies on the connectivity or some mysterious servers being slow or down. The most advanced business users even learn how to operate MS Access database to further lessen the dependency from IT.

But there is only so much you can do with primitive tools. Visual Basic was “JavaScript” of the nineties – it had similar problems, but nevertheless had huge followings. Now the same people are doing JavaScript. If we don’t break this cycle by adopting a common to all browsers VM, we are doomed for going through the generation after generation of underpowered crap.

Recently, one of our clients from Wall Street sent us a list of issues to be fixed in an Web application that we were developing using Adobe Flex framework (Flash Player was the VM, where this application ran). One of the requested fixes was “remove a random blink while a widget moves in the window and snaps to another one”. We’ve fixed it. You may argue that Flash Player as any browser’s plugins are going away. But the bar set by Flash based enterprise applications is set pretty high. We hope that future enterprise Web applications developed with HTML6 will raise the expectations in the user experience area. The time will come when HTML widgets won’t blink in any of the major browsers.

We wrote this book to help people with understanding of what HTML5 applications are about. But make no mistakes – the world of HTML5 is not a peachy place in the future preached by educated and compassionate scientists, but rather a nasty past that is catching up bringing the mob with it.

It’s a past and it’s the future. The chances are slim that any particular vendor will win all or even 80% of the market of the mobile devices. In competitive business, being able to make an application available ONLY to 80% of the market is not good enough, hence the chances that any particular native platform will dominate in the Web developers are slim. HTML5 and related technologies will serve as a common denominator for mobile developers.

The authors of this book have more than 100 years of combined experience in development of enterprise applications. Over these years we’ve learned that the saying “Today’s on Wall Street, tomorrow on Main street” works. IT departments of financial companies are very pragmatic in selecting tools for development of their software. Especially, we’re watching the platforms used for development of financial trading applications – they must be fast, reliable, and any delays in processing or clumsy UI may lead to substantial money losses. Besides, the development cost dramatically increases if an IT organization sets a goal to offer their trading application to the entire mobile market, which is a moving target today and will remain the same in the foreseeable future.

Check out the trading application tradeMonster. It has been developed using HTML5 and uses the same code base for all mobile devices (they use Flash Player in the desktop version). Yes, they have created native wrappers to offer this application in Apple or Google’s application stores, but it’s still an HTML5 application nevertheless. You can create a paper trading account (no money is involved in trading) and test their application. If you like it, consider using HTML5.

Enterprise IT managers need a cross platform development and deployment platform, which HTML5 is promising to be. Take with a grain of salt all the promises of being 100% cross-platform made by any HTML5 framework vendor. “With our HTML5 framework you won’t need to worry about differences in Web browsers”. Yeah, right! HTML5 is not a magic bullet, and don’t expect it to be. But HTML5 is for real and may become the most practical development platform for your organization today.