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

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.

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.

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:

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 TheServerSide.com should become “Your JavaScript Community”?

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

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

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

• Notification API
• Crypto API
• Developer Tools
• Factory API updates
• Blob API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

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

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?

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

The Java side knows that in-fighting isn’t good anymore, so we are seeing more and more of the groups working together.

At first the troops gathered around the Java Web Alignment Group, a loose affiliation where nothing has really happened (it is very new).

I think it was a “we should work together!” cry, with no hard action items.

The Spring guys saw JBoss Seam, and talk of Clarity came together (along with other folks).

I certainly feel that there is room for common Java stacks, and Spring is a project that can pull this off.

Now, even more recently, a new force has entered the fray. It is the joining of WebWork and Struts. The WebWork guys have already been working with the Struts TI guys (using XWork), and I think it is a great fit.

Struts has the name. WebWork has the technology.

I can’t wait to see what comes out of the Struts Action Framework 2.0.

It is important times for Java frameworks, to see if they can compete with the simplicity and productivity of some of the other frameworks (including some of their own like RIFE).

Let the games begin.