techno.blog("Dion")

Brendan Eich just spelled out the Harmony of his dreams. A state of the union from the language creator timed for when the ECMA TC39 group gathers to hopefully move the ball forward.

This post made me very happy indeed. Over the years I have gotten to the place where I actually really like JavaScript. There are other languages that I may prefer, but I am at peace with JavaScript and its frustrations.

Variable hoisting and this.foo all over? Crazy, but I am fine.

var self = this; or .bind(this)? Whatever.

Module system is tied to script tags? Worked around.

I was right there with ES4 back in the day, hoping to see a bunch of improvements finally getting in to more than Firefox’s type=”". Then the wheels on the bus came off. There were great additions / changes / clarifications, but the typing and namespaces/programing units/packages features? It went just too far.

JavaScript put its tail between its legs and we had to cheer for the small wins of bind() and create(). Fortunately there were huge wins at the VM level. Modern VMs are fantastic, and paved the way for server side JavaScript with Node…. after all of these years.

We need more. There is a responsibility to backwards compatibility that is always brought up. That is important, but there is also a responsibility to moving the Web stack forward. JavaScript has become the glue and power tool of the Web. In theory you can use that type=”" to do more, but getting all of the browsers to implement a language isn’t going to really happen, so we are stuck with JavaScript for good and ill, for the foreseeable future. Let’s make it great.

So, this is why I am so excited to see Brendan talking about how to do just that. There are some classic lines in his post:

You can do anything with function in JS, but you shouldn’t have to — it over-taxes JS programmers and VM implementors to learn and optimize all the idiomatic patterns. Too much like writing with only one-syllable words.

…

I agree with Doug that tail calls would be a win, especially with evented code. The # function syntax allows us to give tail calls a boost and save you seven (14 total: function + return_ – #) keystrokes.

…

Why not bind this to the same value as in the code enclosing the hash-func? Doing so will greatly reduce the need for var self=this or Function.prototype.bind, especially with the Array extras. It’s great that ES5 added bind as a standard method, but why should you have to call it all over the place? If Harmony does not address this issue, I will count that a failure.

…

A hot-button issue with ES5: Object.freeze. Whose side are you on, Batman’s or Mr. Freeze’s? Simplistic to say the least, since even in one’s own small-world codebase, making some things immutable protects against mistakes. Never mind single- and multi-threaded data sharing and other upside.

…

The simple modules proposal, along with its module loaders adjunct, is the likely Harmony module system solution. Note that there is no left-hand side example written in current JS below — you’d need a preprocessor, not part of the language.

Closing Remarks

This is a long post. If you made it this far and take away anything, I hope it is Guy’s “Growing a Language” meta-point. JS will be around for a very long time, and it has a chance to evolve until its users can replace TC39 as stewards of its growth. The promised land would be macros, for syntactic abstraction and extensibility. I am not holding my breath, but even without macros, the Harmony-of-my-dreams sketched here would be enough for me.

We aim to do more than dream. Narcissus is coming along nicely since it moved to github and got a shot in the arm from our excellent Mozilla Research interns last summer. We are prototyping Harmony in Narcissus (invoked via njs -H), so you can run it as an alternate <script> engine via the Zaphod Firefox add-on.

@andreasgal has a JS code generator for Narcissus in the works, which promises huge speedups compared to the old metacircular interpreter I wrote for fun in 2004. With good performance, we can actually do some usability studies of Harmony proposals, and avoid Harmony-of-our-nightmares: untested, hard-to-use committee designs.

A code-generating Narcissus has other advantages than performance. Migrating code into Harmony, what with the removal of the global object as top scope (never mind the other changes I’m proposing — here’s another one: let’s fix typeof), needs automated checking and even code rewriting. DoctorJS uses a static analysis built on top of Narcissus, which could be used to find flaws, not just migration changes. Self-hosted parsing, JS-to-JS code generation, and powerful static analysis come together to make a pretty handy Harmonizer tool. So we’re going to build that, too.

