You will be happy to know that we have just hired the JBoss Developer Studio project lead (Marshall Culpepper) to drive our tooling strategy. The goal is to make the platform as simple and intuitive as possible to ensure that tooling is a nice-to-have rather than a strict requirement (from a productivity perspective). This way VI ninjas & VB coders can be equally comfortable using Appcelerator. Join the RIA Developer group on the community site and make your voice be heard.

The first thing is “runtime agnostic”. E.g. make the widget/ui controls adapt their behaviour and presence based on their message payload. Today, the behaviour and presence definitions must be defined upfront and can’t or are hard to change during runtime. Second – like Charles already mentioned – a visual designer that allows you to build your prototype interactively or make use of reusable templates / best practices.

This video shows a nice example of these two parts. Especially take a look at the cool data viewer that adapts to the message payload automagically!

http://www.evernote.com/pub/focusfriend/focusfriend#9124565c-4810-40fe-9fcd-73a619597ce3

re: simple comments: I quite agree, and 37signals seems to be making a good business out of this philosophy

re: business users writing software with drag-n-drop: this would be interesting to discuss (I’ll be at TAE and AjaxWorld) – I think the key is to never settle for a tool that generates actual code, but only generates declarations (XML or JSON). If there seems to be a need to generate code, make the declarative format more powerful and expressive instead. Applications that succeed will eventually have requirements that move beyond what a business user can do in an drag and drop environment, so the artifacts the tool produces need to be clear, easy to understand and easy to extend.

I think you may be confused on this feature. The server isn’t listening to UI events… it’s listening to application events that just may be the result of the user’s interaction with the UI (e.g. it’s listening for process_order not for orderButton.onClick). Think of it more like message-oriented middleware instead of GUI event listeners. The server doesn’t have access to every message generated in the UI (go read about Appcelerator messaging basics look for l: and r: for an overview).

The comments stuff is specifically designed to avoid the traps of heavy duty enterprise collaboration. Notice it even uses a twitter-like log of comments. That’s kinda the whole point… the value is in the simplicity!

I’ve been down the “business users writing software via drag-n-drop” before with varying degrees of success/failure (Powerbuilder, Interwoven Workflow, etc.). I haven’t used your stuff before, but you’ve gotten it right… kudos.

BTW, I didn’t take any of your comments as “bashing”, just constructive feedback… but I also didn’t intend for my blogpost to become a competitive anlaysis for another vendor. If you’re going to be at any of the upcoming RIA events I’d love to get together with you to learn more about the concepts behind SmartClient and I can share a more in-depth tour through Appcelerator to see if we can benefit from each other’s ideas. I’ll be at ZendCon, TAE, and AjaxWorld if you’re available. Email me at mquinlan at appcelerator d0t c0m if you’re interested.

On SOA, our viewpoint is that a RIA should be able to consume the same set of data services that are exposed to other types of applications (eg installable Java clients). So, SmartClient can directly consume WSDL web services from the browser without the need for something like Axis or a Java Server. This results in far fewer services, a simpler deployment model (any kind of server; no server-side UI code needed), and a more responsive & scalable application (less server trips). I don’t mean to bash your product, but having the server listening to UI events seems like a step back from this architecture.

Your comments feature is interesting & cool, but how about enabling someone with a product management or business analyst skillset to go ahead and *actually modify the UI* (now that’s new!).

Just keep in mind – comments and the like are typically tracked through through integrated tools that are extremely comprehensive (think versioning, user roles & approvers, BPEL integration, etc) – so just be aware that your simple comments feature is on a slippery slope to heavy duty enterprise collaboration!

I should clarify that our intention isn’t to mock datasources, but rather to provide mock implementations of the Services (SOA) that will need to be written on the server-side to enable the UI. I’m sure that this was clear to you, but when I re-read the original post and your comment it occured to me that some readers may be confused on this point.

As for the “enabler” comment, I’ve seen pieces of this solution evolving for a while, but Appcelerator was the first place I saw it all come together (including the ability to easily collect the user feedback from the iterations directly in the webapp itself). That’s a big part of the reason that I joined Appcelerator.

Best of luck with SmartClient… great minds think alike, and apparently so do ours

People have been doing this with SmartClient for years, only in much, much more sophisticated form. SmartClient has a concept of a clientOnly DataSource, which can be defined in just a few lines of code with mock data, and can be plug-replaced later with a DataSource that actually contacts the server (any kind of server) without changing any GUI code.

http://www.smartclient.com/index.jsp#localDataSource

So, connect a client-only DataSource to SmartClient’s visual components, and you’ll have, say, a complete master-detail editing interaction, all in on .html file, with just a few lines of highly declarative JavaScript.

But years ago we took this to yet another level of power, deciding to let the business analysts build the prototypes themselves with a drag and drop GUI builder (called Visual Builder). Again, same concept, super-rapid prototyping where the prototype is real, production ready GUI code connected to sample DataSources that are plug replaceable.

Anyway, great article on getting rid of cruft in enterprise development processes, but yeah, Appcelerator didn’t exactly enable this