Jan 20

HTML5^H: What it means to developers, standardistas, and browser vendors

HTML, Open Web, Tech 7 Comments »


As soon as you read HTML is the new HTML5 from Hixie, you knew that it would be fertile ground for people to discuss, argue, tease, and ridicule various sides… especially with this coming from WHATWG days after the HTML5 logo was unleashed by the W3C.

On one side you have people looking at the notion of a standard being alive as bizarre. Isn’t the point of standards to be able to say that multiple implementations support something in the same way?

On the other side you have people that say that the notion of a versioned standard on the Web doesn’t make any sense. How many browser implemented CSS 2.1 to the letter of the law?

What do developers want to see? The ability to know what capabilities they have at hand.

How do they work together? How can they be polyfilled? How uniform are the implementations?

This is a massive pain point right now. What does it mean to write an HTML5 experience? Some parts of HTML/CSS/JS are very well baked. Others aren’t. Developers have to work a lot of this out, and the community has built sites like html5readiness and tools like Modernizr.

In practice, to do something truly cutting edge, you have to do a ton of testing on various browsers. You want to just use CSS3 hardware transforms, but you find out that there are drastically different implications on desktop browsers, and when you get to mobile browsers the game that much more. Then there is hardware acceleration of Canvas on some browser/platforms. This goes on and on and on.

Cutting edge alpha developers can maybe keep up with some of this stuff, but Joe the App Developer may not be able too, and nor should he.

Wouldn’t he rather use a platform like iOS that has a very clearly versioned SDK that he can develop to? Surely that is much less painful.

There are trade offs though. In iOS, you have to wait for a beta SDK to play and find bugs. You are much further down the process that the Web, where you can step up and be much more active. And Web developers need to step up to be much more active. We need to be talking to browser vendors about what we need in the Web platform for it to compete, and for us to be able to deliver the experiences that we envision. We have the ability to influence our platform, so let’s make that trade-off worthwhile and not just sit and see what a particular standards group or browser vendors shows us.

I very much want to give developers a great way to see what they realistically build against on the Web platform. However, although the world took up the “HTML5″ mantle as the next “Ajax”, the HTML5 isn’t the right standard for this to play out. It has never been natural, because the Web platform is much more than “HTML”.

In fact, isn’t it ironic that “HTML5″ has become “a platform to build amazing Web applications” when much of the HTML5 spec started out by adding new tags that deal with document structure and not applications at all! sections. authors. navigation. headers.

Hixie mentions the Web Applications 1.0 specification. Something like this is more appropriate as a specification that can say “these are the things that the Web platform will give us”. Allow the HTML group to iterate in a way that they see fit, but out of that chaos we need something that can give an ordered solution to developers. And, if we have the “living standard”, we need the “living tests” that we can be continuously running on browsers. The tests will arm us with knowledge on a) how to use the APIs in many use cases, and b) tell us when regressions kick in.

So, we need to give developers a set of capabilities in the Web platform that they can rely on. What about the marketing angle?

HTML5 was laughed at by many practitioners, but it has traction with execs. They see HTML5 as a way to deliver cross platform solutions, as a way to get new disruptive experiences out to their users. The term is useful in many ways. Authors can write books on HTML5, but how do they write them on “HTML”?

In short, maybe we need some changes:

  • We need a clear vision on where the Web platform is going, and how everyone can be involved.
  • We need some notion of documenting what the platform as a-whole can do (thus: we need versions). Just as an iOS developer can see what 4.3 beta, we should have something similar. This will be an umbrella of smaller specs and versions, but we need something.
  • We need rich tests that we can run against Web platform runtimes so we know what they have implemented from the platform standard
  • We need to acknowledge the needs of multiple parties that keep the Web moving

Whether or not the HTML spec in the WHATWG is called HTML5 doesn’t really mean that much in the big picture. We need to solve the bigger problems. I hope that we don’t spend our time arguing over the politics of this or that, but on where we should go from here.