More on Narcissus and Zaphod as they develop. When the time is right, we will need users — lots of them. As always, your comments are welcome.

I am sure some programmers will feel like they just read Crock’s good parts and finally get JS…. and now it will change? I remember the days where my() seemed so foreign as I put on Perl5 (and it took me a bit to really grok my vs. local [and we have var vs. let now]). There are so many times where I dislike change, but then in time the changes become habit and I wonder how I lived on the other side.

It is time to re-tool.

I am finding that I really enjoy CoffeeScript. I find it fun to use. I am happy when using it. If core JavaScript can give me much of that, I will be very happy indeed.

I may disagree with some of the TC39 decisions, but I just hope that they make a big push to do bold things at this time. The time is now, and it is great to see signs of hope:

Good news everyone! typeof null == ‘null’ might actually happen.

I recently talked about the attack of the mobile browsers.

Then, Steve shared bookmarklets for mobile performance work.

He and Jesse hosted a fantastic Velocity Summit in the city today with the best and brightest in the realms of web ops and browser land combined. It was an honor learning from them, and it was just fantastic to see top notch folks from Chrome, Firefox, IE participating and sharing ideas.

With all of the performance talk, I started to play with Steve’s work, and was reminded how much of a pain it is to work with bookmarklets on iOS. There are some solutions, from Dropbox, to syncing bookmarks (from iTunes as well as Firefox Home), but in general it can be a pain.

Some of the new iOS browsers have extension support though… such as the 360 Browser. I wondered if it would be more efficient to great extensions (they call them plugins, but that confuses the world with Flash etc) that are quickly actionable from within the browser. Ideally, I could tell the browser to always run the extension so I could collect data throughout a session.

One concern though was the fact that most users on iOS are coming at you from Mobile Safari, and although these new browsers are using the iOS WebKit APIs (as Apple won’t let them do anything else) how different are the browsers themselves?

BrowserScope to the rescue. I fired up and ran all of the tests in each browser application and compared the results. They were incredibly consistent. All of the numbers were the same when run on: Mobile Safari, Sleipnir, 360 Browser, and Skyfire except for the “Cache Redirects” test in the Network section. In that case, two of the browsers passed the test and the other two didn’t. All in all that is pretty friggin’ consistent though. The network connections were all the same for example….. so this makes me feel like there is room for a nice developer oriented iOS browser. Sure, it can’t get access to a lot of the low level data, but there is much that can be done, especially if you pair it with a remote session ability so you can power the beast from a desktop rather than the dinky device itself!

There has been a ton of fire on the Internet around the news from Google that it is dropping support for H.264 from the Chromium project. I think that this is a great example of how the way it was messaged could have really hurt Google.

A core issue that Google has is that now it is large, people read many things into its actions. In the case of video on the Web, who rules the roost at Google? There are many parties that have skin in the game in some way:

• YouTube delivers a fair amount of video on the Web
• Google Chrome (browser, OS, etc)
• Android
• Google TV
• Google Voice
• GChat
• … and the list keeps going and going!

I love it when people editorialize only one of these heads. For example, this piece on how the whole thing is actually just about YouTube and their costs. YouTube is only one player.

The key problem is that Web video is friggin’ messy. The Web loves openness. Users love functionality. We are in a period of time where the two aren’t always aligned, which ends up with many people having to double encode and support multiple formats.

Also, both sides of the argument love to talk to extremes, but the lines can be a little grey.

For example:

• Some people wrote about how Firefox is doing great in Europe which is a huge market, and thus everyone will be doing WebM. Erm, there are lots of other markets with millions of people where that isn’t supported.
• Others say that WebM handled as part of a standards group, and thus “it isn’t an open standard! H.264 is!” WebM is licensed very liberally indeed, and is in a position to be very much an open standard. To put the nail in this coffin, it would have been fantastic for Google to have come out with a message that talks about plans for standardization and what they are thinking.
• “Google should stop delivering Flash!” On one side people say, “Come on. Flash is ubiquitous enough that Chrome needs it to be a competitive browser. The battle here should be to move the Web fast enough and add capability which means that plugins aren’t as needed for certain situations.” If you care about DRM and other items in video, you may wish that you can use <video> but you can’t yet. The other side will say “Google is being disingenuous with their use of the ‘open’ word 8 times in their post.” Again, I do think that the communication could have been clearer from them, and they could have explained much more why they are doing this.

