Abstract

Why Smalltalk for JavaScript?

Smalltalk references

Needed Smalltalk features

Tools, parsers, generators etc

Contact me only directly please:
hgn@catpool.com
and please NOT via these job sites, where we may have had first contact.

 

 

JavaScript tools are archaic and primitive

The development of Smalltalk code for JS must stay inside Smalltalk
as part of existing code libraries

Smalltalk comes closest to the panacea language

Let's combine the advantages both languages

 

 

Smalltalk to JavaScript translator

Abstract

We intend to develop a Smalltalk to JavaScript translator in order to combine the advantages of both languages and to avoid the great disadvantage of the very archaic and primitive JavaScript development environments available today.

It is mandatory that all further code development for JavaScript will remain inside the Smalltalk image so that it becomes part of our comprehensive libarry of application classes.

We assume that using the proven Lex and YACC tools could be the best viable path but we are open for alternatives as long as the code development stays fully inside Smalltalk.

We plan to enhance this translator ASAP with tools, utilities and a generator for Ext JS UI config data resulting in a highly productive and, under current terms, unique environment for JavaScript as a commercial product. Because of this, we would prefer some kind of lomg-term partnership.

The background

In today's browsers, JavaScript can be used to build RIAs and through Joose, it can be employed in a truely object-oriented style. Java is on the decline and no alternative for many reasons.

Unfortunately, today's JavaScript development environments are decades behind what Smalltalk has been providing more than 20 years ago. Efficient and truly object-oriented software development is practically impossible with these archaic Stone Age JavaScript tools.

Smalltalk comes closest to the panacea programming language. It is the most sophisticated, most comprehensive and most productive software development environment available.

Our Smalltalk class library has over 10.000 application classes with about 205.000 methods. This code includes also a web server in Smalltalk that serves the JavaScript RIA at runtime.
This existing code is not supposed to be translated. But it makes clear why it is mandatory that the code both for the server (in Smalltalk) and the client (in JavaScript) comes from one source.

We will develop new Smalltalk code specially for JavaScript. This code must be embedded into our existing classes and we must re-use our comprehensive tools and our configuration system.

Mid-range plans

We are planning to extend the translator to a unique JavaScript development environment that offers many more new features and tools. Special emphasis will be on automating the design of RIA UI in Ext JS. We have very concrete plans but we don't want to disclose details by now.

A lot of our existing code can be re-use for this. Our Elepub can be enhanced to act as a totally new type of database publishing generator of RIA UI and all content in one application.

We see a large market for these tools as a commercial product for serious professional JavaScript developers. Another market will be the community of software contributors that we will build up not only for EleFamily but even more for some unique innovative and browser related products that are currently under development and that will be introduced later in 2012.

Why not use any of the existing approaches?

None of the existing attempts meets our requirement that all sources are developed and stored inside the VisualWorks Smalltalk image. Most appear to be just experimental anyway.

The only tool that could provide this is ST2JS developed by Diego Gomez in Argentina in Squeak. Unfortunately, it is very closely bound to Squeak and it was given up at an experimental stage.

All the other approaches, especially the attempts to develop Smalltalk for JS inside the browser, may be academically interesting but are of no practical use for us in real product development. We see absolutely no sense in moving our development away from our very powerful and rich Smalltalk to some minimal, isolated and primitive new tool in the browser. That would mean several steps back. We don't understand why developers have choosen this approach rather than developing a good translator from within Smalltalk, which should be a lot easier anyway .

Overview on planned steps and releases

This is just a first raw plan. Most of these steps and details can be discussed and changed. Please note that the author is an application architect and developer using OOD since 1986 !!! but with only little theoretical knowledge of language grammar, syntax parsing, or "compiler stuff".

Release 1

Release 2

Release 3

Not needed

The other pages

Smalltalk references
Needed Smalltalk features
Grammar and syntax etc