Hawaiʻi's Technology Community

How a new suite of unencumbered technologies could elevate web development today and better prepare us for HTML5 tomorrow

The web development world is in an interesting place. HTML5 is the future, but its not quite ready. Javascript is the lingua franca of this brave new world despite the fact it lacks many basic features of modern OO languages and was never intended to be used for sophisticated desktop-like apps (think Google Apps.) Apple has accelerated the move away from plugin based RIA technologies such as Flash/Flex. In the iOS world that is increasingly dominating high end mobile apps you have two options - mobile web apps using a subset of HTML5 or native apps written with an antiquated language. The future of Java, the language of Android and millions of lines of server-side code, seems uncertain as a litigious Oracle increasingly looks like a suboptimal steward and pillars of the JCP such as Apache walk away. The only company with a high performance modern VM, solid standard library and support of modern OO and functional languages in the browser is...roll the drums...Microsoft!

Google - This is the perfect time for you to save the web from an icky future. What we need is a new standard, lets call it Plex, that provides a standard abstraction facilitating the use of multiple modern languages (OO, functional, etc.) with a standard library on everything from the cloud to the desktop to the phone. This may sound a lot like Java or .NET but a universal VM approach isn't possible, at least not at first, because these apps need to run on the server _and_ in the browser without the benefit of a plugin. On the client we need a GWT-like abstraction layer that, in the short term, cross compiles any Plex compliant language to HTML5 and Javascript - basically a GWT compiler with GCC-style pluggable front ends (i.e. languages.) Simultaneously a push should be started to incorporate an efficient intermediate language in the HTML5 specification so the Javascript step in the Plex compilation pipeline can be removed.

Plex should be designed to accommodate popular languages (Ruby, Python, etc.) in the future but out of the gate it should introduce a flagship language optimized for the Plex environment. "G" should be an optionally typed language supporting OO and functional models with all the goodies we've come to expect. It takes a lot of resources to write a new language, a new server and mobile VM, a new cross compiler for HTML5 and all the quality tools necessary to support development, but if anyone can do it, it's you. I bet your friends at the ASF and other former JCP members would be willing to help.

Views: 226


You need to be a member of TechHui to add comments!

Join TechHui

Comment by Daniel Leuck on January 2, 2011 at 4:14pm
I agree. Flex and Silverlight are the only options for certain types of RIAs today, but HTML5 is the future. I'm happy with the declarative parts of HTML5, but the Javascript-only aspects are very 90s. HTML shouldn't constrain the code-behind language for the DOM.
Comment by Les Vogel on January 2, 2011 at 2:52pm
There are a lot of folks who seem to think Flex is the next language.  I don't. I suspect that this is the make or break year for it.
Comment by Daniel Leuck on January 2, 2011 at 2:48pm

Have you looked at CoffeeScript?

Pat sent me a link to CoffeeScript in response to this post. I haven't tried it yet, but based on the examples it looks like a good example of using Javascript as an intermediate language.

Getting beyond this is hard.  If Google were to do something else, they'd need others to adopt it.  No one want's to help Google at this point. 

I agree. Its going to be hard, but if they got one or two other big players behind it, say Apache and another large corporate interest, I bet they could build momentum. The backlash from Oracle taking the reigns of the JCP could provide an opportunity.

Comment by Les Vogel on January 2, 2011 at 1:39pm

Have you looked at CoffeeScript?


ECMAScript was blocked by Apple/Google/MicroSoft.  Adobe donated Flash's implementation, but it wasn't picked up.  Hopefully someday.  


Getting beyond this is hard.  If Google were to do something else, they'd need others to adopt it.  No one want's to help Google at this point.  Not quite as bad as it was at one time w/ MS, but getting close.

Comment by Daniel Leuck on December 19, 2010 at 9:47pm

@Cameron Exactly.

@Eric I look forward to hearing about your work with Node.js. Its great to have another robust scripting option on the server. V8 compares very favorably to the flimsy reference counting interpreters used by many other popular scripting languages.