In general, that post comes from “Mike Jazayeri, Product Manager.” Who is that cat? Where are these thoughts really coming from? Is it from an On2 guy looking to fight the fight? from a policy person? from YouTube?

Sometimes it is how you say it, and I think Google could have done a much better job getting their partners briefed and unified proactively, and a better job in explaining what they are really doing. A group like Mozilla can make a much more respectable argument based on the grounds of openness and the long term. Asa is out there fighting the good fight right now in fact (commenting on this great post by Haavard@Opera):

In 6 months time, of the HTML5 capable browsers, Firefox, Opera, Chrome, IE9, Safari, more 2/3rds (by usage stats) will support WebM exclusively and less than 1/3rd will support H.264 exclusively.

H.264 is not winning when it comes to HTML5 video support. WebM is winning. Actually, it’s more than just winning; it’s kicking ass.

Now. Back to an incredibly messy world of video. It isn’t about the number of HTML5 capable browsers. There are a few phones that support H.264…. and although hardware support is coming soon for WebM, it aint here yet, and the majority of content isn’t encoded in WebM. This is all great news for companies such as Brightcove who get to leverage the pain that we all have in the (hopefully) transitional phase to an open world for Web video.

Updated Google saw the commotion and I am glad to see that they joined the conversation and gave more information in this clarification.

I am American. Today was the day that it happened, and it has been an interesting experience. I have been resident in the US for over 16 years now, and the time here will soon eclipse the time that I spent growing up in England. At first I hung tightly to my British-ness. It is hard not to when you are an ex-pat. In many ways I felt *more* British being away from the motherland. You become the token, and get all of the questions and weird looks at your funny accent.

Over time I dropped the mate for dude, and even switched from colour to color. Who am I kidding. My wife and children are American. My parents and brother have become American. I find myself in a bit of a weird place, being in between. I don’t fully feel “at home” here, but no longer feel at home when I find myself back in blighty. It isn’t the place that I grew up, and I wasn’t there to roll with the changes.

I have had a green card for a long time, and should have gotten my citizenship awhile back, if not just to be able to vote against the likes of George Bush. But, something held me back.

Then I looked at my young children and knew it was time, so I applied and went through the crazy experience of naturalization. First time around I randomly got a “DENIED” letter which ended up being because something didn’t come in the mail to me, so I had to start from scratch (and pay again! Thanks fellow citizens!).

You are required to learn some simple civics as part of the process. The kind of questions that on the face of it you will nail without any study. Fortunately, my father-in-law has given me quite the civics lesson over time, and it is primarily due to he that I have been proud to take this step.

You see, I often poo-poo’d America. This baby country that has more conservative areas than I would personally like. I don’t like the role as World Police. I think that recent wars have been criminal. But with all that being said, look at how fantastic it is that I can criticize her. This blog isn’t censored. In fact, it is now my responsibility to take care of her.

Take this (from the oath that I just offered):

“I will support and defend the Constitution and laws of the United States of America against all enemies, foreign and domestic.”

Domestic, not just foreign. This country is young and has a lot of growing up to do, but at the same time, it offers me a chance to become younger again too.

My full oath is below:

“I hereby declare, on oath, that I absolutely and entirely renounce and abjure all allegiance and fidelity to any foreign prince, potentate, state, or sovereignty of whom or which I have heretofore been a subject or citizen; that I will support and defend the Constitution and laws of the United States of America against all enemies, foreign and domestic; that I will bear true faith and allegiance to the same; that I will bear arms on behalf of the United States when required by the law; that I will perform noncombatant service in the Armed Forces of the United States when required by the law; that I will perform work of national importance under civilian direction when required by the law; and that I take this obligation freely without any mental reservation or purpose of evasion; so help me God.”