Jan 13

Sometimes it is how you say it; Google and H.264

HTML, Tech, Web Browsing with tags: 1 Comment »

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.

Dec 02

Native apps are always better than Web apps; Psst, the new way has an escape chute

HTML, JavaScript, Mobile, Open Web, Tech, UI / UX, iPhone 3 Comments »

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:

Apple - old and new

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

Oct 07

Don’t “deploy HTML5″? Thanks again W3C

HTML, Tech 9 Comments »


Philipe of the W3C has been quoted telling the world that HTML5 isn’t ready yet and that you shouldn’t “deploy HTML5″. This is sparked the old debate around when HTML5 is ready, and the haters can come out and talk about how long it takes etc etc etc. Here are his words:

“The problem we’re facing right now is there is already a lot of excitement for HTML5, but it’s a little too early to deploy it because we’re running into interoperability issues. The real problem is can we make HTML5 work across browsers and at the moment, that is not the case.”

In the meantime, great developers are delivering next generation experiences on top of new modern features that many browsers have implemented TODAY.

The Web platform makes it very possible to progressively enhance (or regressively!) your application for the fast growing segment of the population that has a fantastic modern browser.

Thus, I utterly disagree with Philipe, and instead emplore you to think about what your site or app can be in 2010 with the new capabilities. The Ajax revolution was a hack, and with modern “HTML5″ browsers we finally have a fantastic runtime with great graphics performance (hardware accelerated up the wazoo [both CSS3 transitions/transforms/animations and Canvas]), amazing JavaScript runtimes, the ability to get off of the main UI thread (Web Workers), much better offline and caching support (Local Storage, Web Databases, App Cache) and much much more.

Take a look at the demos from the IE9 beta event, Chrome Experiments, and Mozilla Hacks for a glimpse at what is coming. Users expectations of the Web are just about to be changed again. The day that you used Google Maps for the first time was the day that MapQuest seemed AWFUL. As soon as the bar is raised, you can’t go back. What side of the bar do you want to be on?

Disclaimer: There are real tradeoffs with the Web platform being an open standard with multiple implementations. The platform is diverse and not always uniform. It is our job to rally browser vendors to fix things. For example, Microsoft is doing great things with IE9, but they need to add CSS3 transitions/transforms/animations as soon as physically possible. I would like to think that Philipe meant more to highlight the tradeoffs and not discourage developers. But man, the W3C can really drive me nuts.

Remy Sharp has some nice ranty thoughts on the topic, too.

Apr 08

Google App Engine and The Java Web; The Wrong Java?

Ajax, Google, HTML, JavaScript 6 Comments »

I had the pleasure of being at the Google Campfire event that launched the worst kept secret, App Engine supports Java and Google has a preview for you to check out if you signup in time.

Java is a huge ecosystem, which is a big win, but what interested me was the nuance. The Secure Data Connector feature that gives us a glimpse of “on premise” type functionality (that Microsoft is touting with Azure) is a big one, and something that enterprises need.

The GWT pitch and the Google plugin for Eclipse is another interesting one. I am always so incredibly torn here. GWT is fantastic technology. Because of the way it works, it gets to do things that pure JavaScript libraries would love to be able to do but can’t. The team is great, and the hard core tech is incredibly impressive. I understand why people use it.

My personal issue is that it feels so funny to see the two messages from Google.

Now, these aren’t mutually exclusive of course. GWT can wrap all of the HTML 5 stuff and both can be happy. But it just feels weird to me. The idea that JavaScript is the assembler of the Web, when it is such a high level language is hard to wrap my mind around. It can be moulded to do so much more than Java can with its static nature (which has downsides too of course!)

