Rapid Web Application Development with AppeX and the Chrome Development Tools

Part I. Motivation for the AppeX JSFile Externalization Framework

This short article serves a dual purpose. On one hand, it is an introduction to AppeX’s “JSFile” framework, which will be available in Cincom® VisualWorks® 8.2, and on the other hand, it is an exploration of the motivation behind the JSFile framework. In addition, it serves as a lead-in to a second article titled, “Using JSFiles in Conjunction with the Chrome Development Tools.” The goal of AppeX is to ease development of web applications. To aid in this goal, AppeX uses the strategy of keeping in step with the latest in web application development technologies, and the not unrelated strategy of “playing well with others.” The JSFile framework is one component of the strategy of fitting naturally into the broader web development ecosystem. It is an appealing prospect to leverage the powerful IDE and development philosophies of Smalltalk while not sacrificing the strengths of this broader JavaScript ecosystem, but it requires a delicate balancing act. Several approaches have been tried (such as transpilation, wrappering and various forms of HTML and JavaScript generation), all with strengths and weaknesses. So, even though AppeX is by no means the first to attempt to leverage Smalltalk in producing complex JavaScript applications, the AppeX approach is sufficiently unique; therefore, it may succeed in ways that other approaches cannot. This pair of papers illustrates the point by considering a RAD development style that AppeX can support primarily because of its underlying design. Many software application developers (and most especially Smalltalkers) have grown accustomed to a particular style of exploratory coding and development that is sometimes known as “coding in the debugger.” Conceptually, this development process is very simple:

Write “exploratory code” while fleshing out a skeleton application, halting code execution at any problem points, modifying the code in place in the debugger and then continuing on with code execution.
Repeat (A) until the application functions correctly.

For such programmers, web development and JavaScript programming can be frustratingly unlike “the programming in the debugger” description of development given above. Instead, web application development has historically followed a much more cumbersome process. Here is a typical web application development process:

Modify static files (JavaScript, HTML, CSS or the corresponding templates used to generate these files) and then save them.
Re-run the program and observe any new problems that arise.
Return to (A); that is, return to the tools, re-edit the files and code, re-run the program, observe the results and so on.

