Nov 21

Enyo shows us a some skin; Sneak peak at a fantastic new mobile Web Touch framework

Mobile, Tech, Web Frameworks, webOS 2 Comments »

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:


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 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.


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.

Jan 20

Why I often prefer Prototype too

Ajax, Tech, Web Frameworks with tags: 9 Comments »


Picture via Dunechaser

I still get asked “what Ajax framework should I use?” frequently indeed. I think that people feel that with my Ajaxian postings I have seen every framework in the world and will have a magic feel for things.

I dread these questions, as context is king for making the decision, and “feel” is a major part of it too. The various frameworks have in many ways come closer together over the years, so making the choice is harder, but also maybe not as big a deal as it once was.

That being said, I really enjoyed Glenn Vanderburg talk about why he prefers Prototype to jQuery. This is the kind of subject that is asking for trouble and foaming at the mouth from people on various camps. Glenn has the kind of nature, wisdom, and touch that makes it hard to think that way. He gives thoughtful points and isn’t trying to cause a stir.

These days, without any real context (e.g. skills on the team, what the project does) I kinda think:

  • jQuery is fantastic for taking a website and making it dynamic. Easy. elegant. Beautiful. If I was a designer doing a rich site I would stop here.
  • Dojo is fantastic for building a large scale application that will do a lot, and end up with a ton of JavaScript. Everything you need will be found there. This isn’t to say that Dojo can’t be used on the small anymore. The new core is small and fast and good.

Prototype, for me, fits in between these worlds. It is small enough to feel small (not a huge library to learn) yet large enough that I don’t jump out into creating a lot of my own code.

On a recent jQuery project that grew fairly big and I found myself surprised that the core didn’t have certain methods and features. Much of it was small things (one example I remember is array utilities). I would find myself looking around for plugins, wondering which ones are good, and generally having a little bit of a tough time. Then there is a the type system. For something that isn’t strapping on a bit of code to the web site, I actually like Class.extend and the like. With jQuery I would use Traits or Base or something which is fine…. but not just there in the same way.

I get used to myArray.last() and having the convenience methods available to me directly on the objects, even if the puritan in me feels a little strange. Just as Ruby “felt right” to me. Prototype does too (duh, since its heritage). A blend of purity and pragmatism. More often than not Prototype surprises me “oh, wow, it has that function already!” On another recent project that got converted to Prototype, I was able to delete a LOT of code. Utility classes went away. Libraries went away. There is nothing better than the feeling of deleting code. Am I right? :)

So, I agree with Glenn. For me, Prototype is the right balance for many of my projects. I still enjoy playing and using others when the project calls for them, and I am ignoring the huge number of other great frameworks (YUI, GWT, MooTools, Ext, SproutCore, Cappucino, man I could go on forever here).

Mar 05

Choosing a Web framework over the years

Comic, Ruby, Tech, Web Frameworks 3 Comments »

Choosing a Web Framework

I read through Wired on the plane. In fact, I use Wired as a barometer on how much I am traveling. If I go to the airport and there IS NOT a new Wired for me to pick up, I know I am traveling too much.

Anyway, I perused the article on 37signals which did a good job on not being a total love-fest. It is one of those articles where you take out of it what you thought before. If you think they are arrogant gits you will say “yup, arrogant gits”. If you think they are doing great things for the industry, you will continue to think that too.

It did make me think about how great we had things a couple of years back when Rails was red hot. There was that brief time where you tons of people were saying “Wow, I am going to choose Rails for my next application”. The alpha masses from Java, PHP, ASP, all checked it out.

Now though? They are moving on to check out other solutions. Many frameworks have copied some of the good things from Rails that make sense in their worlds. Now when I think about the next toy to play with, I have a large set of potential “cool looking” frameworks to try.

For such a brief time, life was easy.

Mar 03

It’s 3am…. can your Web framework handle a diggin?

Comic, Politics, Ruby, Tech, Web Frameworks with tags: , 2 Comments »