Another thing. Writing your applications using Java in this world is about the source code and the language but not about the VM. For me this is hard to wrap my head around too. I get to use a language I *personally* don’t like as much (Java the language) and have it run on a runtime that isn’t as good as the Java VM. Hmm. And, since there isn’t the VM there (on the client, there is with App Engine!), I don’t get the pleasure of writing in any of the very interesting languages available on the JVM (Scala, Clojure, JRuby, Groovy, etc). They have picked the wrong Java for my taste!

Now, Paul Hammant has a very detailed post about building a rich Ruby application on top of AppEngine4J. He flips from a jQuery view to a Ruby client using Swiby to a Ruby Shoes app and beyond. Then, at the end, he says something very interesting:

If Google made changes to GWT to make it a viable thick/desktop/offline technology then AppEngine might shift up a gear with online/offline apps.

Since you are writing Java code, why not ship down a jar file for browsers that support Java (still a fair few) and run the application natively within the browser? Kinda bizarre, but imagine if Gears had been done in Java, and people could add functionality easily that way (this is where Yahoo! BrowserPlus is interesting… how you can write services in Ruby and the like). And now you are sending down a jar, you could write the applications using any JVM language you want. Huh. That would be an interesting direction.

Who knows where this ends. When you get practical though, Google have delivered a nice experience for people that like Java, and that is a large group still.

I am still in the camp of DSLs and lightweight and all that jazz, and agree that one great thing about the Web is that some people can come in and make a change here and there at a very high level and make something their own.

Fun times!

Oct 06

Flash in disguise: Why I want my browser environment please!

HTML No Comments »

I just went to Brightcove, a new Web 2.0 company (of course), founded by Mr. Jeremy Allaire (good guy).

When you go to the home page, you have this weird feeling where it looks like a normal webpage, but something is wrong.

But, then you try to use it like a normal web page, and it breaks:

  • RSS link: I can’t right click on the RSS feed icon and use my context menu to add it to my feed automatically
  • Links: The links are weird. They don’t mouseover like normal, and again, I don’t have a normal context menu… but a crippled one.
  • More links flipping my world: Also, a friend pointed out that if you go to the “Company” section, the current “link” is the one with the underline, and the true links have none! Absolutely the opposite to what you would expect.

My entire browser world is taken away from me. None of the numerous browser plugins that go cool things, and let me work the way I want too, are allowed to play nice.

The reason? This is a web page in disguise as a Flash file :)

This entire page is an <embed src=”brightcove.swf” …> wrapped in a table (with the usual object for those browsers).

Now, I have nothing against Flash. I think it is great technology, and you can’t argue with its reach. I even think that it plays into my Ajax world.

However, why would you break every users world to get this functionality? Sure there are some nice effects? Sure you may not have to worry about browser incompatibility, but really?

Isn’t Web 2.0 about participation? This Web 2.0 should let us participate again. Let me wield my mighty greasemonkey ;)

I like the idea of BrightCove… the more ways to get content out there the better! Come on internet TV!

Sep 25

War of the Web: Revenge of the Dynamics

Ajax, HTML, Java, JavaScript, Lightweight Containers, Microsoft, PHP, Perl, Ruby, Tech, UI / UX, Web Frameworks 933 Comments »

As I was watching “24 hour party people” on DVD, I heard the main character talk about the ebbs and flows of the music business. He is talking about the scene in Manchester at the end of the 70’s, and into the eighties. Moving from Joy Division to Happy Mondays and New Order.

I think that we are in a new chapter for the web, and as is often the case, the wheel of time is repeating history for us.

There are a few dimensions to the current war though. They are on the client side (DHTML Ajax vs. simple HTML vs. Flash/PDF vs. XAML) and on the server side (Rails vs. Java vs. PHP vs. .NET).

Let’s start at the beginning.

Perl: Birth of CGI

Do you remember how the web changed as it moved from static HTML connected content to dynamic websites? That came about due to CGI, and how our nice web server would now fork off our programs to generate the HTML.

