Just picked this up via bb’s post, that Ryan Carson is saying client/server MVC is soooooo old school (some might say dead). From his post:

… The basic client-server model still dominates. Objective-J and SproutCore change all that. They allow you to create true desktop-like apps right inside the browser. They don’t rely on a continous web connection and they are as quick as desktop apps.

Ahhh .. yep. Already on it. In fact, got a demo app here that pretty much blows away Sproutcore’s demo. It’s got all the good oil .. static app download, service layer, rich and stateful UI. This ain’t Silverlight or AIR, it’s straight up JavaScript/HTML/CSS.

Of course you’ve got Dojo, Mootools, GWT, Prototype, TIBCO GI, YUI, Ext JS .. the list goes on (I actually use an old library, the domAPI as the basis of my custom widgets). However *none* of these toolkits tackle statefull in-browser navigations. Check this out, here’s our in-store system:

See all those buttons down the bottom? They’re our modules. Members is currently highlighted .. that’s the Members module. Now, lets say I see a problem with some movie data, I hit the Titles button and we go to the Titles module, which is our movie CMS. Now the hip thing is that when we fire up the Titles module, the members module is left in tact. It’s statefull. I can switch back to it and hey-presto .. it’s as I left it. I can then switch back to the Titles module, and still be mid-edit on 3:10 to Yuma. This behaviour is incredible. It means you can context-switch in between doing anything, and not lose where you were.

You might notice these modules aren’t exactly light-weight either. The members module has 4 tabs, 3 internal windows, search drop down and 3 sortable grids. Our movie CMS has 5 tabs, 3 colour pickers, 6 sortable grids, tinyMCE embedded, 7 internal windows and numerous lookups. The other modules are equally hairy. It can take 15 seconds for our Titles modules to fire up .. but once it’s instantiated it stays there and keeps it’s state. From then on, navigating to it is instantaneous.

I’d love to open source the APPLEBOX app framework and help spread this new paradigm of web development. But right now my focus is on APPLEBOX as a business .. and that’s a very different beast to getting the technology right.

We love Firefox at APPLEBOX. We use it on our in-store iMacs, and it’s developer features reign supreme when creating next gen web apps such as APPLEBOX. But Firefox 2 is now getting long in the tooth .. Safari has emerged as lean and fast, Opera is also quick, IE7 is even looking ok next to Firefox 2.

Enter stage left .. Firefox 3. It’s finally being released next Tuesday and the Mozilla crew are trying to create a world record for the most software downloads in a single day.

For those of you that jumped the gun and have been playing with the Firefox 3 beta .. you will notice APPLEBOX isn’t quite ready for it. Yep, we do have some some layout issues with FF3 at the mo. But rest assured I’m on the case and will have a release by Monday night that will have us Firefox 3 ready. So go on .. pledge your support for the download world record like we have!

UPDATE
With timezone differences, download day for us Aussies begins Wednesday 3am, actually on the 18th (oops). All the timezone variations are here.

SOUI describes a development approach that fully separates UI and backend, whereby the UI is downloaded at application startup and then makes independent service calls to the backend. It completely deconstructs server assisted MVC (which is 99% of web development today) and repositions the View and Controller in the UI with the Model staying server side.

This is what we do at APPLEBOX. As a JavaScript nutter I was using the term Serverless AJAX, but soon discovered SOUI and SOFEA where becoming de rigueur terms amongst the server side noddies of the Java World.

SOUI sounds great to me! So I whacked it in my google alerts to track it’s evolution, and hey-presto .. it’s just popped up in this ppt presentation at the 2008 Microsoft Architect Insight Conference on “The Future of IT”. Looks like the presenter, Michael Barker has a background in J2EE .. but good to see he’s out there trying to educate the Microsofties.