Rails at 3am

I hate the fear ads, and seeing the Clinton one was sad to see. Showing pictures of kids etc… are you kidding me?

I know Hilary is scrapping for her life, but still. I really don’t understand the experience line too, since she has only been a Senator for a few years. How she comes up with 32 years baffles me.

Anyway, it all reminded me of the fear-monging around Rails scaling.

Jan 29

My interview with Steve Yegge on Rhino on Rails

Google, JavaScript, Tech, Web Frameworks with tags: , , 17 Comments »

I have been a long time follower of Steve Yegge and his long blog entries that manage to keep your attention. He has the opposite style to me (I know how curt and bad my writing style is!), so I envy it a little.

Ever since he presented on the ‘Google Rails Clone’ at FooCamp and posted about the internal Google Rhino on Rails project, people have been curious to learn more.

  • What does it mean to port Rails to JavaScript?
  • What can’t you do since JavaScript doesn’t have the same meta programming facilities?
  • Rails = a group of Active*, so did you re-implement everything?
  • What do you gain out of having JavaScript all the way down?
  • Does it actually make sense to have jjs? Server side JavaScript generating client side JavaScript? Argh!
  • What is the state of Rhino?
  • Will Rhino support JavaScript 2?
  • How does the JVM help you out?
  • What are the ramifications of implementing ActiveRecord with Hibernate
  • Fun other languages to play with

And of course, the big questions:

When do I get to see it!

I happen to be in Seattle at the Google offices, so I was able to ask all of these questions and more. Steve was a fantastic host, and I really enjoyed chatting with him.

This is the kind of video I want to explore at Google. We have many great developers working on cool technology. I want to get them on camera, participating with the community when I can. Sometimes we can talk about products and APIs, but sometimes we will talk about fun ideas and projects that we are working on such as Rhino on Rails.

Anyway, give it a watch and let me know what you think:

Jan 23

2008: Year of Server Side JavaScript?

JavaScript, Tech, Web Frameworks with tags: , 1 Comment »

Michael Mahemoff has been playing with server side JavaScript too.

I too haven’t heard of half of the list of Server Side JavaScript frameworks on Wikipedia, although it is certainly interesting to remember that Netscape did JavaScript on the server waaaay back in time.

At the same time, Aptana is trying to define an “Ajax server” with todays release of Jaxer. At first glimpse you can see some of the other frameworks, but it certainly is doing a lot more.

Michael hits on one of the key points when he talks about deployment:

Try finding a virtual host that supports Javascript! You would practically need one that support Java, so you can run Rhino or whatever, and few virtual hosts do that. At least Python and Ruby were running on many virtual hosts before Django and Rails showed up. For that reason, the model pursued by AppJet seems worthy. If they can come up with a solid virtualisation environment for Javascript, they may be on to a big winner.

I want to be able to hit “DEPLOY” or “PUBLISH” and have that be the only way I interact with production applications from now on (with the ability to roll back and scale out). When someone nails that, we will see a lot of applications coming out.

Maybe should become “Your JavaScript Community”?

Jan 22

Visualizing the business importance, and slow moving development, of the Web

Gears, Tech, Web Browsing, Web Frameworks 2 Comments »

Brad was speaking on a panel at a recent conference and asked a couple of questions, and the answers visually said it all:

Raise your hand if your business relies on the Web in some way:

Group with raised hands

Raise your hand if you think that the Web is moving fast enough as a development platform:

Group without raised hands

Jan 15

Gears Future APIs: Services / Daemon API

Gears, Google, JavaScript, Tech, Web Frameworks with tags: 4 Comments »


One of the comments on the Notification API was by lunatix:

It would be really useful if we could set a background javascript process (via WorkerPool) that continue to run after browser is closed and which is able to send System Tray notification.

I would definitely like to see an API (or as part of the Notification API, or WorkerPool in general) that allows you to attach some work to a process that can always be running, or be scheduled to run (a la cron).