I remember my first CGI programs were written in C, and Scheme. I quickly moved on though, and found the beauty, and craziness of Perl.

I spent quite some time with Perl, trying to get by without writing too much NSAPI and ISAPI code (oops, I guess that core dump hurts the entire server?).

I really enjoyed the community at that time. #perl was interesting (some of the time), and CPAN became the holy grail. As soon as you thought you needed something, someone had kindly put that functionality up into CPAN. I even have some of my own modules hanging out there, and helped with others.

Over a short time period, we had developed some fairly rich web modules. We didn’t have to work with $ENV{’SOME_CGI_ENVIRONMENT’}, or STDIN or the like. Our framework abstracted all of that for us, and gave us a simple model. We lauched at the folks who generated html via methods such as b("whee") and we stuck close to HTML itself, allowing our design teams to simply open the html files and see what their stuff looked like. We even had the notion of components, and special tags that you could create. <$mytag name=”…” /> was nice because the name of the tag was the key for the framework to dynamically discover that functionality. No config files, or interfaces, in the strict sense. The coupling was based on a name.

In retrospect, life was pretty simple for web development, a lot simpler than some of the frameworks we have today!

But, we moved from Perl. CGI was not the nicest for our high load servers. It was crazy to think that we would fork a process for every little request that came in, and that a Perl interpreter would start up, load the program, do the work and then die off.

We naturally moved to solutions such as mod_perl, and that helped. It was so new though that it was buggy and we had a lot of problems. Some of the problems had nothing to do with mod_perl itself, but due to laziness and side-effects.

When you work in an environment like CGI you can be a very bad man indeed. If you don’t close something correctly, or don’t play totally nice with resources, baaaah who cares? The server is going to kill me in 2 seconds anyway, so I will get my job done and have him kill me. In mod_perl world though, these programs start to live longer, and they get fat and oily.

Java: No more stinking processes!

Remember the beginning of Java (Oak!). We were building applets, and feeling the pain very early on.

Servlets were the big thing though. We ported our Perl based framework over, and were able to see significant performance improvements at the time. Some of the team loved the change, others hated the verboseness and static typing.

The nice threading model that Java gave us was huge though, even with the poor JVMs back then (Microsofts was by far the best remember!).

This is when we moved from the world of Perl to having Java start to take over. That isn’t to say that there wasn’t competition. In the waters we saw the lurkers of ColdFusion, ASP, and the beginning of the PHP revolution. Java came up with JSP to compete with these tag based approaches, but it was the advent of the rich MVC style frameworks that really spurred everyone on.

In my opinion Java is still in the hot-seat, especially in the corporate world.

Preparing for the server war

The troops are being gathered. Strategies are being worked out. We are currently getting ready for a new battle on the server side.

What’s happening?

  • Ruby on Rails: Whatever you think about Rails, it has lit a fire under the server side web development community. Many have jumped on the bandwagon, claiming real productivity improvements. Some of the PHP converts enjoy a richer language, which is still nice and dynamic, with a framework that enforces clean MVC techniques. Some of the Java community are frankly a little bored of Java, and enjoy the new challenge. They also love the freedom of the language, and the fact that they now have just ONE stack to worry about. Will the Rails buzz keep growing? Will it be the Perl of Web 2.0?
  • Java: Java isn’t going down without a fight. Some argue that the problem with web development in Java is that it has been too complicated and heavy for much usage. I have personally called for the need of a common stack for Java, and people have stepped up to the plate. On one side we have companies that will certify a set of technologies (JavaServer Faces + Spring + Hibernate). Then we get frameworks taking on simplicity themselves (WebWork now embedding Spring). Finally we have initiatives like JBoss Seam, which is trying to combine the component models of JavaServer Faces and the backend. Seam aims to give you the power of the Java tier, but also giving you a simple productive environment. So, Java frameworks are rising to the challenge of Rails, and we will soon see how much of the success of Rails is Ruby, and how much can be duplicated in other platforms.
  • PHP: We can’t discount PHP. A lot of “serious engineers” (read: anyone who isn’t a PHP developer thinks they are serious) poo poo the PHP world. Yet, by all accounts, there is a LOT of PHP development going on out there. PHP has the advantage of being something written JUST for the web. Take a look at how Wordpress came along (PHP based blogging software) and in no time at all there were thousands and thousands of plugins that you could simply drop into your Wordpress system. Literally, you drop in a file and you are done. There are numerous PHP frameworks that are aiming to mimic, and compete with Rails, so we can’t forget about these guys. The question with the PHP community is: will it grow more into the enterprise, or will it be for script-kiddies.
  • .NET: Never discount Microsoft. ASP.NET keeps getting more productive, and it is hard to compete with their end to end story, which includes fantastic tooling in their latest Visual Studio. And, we get Avalon and XAML along for the ride, as well as the futures of C# 3.0 which takes a lot of ideas from the dynamic languages and puts them into a static structure (such as: var foo = new Bar(); and the relational/xml integration)