It is really quite fantastic that you are executing an oath to the Constitutional ideals and not a President, or Monarch. On that note, I looked up what a Dion in a parallel universe, who moved to the UK from the US, would be saying today upon joining the United Kingdom as a citizen:

“I (name) swear by Almighty God that on becoming a British citizen, I will be faithful and bear true allegiance to Her Majesty Queen Elizabeth the Second, her Heirs and Successors, according to law.”

That’s right. You are swearing your allegiance to Queenie still!

One thing I did like though was the note:

“You can make an affirmation if you prefer not to swear by God.”

I appreciate that, and wish that I didn’t have to use that term so much in my ceremony today. It undermines my oath since if I don’t believe in Him, am I really able to take the oath?

The ceremony itself beat my expectations. It was held at the Paramount Theatre in Oakland (they made me pledge allegiance to the Oakland Raiders too! :), and the chap running the show was funny! He welcomed people in 8 languages…. very impressive indeed. He was incredibly respectful of all countries, and there wasn’t even a hint of “you have joined the most amazing country! you were so smart to leave any other!” and instead the already mentioned respect for countries all over the world. There were over 1300 people present, from 106 countries, some of which I had never heard of, and others that do not exist anymore. Barack Obama said a few words (recorded of course), and I was thankful that I waited for his welcome rather than a predecessor.

I now look forward to adding to the melting pot, and hope to be a bridge between the yanks and the chaps.

Here’s to my fellows from both countries that I adore.

It has been exciting to see the increase in mobile browsers available for various platforms. Some platforms have allowed this freedom (e.g. a “full” Firefox experience on Android). Others like iOS restrict applications to the realm of WebKit and the APIs available:

“2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript”

Even with that handicap, we have seen some very interesting experiments, each with their own take.

I have been playing with some of the new iPhone browser apps recently. What jumps out at me?

My favorite is probably the 360 Browser from Saloni Srivastava. It packs a lot of fun features into a small device sized package, even if the UI feels a little foreign sometimes:

• The pie menu approach brought a smile (we experimented with a pie menu in Bespin). There are two modes: drag and tap. With the default drag mode you end up holding a digit down on the screen and moving around. In practice I found this approach wanting because I would either hide the menu that I was aiming for, or I would move off and the menu would disappear. I prefer the tap approach, but actually wish for a solution that mixed the two… specifically, in tap mode I want to be able to hold down on a menu item and have a tooltip tell me what I am dealing with…. important as you learn the system.
• Firefox Sync support is fantastic. I wish that I could tie in syncing from other browsers too and unify things.
• In the top left of the toolbar you can quickly tap to make the current tab private…… something that many users will enjoy ;)
• Tab support in general is good, and you can quickly show and hide them
• Which leads into full screen support
• The plugin system allows you to bring in a lot more to the experience. It feels a bit clunky, going into the plugins area and tapping on the item even though it has an [x] on it etc, but it great to be able to extend your browsing.

Sleipnir Mobile innovates nicely with tabs and somewhat with tagging and bookmarking. Being able to setup various “workspaces” for your tabs is very useful. I find myself wanting to keep a copy of sites like TechMeme, Hacker News, and others, and being able to put them in one tab group is fantastic.

Skyfire has both an iPhone and iPad version of their browser. Most talk about their support for Flash video, but they also have other interesting features such as their “quick views” which give you a taste of Twitter or Facebook without having to jump away from your current browsing stream. I am not the kind of chap who is looking for “related” exploration, but others probably are. It is also interesting to see how browsers get around limitations of the app-centric model. For example, Skyfire is aware of the clipboard and sucks in URLs, since you can’t send a URL to open that browser, or have a system-wide setting for “default browser”. We have similar issues with bookmarks. I want one central store that they can all use (others would like separation).