As someone who has worked (and is currently working on) language and interpreter design, I can attest to the fact there is no golden hammer. Javascript, due to its highly dynamic nature, does not have the same performance characteristics as statically typed languages such as Java and C#. The V8 engine makes it much faster, mostly by analyzing JS code to find ways to treat it like class-based Java, but you won't find any implementations of, for example, HBase, the Java distributed columnar database designed for use over billions of records, implemented in node.js anytime soon.

That being said, I think node.js is interesting and I expect people will find a wide range of uses for it.


re: Oracle's legal attack on Android's Dalvik VM

We can only pray they lose. A victory for Oracle would have far reaching implications for VM-based mobile platforms because the patents they cite in their lawsuit (5966702, 6910205 and RE38104) are dangerously broad. When I say VM I'm referring to mobile virtual machines in general, not just Java VMs.

Comment by Cameron Souza on December 19, 2010 at 4:41pm

I think what Dan is saying is that HTML5 (or 6) should stop dictating the language used to interact with the DOM. It should specify an intermediate language and let developers choose the language they use for client-side programming. Because this isn't possible right now, Google could provide a way for other languages to be easily translated into Javascript the way GWT does for Java today. In other words, for now, Javascript is the intermediate language.

In general, I don't think Java developers find HTML5, CSS3 or Javascript particularly difficult. Its not a question of difficulty. HTML5 and CSS3 are good standards that perform their job admirably., in its current form - not so much :-)

Comment by Eric Nakagawa on December 19, 2010 at 3:28pm

The current HTML5/CSS3/JS is a challenging shift for folks who have tied their careers to Microsoft/Java. Though I think Microsoft will soon introduce their .Net language updates in due time (if they haven't already). I'm curious if Google has a vested interest in guiding the HTML5 spec to additional languages used (aside from say Python) or expanding the functionality and scope of the V8 engine (already heavily tuned to JS).

For Google their V8 engine already fulfills points #2 running on server, desktop, and mobile. I do wonder what Google will do to de-link from the Java liability on the Android platform... perhaps V8 + HTML5.

Personally: I have currently shifted focus and development into Javascript on both front-end and back-end (node js). I've drank the kool-aid.


Time to shift to ECMAScript?

Comment by Daniel Leuck on December 12, 2010 at 7:47pm

That's not what I'm suggesting. Perhaps I've obfuscated the gist of the post by conflating three goals:

  1. To allow other languages to compete with Javascript as the "code behind" language for HTML5. To do this, they need direct access to the DOM without the need for a plugin. In the short term this can only be accomplished by converting the code to Javascript the way GWT does with Java. I'm suggesting creating an abstracted GWT compiler that would allow people to write language providers, much the way you build .NET languages today, that act as front ends for PlexWT. In the long term it would be ideal for HTML to specify an intermediate language so the convert-to-javascript stage could be removed.
  2. To provide a high quality modern VM without any legal baggage that can be targeted by multiple languages. Variants of this could be provided for server, desktop and mobile use as has been done with Java and .NET.
  3. To provide G as a reference language that takes full advantage of the new platform. Microsoft did this with .NET and C#. Although the platform was designed for multiple languages from the beginning, C# was introduced as a reference language that fully exploits all the features of the runtime. That didn't stop dozens of other languages from targeting the platform.
Comment by Seth Ladd on December 12, 2010 at 6:57pm

I agree in principle, but I think trying to create the "one, true OO language" would be a waste of time.  As desktop and server development has taught us, one size does not fit all.

I do think that we should push hard for something at the VM level, or even lower (like Native Client).  This lets other languages and environments to be layered on top.

Giving developers choice and users security seem like both achievable goals.

Comment by Cameron Souza on December 12, 2010 at 5:52pm

Its too bad this couldn't just be Java but clearly the stars (along with Microsoft and Oracle) just didn't line up for it. Maybe now is the time for something new, like Plex, that uses HTML5 for markup the way Flex uses MXML and .NET uses XAML.


web design, web development, localization

© 2022   Created by Daniel Leuck.   Powered by

Badges  |  Report an Issue  |  Terms of Service