It is going to be an interesting couple of years, as all of these platforms mature, and take eachother on, trying to get mindshare!

Client Side: JavaScript is cool again

But what about Ajax? The battle for the client side is going to be just as hot as on the server. And they will even intertwine with eachother.

Firstly we have the big debate of how far Ajax is going to go. Is it a one hit wonder? or will it become a standard part of our toolbox and even just be called dhtml again?

As an Ajaxian, I obviously have my thoughts on this matter. But there is a lot of competition inside and outside of Ajax:

  • Flash/PDF: Adobe/Macromedia are a definitely force to be reckoned with. Flash is almost ubiquitous, and PDF is used everywhere. Now the companies are combined, what do they have in store for us?
  • Avalon/WPF/E/XAML: Microsoft announced WPF/E, which is a subset of XAML that will be ported on various platforms and available in many browsers. This means that you can build your rich application in the .NET set of tools, and have it run in Safari on Mac OSX. Impressive. When are we actually going to see this in a form that we can deploy to the real world?
  • HTML: How much do we want to work in the open (ish) world of HTML. A large group of developers do not want to jump into any monopoly, and will therefore want to stick to a more open environment. But, another set will just want to use the best tool to add business value. What will the split be?

JavaScript will play a big role in this war. JavaScript 2.0 offers big improvements, that many people will cheer for. Also, the same people who poo-poo’d JavaScript in the past have come to realise that it really is a great language. It may not be what they are used too (it uses prototype-based OO vs. class-based OO), but it is powerful and robust. There are some features missing, and a big question around libraries. JSAN and others are trying to build a CPAN for JavaScript. We also worry about the black box of the JavaScript VM in the browsers, and cross-browser bugs are truly real painful. Fortunately, frameworks like Dojo and Prototype are trying to help us out on that front.

We are also seeing that we need to take JavaScript from the former:

“That is just crappy code that the web dood View-Source’s and pastes into the web pages”

to the future:

“JavaScript also needs to be engineered, and is a first class citizen”

Thus we finally see more unit testing of JavaScript code, and professional ways of creating modules and namespaces for our code. We also see great advantages with features like E4X where XML becomes a native type.

JavaScripts increased popularity, thanks to Ajax (and Flash/ActionScript) has also drawn it into the server side. Mozilla Rhino gives you a quality Java-based approach, so why not use a cool dynamic scripting language for certain tasks on the server side? You don’t have to use JavaScript for everything, but it has its place, and that place is growing.

The Battles Join

This is where the battles are joining. We have JavaScript bleeding across the layers, and we have the need for server-side frameworks to support the new Web. It isn’t enough to generate simple HTML and be done with it.

Today’s frameworks need to be able to help us build Ajaxian components, and help us write this applications quickly and cleanly.