In general, features such as private browsing, better tab management, and also caching itself can be huge. It drives me bonkers to hit the back button and have to wait for a page to be reloaded when I just came from there. I would happily give up a lot more hard drive space on my device to the browser. The feel of the browser is important too. If the scrolling is off, or the gestures? Ugh. I had that experience with Opera when it first came out. By default pages were zoomed so far out that it was unreadable and the pinch/zoom felt wrong.

I really hope that the exploration that is happening in the mobile browser space (and the money that some folks are making off of it!) keeps going, and that Apple opens up their terms to allow for a full Firefox experience and others.

What would you like to see on a mobile browser?

I love the Web, but a couple of things have gotten me thinking.

#1: Netflix on PlayStation 3 via HTML5

I got to meet some of the awesome engineers behind the HTML5-fication of Netflix experiences, specifically folks in the TV group. They showed us various UI experiments and it was beautiful to see. The UI is slick and modern, and every effect is using CSS transition goodness, nicely hardware accelerated thanks to the PS3’s GPU.

At first it may seem a bit crazy that the team took Qt/WebKit with them as the rendering platform, but when you think about the huge number of devices that Netflix needs to support, it makes “wanting an iPhone and Android app” seem like laughable fragmentation.

#2: Trusting the implementations to catch up?

We have amazing browsers in modern devices. But as we push the Web forward, we are still facing buggy implementations and varying support. Although WebKit lives within Mobile Safari, that doesn’t mean that Mobile Safari has open sourced everything to WebKit. The touch support isn’t there. We can’t all use the same scrolling effects and the like. That has to be built up by everyone.

Ideally, with position:fixed (now in Android), you could use that and even flexbox to use the core scrolling of the browser itself so you don’t have to resort in the mimicry that frameworks have had to do until now.

Even the magical escape chute to the GPU via CSS3D isn’t a silver bullet.

Matthew Farag has a lovely portfolio site that uses the power of this modern goodness (using Scripty2 for auto hardware acceleration!). Works great on a desktop WebKit, but how about the iPad? It does pretty well, but you start to see some of the buggy issues where the GPU seems to run out of memory and you get weird artifacts.

So, when you put these two together, you realize that it could be nice to carry a great consistent Web runtime with you to allow you to get great experiences, especially while we are transitioning and getting everything flushed out. It would also enable us not to be beholden to the likes of Android and Apple to make sure that their Web runtimes are fantastic.

I may want Chrome Frame for devices more than I care about it on the desktop as it turns out. Hmm. Alex? ;)

People have often commented on how strange it is that Google has two OSes in Android and ChromeOS. Some talk about how it is doing the “Microsoft thing” by setting up an internal competition, and Google is big enough to do that kind of thing.

There were many who saw that “the Web will eventually win”, but as Android’s numbers get larger and larger, others are pondering things. Is the timing off? Has Android gotten too large to let itself lose to Chrome OS? Is the app ecosystem for Chrome OS not up to snuff with Android (let alone iOS)?

If Google pulled the plug on Chrome OS it would feel like a bad day for the Web. Chrome OS needs push the entire Web forward. Chrome is adding features to WebKit and Chromium at a very healthy rate, and the Chrome OS pieces make sure that features that flush out the Web to rival native environments come along. Without the Chrome OS project being part of the whole Chrome ecosystem, that may not quite be the case.

There are some projects that Google should go long on, and some that should be experiments. You could argue that Wave was an experiment that didn’t warrant continued evolution, but Chrome OS should. It moves the Web forward.

The Web has a lot of huge benefits, but it is still hard at it going up against iOS, Android, and others. We need a lot of investment to give the Web the SDK that developers are striving for, so they can deliver compelling experiences. We aren’t there yet.

With Google and Chrome OS, HP and webOS, and even a lot of other players (e.g. RIM and its Web support, Nokia and its, etc etc) we are seeing a healthy double-take on taking the Web forward and making the next big platform truly multi-vendor.