Many web developers who read this description will recognize within the steps described an implication of some rather tricky development work; namely, observing possibly incorrect behavior within one context (such as on a web page), trying to deduce the code processes that may have taken place in another context (such as in a file parser in a server application) that eventually led to the incorrect behavior, and finally making modifications from within yet a third context (such as in an editor for a text file). The main development pain points that these fairly typical web development steps introduce, as opposed to the “coding in the debugger” (that, incidentally, can be routinely performed in many non-web environments), are a large number of context and tool switches and slow iterations of making changes and testing those changes. To be sure, JavaScript and associated browser IDEs have been growing up, and “coding in the debugger” *is* to a varying (and ever-increasing) extent supported within particular web browser toolsets. JavaScript has slowly been coming into its own as a full-fledged object-oriented language, with the tooling for building robust enterprise applications and sophisticated “desktop looking” GUIs slowly catching up. AppeX is primarily designed and intended to facilitate the development and hosting of modern web applications, namely “single page” HTML5 web applications with complex JavaScript logic on the client (the web browser) and “AJAX” calls to the server. This approach dovetails neatly with the direction that JavaScript has been taking. Let’s consider the question of how AppeX can leverage a relatively recent example of these advancements, the Chrome Developer workspaces. The single most important concept to concentrate on in answering this question is that, in AppeX, “the JavaScript you write is the JavaScript you get,” or equivalently, that “your native JavaScript is incorporated untouched into the Smalltalk IDE.” “Incorporation into Smalltalk” consists mainly of the essential conceptual step of hosting on the server a representation of the JavaScript object structures that are required for a JavaScript-based GUI and application architecture. This “hosting” allows the JavaScript code and object relationships to be managed by Smalltalk’s unmatched IDE tooling and flexibility, while maintaining their essential “JavaScriptness” and “HTMLness.” In other words (and this deserves stressing), the AppeX web developer, in the role of web developer, stays a JavaScript and HTML developer, only with the additional advantages of having available Smalltalk’s ability to manage and introspect on that same JavaScript code. Thus the philosophy of AppeX is to insert *no* “translation layer” between the JavaScript and HTML that is written by the web application developer and that which runs in the browser. The role of AppeX is to manage the code, analyze the code and deliver the code to the web client, but not to change it. This non-interference by AppeX with the JavaScript code opens the door to allowing other IDEs to also read or change that same code, and is crucial to the further step of leveraging industry-wide emerging web development tools. In managing the code on the server side, one might be struck by the fact that the AppeX representation of the JavaScript hierarchies is class-based. As a partial explanation of this design decision, it is worth noting that, although JavaScript is an “instance-based” or prototypical language, most enterprise application developers nevertheless code with a decidedly “class-based” slant, and this carries over well into shallow, class-based JavaScript hierarchies. Whether this reflects a natural “ease of use” of class-based hierarchies as opposed to instance-based hierarchies, or merely a learned bias among application developers is a subject of debate. It may be pertinent that class-based programming tends to be “static” (i.e., not modified at runtime), whereas instance or prototype-based programming tends to be “dynamic” (modified at runtime). Therefore, the class-based programming structures are perhaps easier to read, understand and maintain. It’s also worth mentioning that ECMAScript 6 finalized in-built Class Semantics for JavaScript. Regardless of the reason, AppeX follows this class-based OO paradigm and “maps” the JavaScript code used on the client to Smalltalk “JavaScriptClass” hierarchies that are managed by the Smalltalk IDE. Because the JavaScript is not modified, but only managed by Smalltalk, the AppeX JSFile framework allows the web developer to work with their JavaScript code with external tools and have the changes reflected immediately in the Smalltalk environment (and in the web browser). This “externalization” of the Smalltalk-hosted JavaScript code thus allows AppeX to support powerful exploratory coding in conjunction with other tools. For instance, using AppeX, JSFile and Chrome developer tools, the developer can run their code, halt in the executing stack frame (whether on the server or the client, i.e., web browser), inspect and/or change the state of live objects in any of the execution context, make any necessary code changes and then continue with code execution. It is too large of a claim to make that AppeX enables exactly the equivalent of “coding in the debugger” as would be available in, for instance, a non-web Smalltalk development environment. However, what can be said is that AppeX and JSFile is a step in that direction. The next article illustrates a simple example of “coding in the debugger” with AppeX and Chrome workspaces.

Part II. An Example Debugging Session Using the AppeX JSFile Externalization Framework in Conjunction with Chrome Workspaces

In the previous article, we set the stage for this case study, wherein the developer uses Chrome Dev Tools and Chrome workspaces to set breakpoints in JavaScript, make changes directly in the Chrome Web Browser debugger and have those changes automatically imported into the Smalltalk AppeX IDE and hence into the web page on the next browser refresh. For the following examples to work, you will need to install a recent VW8.2 pre-release build. If you are a Cincom Smalltalk™ licensed customer, please subscribe to the CST Developer Program to gain access to the most up-to-date code. Step 1: Load the package AppeX-Examples. Step 2: Start up the “Examples” server, which includes the Counter example application. Step 3: Synchronize the AppeX JavaScript with the Chrome developer tools. This step actually requires three main actions.

open VW System Settings’ and navigate to the Web Development item.

VW Settings->Web Development->JavaScript->Supply JavaScript code from->script files Alternatively, one can execute in a workspace: Application codeComposer: JSFileComposer The default script directory in which AppeX will place the JSFiles is …image/appex/scripts, e.g. C:/vw8.2/image/appex/scripts (on OSX, this would be /Users/<yourUserId>/vw8.2/image/appex/scripts) The directory can be changed in VW Settings>Web Development->Script Subdirectory or by executing, for instance, Application class>>scriptDirectory: ‘myJSFiles’. This first step activates a JSFileMonitor daemon in AppeX that will monitor the selected directory for changes to be parsed and imported into AppeX. It will also cause any changes to the JavaScript made within the AppeX IDE to be written to the file system for access by external tools (including, but not limited to, the Chrome Developer tools). Finally, it will cause any application requested by a web browser to “externalize” its JavaScript by writing it to the file system in the selected directory.

Open the Chrome developer tools, and add the directory mentioned in step (1) (the directory that will contain the externalized JavaScript) to the Chrome DevTools workspace.

