I deployed Altitude in box3 on Thursday. It's Wednesday so that's almost a week.
There's good news and bad news on that front.
The look of the site itself is not an important consideration in this discussion, I don't think. It has the content of squeak.org, which is links. Changing it to what it needs to look like is trivial. The problem with the design of the site is agreeing on what people want, which is a pain, because people don't know what they want, they just know they don't like what they're looking at. So, the initial impression of the sight I'm not about to trouble myself over too much, until people have some idea of what a "Squeak homepage" is supposed to look at.
The good news about Altitude is, in my opinion, that it is the fastest web framework every to be deployed in a Smalltalk image. The bad news is that at the moment it isn't 100% stable. I've killed and restarted the process twice.
If you try the site at http://173.246.101.237:8624 you'll see it moves at the rate of a laser beam. Go to Smalltalk Hub and compare. http://smalltalkhub.com/ Or http://www.esug.org/wiki/pier/Conferences/2012 (Wait for how long it takes for the browser to stop spinning.) So, Altitude is dead fast.
It has a problem though. On Monday I checked the site and Chrome said it could not be reached. I hit the ip and port. Nope. I logged in and top -d 1 to see it is now consuming 99% of CPU. Not good. I killed the process. I just did it again this morning the day after. There is no debug log printed into the image directory. So there is nothing to check.
Now, I think I can tell you how to reproduce the problem in localhost reliably. Build a site with Altitude. Make an intentional mistake.
Say you want a break tag in your page. You type in html b, when what you should have typed is html br. The basic checker will not see a syntax error, because there is an existing b tag in the canvas. But really, it's gibberish. Go to your browser and press refresh to see what you've changed. You get an error. Here's the important part.
The browser is still spinning. If you touch the debugger window while it's still spinning, then your image will hang, It'll start consuming 99% of CPU. You'll have to break out the Activity Monitor and kill. Guess what? You're work is now lost. Do that three times in a row and your mood will start to change. As a preventative measure, I started saving the image every time I was about to refresh the browser.
But here's the thing. If you stop the browser spinning, stop it from requesting the server, then you can use the debugger window without incident. I think this is related to the problem I see in box3. And I think it has something to do with Altitude/Xtreams not knowing when to stop.
Kom, however weird, is very stable. WebClient, more pleasant, is after two years seen as a stable server. It's the reliability of the server that matters, not the application, so much. And what happens when you type a wrong tag into GreenNeon, HTTPView2, or Seaside?
First of all it doesn't crash. Second, it prints a walkback in the browser, which is very useful. (I take it that the server gets output from Exception description and routes it to the browser.)
WebClient assumes a difference between server and application. I think that perhaps Altitude has see more effort spent in creating the application than ensuring the server is as reliable as it needs to be. Or giving a developer the kind of feedback expected in seeing a walkback in the browser. But, my God, it is so fast. The fastest.
I am certain of two things. The first is that we cannot watch to reboot squeak.org each day. The second is that I have every confidence that with a little work Altitude can be hardened so that it doesn't crash. This is, after all, the first time Altitude has every been deployed in a server. I think having the fastest framework is worth the effort.
Chris