“Merging” with Android is interesting. Android’s web stack has gotten better recently, but it is very much lacking, and you could argue that getting the Chrome/WebKit talent and putting it on the Android stack could do a lot for the Web, and maybe bring the Web up to be a true Android platform. That could be a good thing, but would it ever truly be a first class citizen compared to the “Java but not really Java” stack?

I truly hope that Google double downs on Chrome and Chrome OS, and gives it time to have the Web come along for the next ride as more than the ghetto that some would like to see it become.

If not, time for Mozilla to create a Web OS :)

When we talk about the mobile Web being a good candidate to be a unifying platform for mobile and beyond, we often get nay-sayers telling us that there is no chance of this happening.

Their claims often chanted include:

• Cross platform never works (case in point: Swing)
• You can’t create a great experience without going native (and Apple raised the bar on the experience!)

There is some validity to some of this, but I also wanted to discuss the other side too.

Cross Platform Did Work

Swing gets bashed because a) it didn’t take off, and b) people always saw Swing apps as ugly and great examples of the uncanny valley. That team worked tirelessly for many years to try to get the look and feels to be as exacting to their hosts as possible. A pixel off here and there…. and it felt wrong.

It turns out that this probably wasn’t the right approach, and either a) Use SWT to use the real OS components or b) create a great looking l&f that is different to any one host, but natural and fantastic to use. Ben, Jasper Potts, and others fought for such a look and feel in Nimbus but a lot of time had gone by.

We have all seen many platforms on top of hosts that don’t feel right and don’t look good. That doesn’t mean that cross platform can’t work. Flash is an example that is very much cross platform and that community very much went the “every app will have its own UI”…. probably TOO far in the other direction ;)

In fact, the Web itself is a fantastic cross platform success. We have argued that if it wasn’t for the massive Web revolution, would non-Microsoft vendors (read: Mac OS X) be in the situation there are now? Or would they have followed in the wake of Atari, Amiga and BeOS? When the Web happened, suddenly the interesting actions that people wanted to do on a computer were dominated by the global scale of the Web (Google, Amazon, Yahoo!, eBay, etc). The Microsoft Office lock-in was gone (aside: it also DID help a lot that Microsoft gave Apple money, got Office over there, and solutions like VMWare enabled those few Windows apps that you still wanted to come with you).

The Web was a great cross platform success, even though its rich capabilities in the areas of graphics were laughable…. as I mentioned in an earlier post:

When you look back at many of the earlier designs of the top website brands, they are comical by todays standards. However, at this same time, technology such as WPF was being touted on the desktop. Why would people visit Web sites when they could experience amazing native Windows and Macintosh experiences?

So, I don’t think you can discount the Web on the merits of “cross platform can’t win” as it already did win once, and at a time when the capability gap was much wider than we now have with HTML5.

Compare this native app to their Web site!

I teased about the Delta mobile Web application before. If you compare their iPhone application to what you get if you go through a mobile browser, the difference is huge.

But, is the reason they are so different due to capability? I think not. I think the reason is much more about structure, legacy, politics, and history reasons.

I remember seeing an early viewing of an Adobe AIR eBay client. The thing was so rich, so much better than the awful eBay site in almost every way. It made you want to cry looking at the website afterwards. Why or why would eBay have this fantastic client and not spend time on the website where all their customers were! It wasn’t that they were baffoons, it was because they had no legacy in this new world!

The designers had free rein with a blank sheet of paper. They had core concepts and some design language, but total creative freedom. Compare that to the website. If they changed the color one hex value users would go nuts! Every time Facebook changes their site there is a massive campaign to change it back for the first 2 weeks.

They also didn’t have to run the gauntlet of the massive codebase that had been built over years to make any of these changes. And the QA. Ugh.

In fact, an entirely new team could be formed to do this work.

This is exactly what I am seeing in mobile. In many companies, if there is a mobile group, they are just that…. a very separate group. In a non-mobile-thinking company they are like the old “Mac” group in a Windows heavy shop that hangs in the corner and is very different.