(Detailed instructions for using Chrome Workspaces can be found at https://developer.chrome.com/devtools/docs/workspaces.) Again, this directory is by default … image/appex/scripts. The instructions given on the website for adding the directory are included here for convenience: “To make a local folder’s source files editable in the Sources panel, Right-click in the left panel of Sources and select Add Folder to Workspace. This launches you into a file dialog where you can choose a new folder to add to your Workspaces. ” You will see a message in the Chrome Debugger saying “DevTools requests full access” to the directory. Select “Allow”. You can now edit any of the source files in that folder or its subfolders in Chrome.

The third and final file synchronization step is to map the file JavaScript system files to Network Resources.

The recommended way of doing this is to first request the network resources through your Chrome web browser by navigating to the URL for the application that you wish to work with, “localhost:8889/appex-counter/AppeX.CoreCode.js” Note that the externalized JavaScript files corresponding to the JavaScript code for an AppeX application will not necessarily be present at this point; they will be automatically generated when you first request that application’s URL from the browser. Once the JavaScript files have been generated by AppeX in the scripts directory, you can right click a JavaScript file in the Sources pane of the Chrome Developer tools, select “Map to Network Resource..” and then select the appropriate URL to establish the mapping. For instance, “AppeX.CoreCode.js” might map to the resource “localhost:8889/appex-counter/AppeX.CoreCode.js”. In general, after you’ve manually mapped one of the JavaScript files to a resource, the rest will map automatically. After mappings have been established, we’re ready to do some coding! Let’s set breakpoints in the chrome debugger and change the code when halted at them. When you refresh your browser, those changes will be reflected both in the browser and imported in the AppeX environment. Conversely, any changes made within the AppeX IDE will be written out to the file system and will be reflected in the Chrome browser upon browser refresh. Open the Chrome DevTools JS search box with Ctr-Sh-F (Cmd-F on OSX). Search for “Decrement”. Inside the callback function to the “click” event of the decrementButton, click to place a breakpoint beside “self.decreaseCounter();” Back on the Counter application display, click the button labeled “Decrement”. The debugger should halt at the breakpoint. Duplicate the line “self.decreaseCounter();” in the debugger, and save your changes with Ctr-S. Resume execution, and try pressing the decreaseCounter button on the web page. The Counter should decrease twice with each button press. So far so good, but so far, we’ve seen nothing beyond what Chrome devTools workspace provides without AppeX. Now refresh the Counter screen, and try pressing the button again. Still good, but still nothing exceptional. Next search You should see in the method definition the changes you made in Chrome, namely .click(function () { self.decreaseCounter(); self.decreaseCounter(); }), Now that we’ve seen how code changes in the web browser debugger are automatically reflected in the Smalltalk environment, it’s time to try pushing JavaScript code changes the other way. In the same Smalltalk pane, change label: “Decrement” to label “Decrementing”, and save your changes. Now, when you refresh your Counter application in the web browser, it will show the new label. t’s change the label again, but this time from the Web browser. Return to the previous search in Chrome devTools. Change the line .button({label: “Decrementing”}) to .button({label: “Decreasing”}) and ctr-s to save. Refresh your browser to see the change. You verify that the change made in the web browser propagated through the filesystem and Smalltalk IDE by again looking at the CounterClient>>buildToolBar method. Final Notes and Cleanup Although changes made externally to AppeX JavaScript remain in the file system, they will not automatically be “published” to Store (just as changes made to the JavaScript from within the AppeX IDE are not automatically published). Therefore, you must publish any changes to AppeX JavaScript that were made by external tools that you wish to save permanently to your codebase. If you want to remove external JS files and the changes they contain, you can either do so through OS tools or have the AppeX do it for you automatically by selecting the box “Delete script files when switching to Image methods”. Alternatively, execute the following in a workspace: JSFile This has been a bare-bones illustration of the capabilities that AppeX and JSFiles provide. The approach described in this article fits well into the future of rapid web application development, and with it, AppeX provides the means to integrate client and server debugging into a single, seamless development workflow.

Rapid Web Application Development with AppeX and the Chrome Development Tools

Part I. Motivation for the AppeX JSFile Externalization Framework

Part II. An Example Debugging Session Using the AppeX JSFile Externalization Framework in Conjunction with Chrome Workspaces

Related posts: