My last post on March 11 talked about the upcoming release of Sencha’s ExtJs 4.0 libraries.

Finally, ExtJs 4.0 was released last week and this will now allow development of the QuickSilver libraries to resume.

I plan to move the QuickSilver blog from WordPress to one of my own sites probably in early June. This will allow both discussion and interaction with the tools to occur in a common environment.

The goal is to create a Smalltalk-like environment for rapid development of Internet-based applications.

I will be posting more details in a couple of weeks.

Update to ExtJs 4.0

ExtJs 4.0 was scheduled to be released Feb 28, but the beta is still not available as of today (March 11). Instead, there are a number of pre-releases (currently pre-release 3) that are only available in full debug configuration. This is about a 2.8 MB download, so the loading will be slow until the beta is available.

Once the beta is ready, I will use the dynamic loading capability which should improve startup times dramatically.

ExtJs 4.0 is a major refactoring of the product, so I decided to proceed with the upgrade rather than extending the ExtJs 3.3 tools.

QuickSilver Smalltalk Compiler

The compiler is working well with only a few bugs that I am aware of.


A debugger can be implemented by some additions to the code generator that will insert extra statements to store the current state and exit the current process. I don’t see any major problems implementing a debugger.

Smalltalk vs JavaScript Syntax

The QuickSilver compiler could be extended to handle either Smalltalk or JavaScript syntax. In any case, the compiler will have to be reworked to support a debugging environment.

Currently, the compiler takes Smalltalk code from which it generates JavaScript code for compilation. The inverse should also be possible – that is, take JavaScript code and convert it to Smalltalk syntax.

ExtJs 4.0 supports SVG graphics which means that it is probably not too difficult to build an “MIT Scratch” type visual programming interface for end users.

QuickSilver is now about 86kb in size. Adding JavaScript syntax support could add another 30-50kb (guess?). Supporting Scratch really doesn’t add much to the compiler – it receives a graph structure from the graphical interface and uses it to generate code – this just uses the generator that is already in the compiler.

Dynamic Environment

One change that I am currently implementing is to load as much as possible (HTML, CSS, JavaScript) from dynamic sources – Memcache or Database. This will allow many applications to share common components.

It also means that applications can be dynamically created from existing components on the site. The “Lego” building-block approach to creating applications.

An article from a game developer publication:

At the Game Developers Conference last week, Electronic Arts and now Digital Chocolate (Millionaire City) founder Trip Hawkins worried that evolutions in the multiplatform space would pose major challenges for developers trying to earn money in emerging spaces.

The explosion of browsers onto mobile devices and the rise of cloud-based gaming can take much of the credit for why Hawkins, who was also Apple’s director of marketing prior to founding EA, believes that it’ll end up the game industry’s most central platform.

The browser has taken over 2 billion PCs–it’s going to be taking over a billion tablets over the next few years, billions of mobile devices,” he says.

And it’ll even enter new areas: “It will end up in my opinion very strong on the television. The browser is the platform of the future,” Hawkins adds.

Cloud-based rendering is increasingly enabling consumers to access content from a number of devices whether or not they own that content, thus “there is going to be enormous growth there,” he says.

Consumers will be able to integrate that content more persistently in their daily lives and want to remain engaged with it, versus traditionally when content was segregated to the living room or to a single computer.

He is saying what I have repeated several times in this blog – the application platform has moved from the desktop to the browser/tablet/phone connected to the Internet. And this trend will continue and accelerate.

QuickSilver runs in any JavaScript environment and is deployed from a cloud infrastructure (Google’s App Engine).

Form-to-Form Communication

Form-to-Form Communication

In the image above, there are two browsers open – Safari on the left and Opera on the right.

In each of the browsers, there is a window called “Test Form” which was created with the form design tool that I have discussed in earlier posts.

At the bottom of each “Test Form” window, there are two buttons – “Send” and “Open” – and a text field with the name of a channel.

Pressing “Open” opens the communication channel; pressing “Send” sends the contents of the form to any other forms which are on the open channel.

In this test, I filled in some data in the Safari form and pressed “Send” – and the data immediately appeared in the Opera form.

Creating the test form took about 3 minutes and no knowledge of Smalltalk or JavaScript was required. Using the form is even easier – just open a channel, fill in some data, and press “Send”. And, of course, the other forms on the open channel can “Send” data back as well.

I have renamed the design tool to “QuickForms” and it will be increasingly used to build both tools and applications.

Form Designer Code Generation Test

Form Designer Code Generation Test

The form window at the left was completely generated by the FormWindowDesigner tool shown at the right.

FormWindowDesigner does this by generating Smalltalk code from data developed during the design process. The Smalltalk code is then compiled into a Smalltalk class and methods. When using the tool, clicking “Save” will open the created form window and show the generated code in the Transcript.

Next steps are:

1) saving the generated code in a database file
2) adding channel and database behaviors to the generated form window

The same procedure will also enable building re-usable components and editing of existing windows and components.

As I have said in previous posts, using Smalltalk will enable the development of very sophisticated online tools and extremely rapid deployment of applications.

Form Designer Test

Form Designer Test

Above is an image of a “Form Window Designer” Test.

FWD is now available from the desktop context menu. You can add, remove, update, or move field definitions.

Items marked “Title”, “Class”, “Channel”, and “Database” will be used in the final window class creation.

The tool should be finished tomorrow.

Then we can start some Form-to-Form collaboration demos and some simple database support utilities.



“Form Window Designer” is a very simple tool for creating “Form Windows” which contain only labelled text fields.

FWD is intended primarily for end-users who have little or no knowledge of Smalltalk or JavaScript. The tool is now in development and should be available in a couple of days.

There will be two ways of using “Form Windows” created by FWD:

1) Simple database CRUD (Create, Read, Update, Delete)
There will be optional database name and key fields that can be created. If these are defined, the created window will be able to manage a simple database whose records consist of the data fields.

2) Form-to-Form communication over channels
A couple of weeks ago, I built a channel communication demo called “Chat” which sent simple text messages. Form-to-Form communication uses the same foundations as Chat but sends and receives encoded data fields instead of text.

This is the first of several user-oriented tools for QuickSilver. And it is being built 100% online using only QuickSilver in the browser.