Other companies are still getting into the world of mobile and realizing that usage patterns are going in that direction. They are bringing in consultants to help out. They are forming new crack teams to take on the challenge. They are realizing that they need to re-think the entire experience, and hopefully realizing that they need to create software as-a-whole in a very different manner.

The bar on the quality of experiences on some of the mobile platforms is very high indeed (and very low on others!) which has the (great) effect of pushing the bar forward.

Will this leave the Web versions behind? Maybe in the short term. Kinda like how the old Twitter website was simple compared to Tweetie and other clients, but #newtwitter is much richer and borrows some of the concepts where they make sense.

I am definitely seeing people swing back to their web experiences. As multiple platforms foster in touch and cross device, they are starting to feel the increasing tax of building totally different applications across the fragmentation, and then trying to keep them in sync once the 1.0 is complete. Outsourcing the 1.0 is one thing, but the syncing part is hard.

Back to Delta. You will notice that the screenshots on the web side get increasingly poor as you go deeper into the experience. Contrast that with the iPhone version above that is always at a high quality. It is time for them to go back to the web side and sync up.

In fact, just before a recent talk, we coded up some of the simple transitions and feel just so show how easy it is to get some of this stuff working via the mobile Web. You can see the simple example here.

In our Palm Developer Day keynote we shared some of the high level pieces on how to put this all together, the major piece being that you have to really re-think the way that you architect your applications (think: Gmail not server generated HTML, Backbone.js, and more).

Here are some of the slides:

aside: Dave Balmer goes into some depth in his Rockstar apps with HTML5 talks.

Of course, it isn’t all hunky dory. There are still edge cases on getting things performing just right using the Web on the various devices. You have to think “cross platform” again. It may have been nice to ignore that and hack on a native application for awhile. But, would you rather be porting between proprietary SDKs and languages all day long? Or re-use as much of your code as possible.

And, if for some valid reason you really DO need a bit of native for something, you can break out of jail and do just that. The escape chute is waiting for you.

We have a long way to go on giving developers better access to native capabilities and tools to make building the next generation of apps more of a breeze, but it is doable right now (another aside: webOS kinda proves that right now as the native apps ARE Web apps!)

I will finish with the interesting take from Venture Beat the other day on how
the iPhone app is the Flash homepage of 2010. They say:

In the late 1990s, it was common for companies to spend $50,000 to $150,000 for a Flash homepage that looked like a beautiful brochure. However, they soon learned that Flash was cumbersome, slow to load, expensive to build, and hard to update, and moved on to HTML. Now only specialized, high-end sites are Flash only.
The exact same thing has replayed itself on the iPhone. Companies have paid $50,000, $100,000, and more for an iPhone app. Now they have to keep the iPhone app in sync with their regular web site, and have to add additional native apps, each at a high price point, due to the hypergrowth of Android and newly viable platforms like Windows Phone 7

Today was a big day for us, moving into the new pad on University Avenue, Palo Alto. Not a bad place to be! Major kudos to Spencer Tall of Allegis Capital who are letting us hang with them as we incubate our ideas. It is majorly appreciated, and exciting.

Once we finally settled into our offices (after a trip to the Apple Store, just a block away!) we sat down to look at the view, and we giggled to see that it was this:

We are staring at the front door of Sencha! It feels like we are on a stakeout to see when Abe comes and goes. We took this shot and sent it to Abe just to let him know that we are “in position” ;)

We said “hi” to our Sencha neighbours and man did they seem in good spirits. The very recent SenchaCon was a huge success. It was there that they announced their 1.0 of Sencha Touch, and that it was to be free. This is great news for the mobile Web community at large. The segment is buzzing with jQuery Mobile, Enyo, Sencha Touch, and more.

Congrats to all, and Abe….. looking forward to being your neighbour mate.

The Palm Developer Day in New York City was a ton of fun last weekend. Greg and the events team did a bang up job, and it was a pleasure to continue to hang out with the webOS community. Seeing old friends was great, and finally being able to put a face to a name or a nick was great too (highlighted by meeting Rod Whitby of webOS internals, all the way from down under!) This community sure is passionate.