There are various directions that frameworks are going in here.

  • JavaScript Code Gen: Why not give you a simple macro that splits out the ugly JavaScript that you would have to write?
  • JavaScript Framework Code Gen: Spitting out low-level JavaScript is too much work. Many frameworks are writing on top of a higher level JavaScript framework like Dojo or Prototype. Now the code-gen is less, and you get the benefits of the rich functionality, browser compatibility, and visual effects available from these frameworks.
  • Tools and Widgets: Should developers even care if a piece of their page is Ajax or not? Some frameworks give you drag and drop editors that let you setup widgets or components. Some happen to be ajaxian. Some are not. Who cares?
  • Markup based: A lot of frameworks are giving us markup based solutions. That is one of the strengths of Microsoft Atlas, not the fact that they added support for $() etc. Are we going to want to build using markup or via programatic APIs?


It is hard to predict the winners of the new battles, and the losers will not die off totally, but it is an exciting time to be watching web development. The dynamic languages of Ruby, JavaScript, and PHP are making a big run, and people are realising that they aren’t just cheesy scripting languages that can’t be used. It’s time to take them serious.

We are going to start really working out what makes sense for usability on the web with rich interfaces. And, at the same time we will get simpler and simpler backend tools to make the generation of rich web experiences easier and easier.

I am looking forward to seeing this battle!

Mar 14

XMLterm: The marriage of the command line and rich ui

Ajax, HTML, JavaScript, Tech, UI / UX 200 Comments »

A friend pointed me to a (seemingly old) project called XMLTerm. XMLTerm is a mozilla based “A graphical command line interface”.

At first you may laugh, and ignore some of the security implications for now, but this could actually be quite cool.

Ajax could also come in to really help this out.

Some thoughts:

  • % du: When you do a ‘du’, wouldn’t it be cool to show a pie chart usage as well as the numbers?
  • % ssh [TAB]: tcsh came up with the ‘complete’ command, which lets you get smart with your tabbing. We can take that to a new level with a bit of UI integration. If you hit TAB after typing a command that needs a host (e.g. ssh, scp) then a select list can appear with your list of hosts
  • % history: Since we can place cool widgets in places, we could have a history bar which would allow you to click on an item to rerun it. Command Line Suggest could also get pulled up if you TAB at the beginning of a command, showing a drop down on history.

The XMLTerm site itself has ideas on graphical ls which shows thumbnails, and a special cat which groks HTML, images, etc.

In theory, this could be an interesting marriage of the command line interface (power), and richer functionality (not just text).

Feb 24

Ajax: A New Approach to Web Applications

Ajax, HTML, JavaScript, Tech, UI / UX 10 Comments »

There has been a lot of talk regarding the amazing new UIs that we can build with XmlHttpRequest, and the like ( a la Google Maps, TadaList, etc ).

Jesse James Garrett has given this set of technology a new name, and talks about it in Ajax: A New Approach to Web Applications.

I am extremely excited about the technology, but can’t agree more with Jason Fried when he calls for some caution.

As with all ‘new ways of doint it’, we need to make sure that we don’t confuse the users. One of the sad truths of UI work, is that you often have to keep your UI in a state that users are used too, even if the purist in you thinks they know a better way.

So, its time for us to get creative, but end up with an interface that is as usable, as much as it blows away the customers! :)

Feb 23

JavaScript Enabled

HTML, JavaScript, Tech, UI / UX 5 Comments »

I remember, back in the day, having to write a lot of <noscript> areas, and making sure that the application that we are working on works perfectly for those that choose to turn off JavaScript in their browser (or don’t have a JavaScript enabled one).

Has the tide turned now? Of course, you wouldn’t want to abuse JavaScript just for the hell of it, and when you can give a ‘backup’ to non-enabled peeps it should be done.

But, with the likes of Google Maps, maybe we are seeing the start of the JS/dHTML revolution.

Enable JavaScript to see this site. Enable JavaScript else you will have a poor experience.