This can be particularly important with Offline and syncing that comes along with it. Imagine a world where Gmail worked offline. The need for a service that downloads email in the background may not be that important, as people tend to leave a tab with Gmail running in it.

But, if you take Zoho Writer as another example. You may not have Writer open all the time. You open it when you get a new document that you want to work with. Let’s take a look at a scenario:

  • Bob edits a shared document that discusses the travel for the next quarter
  • Bob closes the document and keeps working for the rest of the day
  • Meanwhile, Harry, Linda, and Chou all edit the document
  • Bob goes offline and heads to the airport
  • Bob opens up the document on the plane

Does Bob just have the document with content from his step? If there was a service that was running in the background, it could detect the changes and bring them down. Then Bob would have the latest and greatest up to when he turned off his computer.

The obvious issues

Of course, a key issue here will be making sure that this isn’t abused, and what UI do we give users. I personally never like it when I find services running on my machine when I closed an app. You know the culprits…. Quicktime and the like. I want to be able to know about every service and prune the list, but also not be burdensome for the average Joe. Does this mean that the system tray notification system has a way to see all of the services?

Also, I don’t want some rogue daemon taking up my resources, and of course, it can’t have special access to things such as key logging ;)

You can write Gears too!

A few people have emailed me about potential Gears saying that they wish they could build a new Gear. Remember, Gears is a true open source project, so you CAN write your own Gears. If you want to implement a new API, start out by emailing the group with your proposal and then get to it!

Other Future APIs

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

Mar 01

Aren’t you bored of Java frameworks? I am.

Java, Tech, Web Frameworks 32 Comments »

Back in the day, I was the first person to know, and care about version 2.6.1 of FooBar, the open source framework that does everything that you need.

For one, as editor-in-chief of TheServerSide, it was my job to be on top of things.

For two, I actually cared. The playing field was fun, there was a lot of innovation. It was a brave new world.

Fast forward to 2006, and I am the anti-framework releaser. If I never see “YetAnotherMVC 1.2 Released” announcement on TSS and others, it will be too soon.

Isn’t it just so BORING? Partially, I think I hit the end of the road on keeping up with the Jones’. At the end of the day I want to get my job done. I want to produce business functionality for my clients. ROI and all that garbage.

Now, I am living part of my life in the land of the UI. What has excited me about this land, is that when I develop a great Web UI for a client I can:

- Show my wife, and she can see that it is cool. Telling her (totally non-technical thank god) that I refactored my 3-tier backend using ALL of the GoF patterns isn’t a turn on. Neither is showing her a web page, but at least she can get it.
- Same for the client: Watching clients say “wow” is worth it. The backend is very important, but the front end is big too.

So, I am officially bored of all of the server side framework crap. I do listen for some things. Every Dojo/Prototype/Scriptaculous release makes me look, as so much has been added, because they are so young.

Aren’t you kinda bored too?

Feb 15

Scaling Websites (RE: Large sites powered by Java web frameworks and Tiles + WebWork)

Caching, Tech, Web Frameworks 4 Comments »

Matt Raible is look for large sites powered by Java web frameworks.

Maybe I am in a cranky mood, but I wouldn’t worry about scaling out the web tier.

You can scale JSF just fine (although I may not like JSF at all ;)

Slashdot does just fine with Perl + memcached.

Your scalability concerns are going to come in with your architecture, and caching.

If the bottleneck is in taking the HTTP info in, parsing it into objects, and the on the back-end doing the opposite, then you have done an amazing job scaling the database and the network layers.

Of course we need to test our architectures etc, but I have just seen a PHP application that handles a massive load, with an average architecture :)

It handled everything just fine because of the caching they use.

This is why running on EJB etc was/is such a hilarious thing. Tapestry isn’t the bottleneck ;)

And with 64 processors each with 64-cores, CPU bound scalability probably won’t be the case often too!

Use the tech that gets out of your way and feels right to you. This is why Rails is doing so well.