A strong thread throughout the show was the importance of cross platform solutions for developers. There was great content such as a cross platform framework landscape review, and PhoneGap, and a panel including the likes of Charles Jolly of Strobe/SproutCore.

The icing on the cake though was the coming out party for Enyo (greek goddess of War), a next-generation touch UI framework from HP.

It is important to understand where Enyo came from. A chap called Matt McNulty was one of the reasons why Ben and I joined Palm way-back-when. We had been working with him on a webOS-bespin hybrid which later became the fantastic Ares Web based IDE. The layout system is still best in breed, and being able to deploy from the Web to your phone is just awesome.

Those in the Ajax community, especially Dojo old-timers wouldn’t have been surprised to see this level of polish and innovation. Scott and Steve created the grid that was donated to Dojo.

The team behind Ares were not using the Mojo framework, but rather another one (Opus) that would morph into what we see with Enyo today. Going between an Ares application and a Mojo one has always had friction, but that will all be changed with The Unification happens. You will be able to go between the UI builder tool (Ares) and hand coding, no sweet.

There are a bunch of modern touch UI frameworks these days: Sencha Touch, Sproutcore Touch, iAd JS (really!), jQuery Mobile, and more. I am excited about Enyo being added to this mix. Here is why:

Performance

This has been the number one goal, and I have seen the massive difference that it makes on webOS. Enyo based apps start incredibly quickly and stay smooth. This is an area that webOS needed to improve (performance) and Enyo makes huge strides (especially when you also add the work that the entire platform and apps teams have done). Fortunately a lot of the top frameworks are starting to do a really good job here. They are using similar tricks around: keeping a virtual tree and only going across the DOM boundary as little as possible, trying hard to keep animations and rendering on the GPU and without triggering re-renders whenever possible via CSS3 tricks.

Developer productivity

Ares developers have told us time and again how fun it is to write apps. It is very easy to get going, and this goes beyond the great tools. The Enyo framework itself has some fantastic developer ergonomics, especially around layout and the event design, which also helps make sure that you don’t leak memory (obviously a huge thing on mobile).

Cross device

Another major goal with Enyo is the fact that it has to deal with the number of devices coming out of HP running webOS in the future. This is huge, because a massive pain points for developers right now, and in the coming years even more so, will be the need to handle many resolutions, dimensions, and capabilities for the touch world. By solving this problem in a unique way, Enyo makes this a strength. Scott Miles (or as I call him, The Architect) showed off an email client that is in “phone” mode (list of emails) when in a narrow window, but as soon as it got big enough (say, a tablet size resolution) the layout changed in real-time to offer a different view. Being able to share views, and have magic components that can even do a lot of the work for you, is fantastic when you think of building applications that span mobile and tablet (and others). Beyond this though, what about Web apps? I have often said that I wish that I could run a Twitter app in an IM-like configuration (long thin view) looking like echofon/Tweetie/etc, but as soon as I maximise it or stretch it out, it uses that real-estate to become more like Twitter for iPad or TweetDeck. Enyo makes this very possible indeed.

ASIDE: I had a bit of fun with doing this manually with the “hello world” style site setdirection.com which changes between browser, mobile (including landscape and portrait).

Cross platform

Enyo is too good to be stuck on any one platform. I think that the folks behind webOS know this. Having a set of tools and framework like this available for the Web as a whole is going to add to the growing list of quality frameworks that are available for true touch applications (not just DOM sprinkling libraries).

Having this discipline is also added by the fact that you can then spend most of your time developing in a browser rather than an emulator, and thus use all of the browser debugging tools that are available.

Conclusion

Firstly, congrats to Matt, Scott, Steve, and the entire team for showing us a glimpse of Enyo. I can’t wait to have developers play with it. Go Web.

It is great to see not only PreCentral grok its importance, but also Engadget and others.