I think SOUI is a brilliant way to develop rich web apps like APPLEBOX, but I think the push for adoption has got to come from the JavaScript frameworks out there .. prototype/dojo/yui/ext.js and so on. Appcelerant looks interesting (although I don’t know what’s up with their http://apptunes.appspot.com/ demo as it continually hangs firefox & safari on OS X) but the afore mentioned frameworks embody a massive number of web developers out there who are ready to jump on the next big thing. If SOUI is to catch on, it’s gotta be driven by these guys.

Back in 2005 Video Ezy implemented a Microsoft solution for its in-store systems, across their 560 stores here in Oz. So impressed are Microsoft with their efforts (they in fact designed it), they featured it as a case study on their own site to promote MS Solutions over Open Source. You can read the case study here. Last week Linux evangelist David Williams (of ITWire) decided to pull apart this case study and debunk the anti-linux rhetoric the case study presented. You can read that here.

At APPLEBOX for our server we use an Open Source J2EE stack sitting on a Linux box, and love it. It powers along and hasn’t missed a beat, with the only downtime being a rather hasty server relocation. But at the end of the day, it’s the product that matters, not the technology used. This is what stunned me about the Video Ezy rollout. Only 4 years ago they had the opportunity to redesign their in-house systems, across the whole franchise group. With such enormous successes from SaaS (Software as a Service) initiatives, spearheaded by the phenomenal growth of Salesforce.com (servicing 41,000 customers without any remote-site deployments to be seen), Microsoft wanted Video Ezy to roll out a small business server to each of their stores. That’s 560 remote server deployments all needing maintenance and support. 560 servers to patch, backup and trouble shoot. Hmmm.

If I was the Video Ezy CIO, I’d want a new system to centralise inventory and membership systems, to allow members to rent from one store and return to another, and definitely not need remote server deployment. I’m not convinced this is what they ended up with. My tip: don’t let technology vendors build you a solution. Their consultants will follow their head office mandate .. and for Microsoft that’s deployments - both desktops and servers.

I’m absolutely sold on SaaS deployments. The web today (and 4 years ago) is the platform, it’s scaleability and reach puts that beyond doubt. And I’m happy to report APPLEBOX is SaaS personified.

Product quality suffers. I know that inside out .. yet I just got caught myself. I’ve just updated our front page with some lovely pics of our shop. If you click them they spring to life in a lightbox (I’m using lightview). With a minor update to layout and some testimonials thrown in, it’s no biggy, just an incremental improvement.

So, as always I get it working in Firefox. Easy! I develop on a G5 Power Mac, so to test on IE I’m caught between the VPC days of G4s and the Parallels world of MacIntel. So I have a crappy windows box that sits under my stairs and is networked in. I use it remotely via Microsoft’s Remote Desktop Connection, which is great, but the RDC/windows combination still freezes way too much and I find myself getting up and rebooting the windows box more often than I’d like. Then of course we hit the beauty of IE and no multiple installs. With Firefox, I have 3 live installs: 1.5, 2.0 and the latest 3.0 nightly. Easy! With IE I should also have 3 live installs: IE6, IE7 and IE8 beta. Not Easy. In fact not possible! MS offer a free VPC image so I can run natively with IE7 and use VPC to test IE6 and IE8. But it expires regularly and on my box runs like a dog. So with an expired VPC image at this point, I’m removing and installing each version of IE to test against. Great.

So I got lazy. Tested in Firefox. Fine. Tested in IE6. Fine. Great! IE6 is normally the problem child so IE7 should be fine. Bugger it, I’ll just deploy. 2 days later I find the layout in IE7 is completely screwed and people have been seeing this weird Mondrian take on the APPLEBOX front page. Don’t worry, I’ve kicked myself enough times already. Turns out IE7 doesn’t like floats attached to unordered lists like Firefox and IE6 does. There’s another variation in the IE world to remember.

All sorted now though, and everybody can see what a lovely shop we have

Ok, time to geek out and talk about the technology behind APPLEBOX. Whilst we think our model for the local DVD store is a winner (we’ve reduced store overheads, embraced the Internet and kept a strong sense of local community even from the web) we also completely love the technology! Forget Rails, we’ve got a J2EE web stack that we think is second to none. Check it out:

• Our architecture is SOA (Service Oriented)
  All our application calls are SOAP, which from the ground up creates an API we will give public exposure to at a later date. For example this call returns a movie profile.
• Our storefront is Serverless AJAX
  The Web 2.0 movement has swept AJAX into the mainstream. We take that one step further and deliver our complete application as Serverless AJAX that makes stateless SOAP calls to our backend.
• Our development process is Model Driven (MDA)
  Rails gives the Ruby community productivity. For us, MDA gives J2EE a similar shot in the arm. Our complete stack with stubs for all business methods and web services, a default CRUD service layer, and all the J2EE XML config files are generated from a UML model. We can iterate from UML through to database and service layers in a matter of minutes. The MDA generator we use is AndroMDA.
• Our J2EE components are
  Axis (Web Services), Acegi (Security), Spring (Transactions), Hibernate (ORM), MySQL (Database) and JBoss (App Server).

The key to everything we do is the Serverless AJAX. As I mentioned in a previous post, we take the Single Page Application model, and chain multiples of them together as iframes within the browser. These SPAs are housed within a JavaScript controller that moves between each SPA as the application requires it. This is standard MVC, but the C and the V are in the browser, rather than on the server. So we’ve got:

• Static delivery of htm/js SPAs to the browser (no dynamic markup). All SPAs can be downloaded at startup or on request
• A stateful htm/js client where UI components persist until the app is closed
• Full containment of the view & controller in the browser
• A JavaScript controller that binds multiple SPAs together all with interfaces that can be called directly from other SPAs or from the main controller. With a pub/sub mechanism each SPA can publish and subscribe to global application events as well.

This is good because:

• The static htm and js resources can truly act as an application client, cached in the browser for next use. Cache headers are set to never expire, with versioning controlled within the URIs themselves (configured from a non-cacheable boot script).
• Each UI keeps its own state. For eg, when the user manipulates a page (eg magnifies the poster art, or respositions a cover strip), when they come back to that page it’s the same as when they left it.
• UI widgets don’t need to be rebuilt when navigating back.
• The complete JavaScript framework and model remain in memory. No reparsing thousands of lines of JavaScript to reload the object model that was there an instant ago.

Additionally:

• This scales well as repeat app use hits the server only for data. No pushing out reams of html, and app navigation is much less server bound.
• We build our backend as an application API from day one. We can re-use the same application services for other clients. Eg, our catalogue services are used in the public storefront, in our in-house administration systems, and from our testing framework. As SOAP services, we can also call these from Flash, Silverlight, or a native Win or Mac client if we wished. We can also choose to freeze a subset of the API and offer them publicly.

This stack works for us and delivers great productivity. To see it all in action, just click through to applebox.com.au and hit ‘Browse DVDs’!

Richard MacManus over at Read Write Web has written, Let’s Focus on Web Innovation Again!. Absolutely! The last few years have been completely manic in development pace on the World Wide Web. Driven by the early hits of hits of Ebay, YouTube, Flicker & MySpace, there’s now IM platforms, VOIP applications, Email services, online photo editing, task managers, 3D worlds and more social networks than you can poke a stick at.

But it’s become harder to see the innovation*, because now most of it’s been done. So, at the risk of hubris, I put my hand up to say APPLEBOX innovates it’s ass off!! Check it out:

1. Our Model
We’ve taken an existing model of the local video store (typified by Video Ezy), and completely turned the economics of it on it’s head. We’re fully integrated with the Internet, and leverage the strength of both local store, immediate pickup and online browse, search and reserve. Hard to believe, but nobody’s done it before.

2. Our Technology
We run Serverless AJAX with a complete Web Service back end. Without descending into too much jargon, our way of delivering APPLEBOX is new. We take Single Page apps to the extreme, and house multiples SPAs within a JavaScript controller that moves between each SPA as the application requires it. This is standard MVC, but the C and the V are in the browser, rather than on the server. I get a lot of comments on how well our storefront works; this is largely due to the Serverless AJAX techniques.

So you want innovation? Look this way. And we’ve only been open 2 months. Give us another 12 and watch out!

* My dictionary says to innovate is to introduce something new, or make changes in something established, especially by introducing new methods, ideas or products.

Nice to see Telstra and Quickflix redesign their sites and finally get some JavaScript skills on board. Good web sites engage their audience. Basic animations like sliding a strip of covers to the left or right are fun to use! There’s no page-refresh wait and we get an instant response to our actions. The page is just more engaging.

Telstra look to have turfed their skinned version of Webflicks (licenced via VNH systems) - good, because this had completely stagnated. I wonder if their new effort is internally developed? Who knows. It’s a bit slow, and still completely inconsistent with their downloads business, but hey - progress is being made. Good to see they are using prototype for their JavaScript library. Quickflix have gone with Yahoo. Both are good, solid choices. I use my own library, augmented with the DomAPI. The DomAPI was way ahead of it’s time years ago, but prototype, dojo, yui have now caught up and have a huge amount of momentum behind them. At some point I’ll consider swapping DomApi out for one of the others, but for the moment I’ve got all the GUI richness you can poke a stick at - sliding cover strips, resizing cover art, buttons that actually depress, tabs .. you name it.

Nice also to see Telstra have stretched their UI to 990px wide - hello Quickflix? Still at 800 - news flash, the majority of displays are 1024 wide these days - use it! APPLEBOX of course can go full screen width: 800, 1024, 1440, 1660 - you name it.

The bar is being raised. ezydvd.com.au suddenly looks sooo first generation. Massive traffic, but there comes a time when you have just gotta move with the times ….

Hey - made the front page of Builder AU!! You can check out the article here. The lead in:

Simon Gilligan’s attempt to breathe new life into the neighbourhood video rental store, called applebox has become an unlikely showcase for Web 2.0 technologies.

The article was written by Brad Howarth. Many thanks! Brad gives incredible coverage of the Australian IT sector - from IT initiatives to go green, the state of play with VC and emergent companies through to architecture and development strategies that small companies (like me) put into practice. Its one helluva spread that pretty much guarantees a seat on any discussion panel you can think of! It’s great that Brad has an ear to the ground and is willing to speak to the small players .. one day we’ll be big gov - honest!

I used to work in the corporate world. I had my place: analysis - specs - development. Outside my world, server guys provisioned servers. Network guys kept the network humming. Sys Admins administered systems (know unix? sure! lt gives me a directory doesn’t it!!!). Desktop guys rolled out new desktops. I never appreciated how much their presence kept my wheels turning … until now.

I bought my server, installed SLES10, found a data centre and hosted it. It took me WAY TOO LONG. I learned my sys admin and dealt with linux, apache, tomcat, ssl, webdav, jboss, mysql and all the quirks along the way. And that also took WAY TOO LONG. I’m not the uber-hacker who eats this stuff for breakfast. Its been a long hard push. And then there’s the J2EE stack: spring/hibernate/acegi/axis, modelling with UML and androMDA code gen, and then a hefty browser JS stack.

Its the config that kills me! Every component needs its own config, its own tweaks. And back in the day, there was an expert on hand who could (as Ben Stiller would say) ‘just do it’. Not in this startup! I gotta do all that, and on top of it still develop a product. Gotta know the market, watch the competition, create a business that’s more than the underlying tech.

Yet every little hiccup pushes out the development time. Loose sessionId’s with apache proxying to tomcat? Drove me nuts, lost a day. A day here, half there, 2 days the following week … it pushes and pushes out. Want a reason not do a startup? The workload will close to break you, pure and simple.

Ok - I’m havin’ a bitch! Its been one of those days … it ain’t all bad!