Story Driven Development with DSL and REST – Part 2 December 12, 2018

Part 2 - The power of DSL and REST

Placing a script in the page with the HTML is fine for simple websites, but it makes the source code visible for the world to see and to copy. Of course, this is true for any embedded code, including JavaScript in the page header, but DSL scripts are far easier to read. More importantly, the tendency now is to go for single-page designs, which result in much larger scripts that combine the features of what would otherwise have been several pages. Whether JavaScript or EasyCoder, the larger the script the longer it takes to download, and in the case of EasyCoder, to compile prior to running.

Both of these issues are dealt with by using REST. As supplied, EasyCoder comes with its own REST server in the form of a PHP script in the plugins folder. This manages content in any number of MySQL tables added to those already used by WordPress. The tables all share the same structure; an id, a name and a value, and one of these tables can be used to hold your scripts. Another can hold chunks of HTML for use by your pages, and a third your CSS definitions. Other tables hold data specific to the needs of your website.

An EasyCoder web page can comprise just 3 commands:

variable Script
rest get Script from
   cat `easycoder/rest.php/`
   cat `ec_scripts/name/main`
run Script

In this script the word 'cat' performs string concatenation, keeping the lines short enough to fit on a mobile screen. You would normally just put the whole thing into one long string.

The script declares a variable, performs a GET request on the REST server (asking for the item named 'main' in the 'ec_scripts' table), fills the variable with what it gets back then runs the script. Everything from this point on, including loading the HTML, is handled by the script. This is the ultimate in hiding your code from curious eyes, yet the script and the HTML are still easily accessible by anyone with the right accreditation.

Cute as this is it's not actually a very good way of organizing things. You should always deliver a web page as quickly as possible so the user sees something, in case they get impatient and click away from your page. If it's not the whole page then some part of it, just to let the user know it's on its way. So the initial page should contain just enough HTML to give an outline of what's coming; the title and the major content areas, initially empty. It should also contain enough of a script to get things moving. Much of this will be REST calls to load other scripts and HTML, so you're not giving much away by having it visible. There's probably a masthead logo, which takes time to download, so there's plenty of time for the script to compile and start work. The EasyCoder compiler is pretty quick; it's unlikely that any initial page of this kind will take as long as 100ms to compile. In most cases compilation will take under half that, so there's little to be gained by loading the initial script from the REST server as shown above.

Once the script is running it will start to display content; items that are either already in the initial page or called from the REST server. Multiple requests can take place simultaneously, so the pipeline is kept pretty full. The user will see the page load quickly then fill in with the detail.

The initial script will load more HTML, CSS and other scripts whose job is to handle interactivity. There's no need for these to be in place right at the start as few users start clicking before the page has loaded, and if they do it's OK for nothing to happen. The scripts can load after everything else; the chances are that images will still be arriving at this time. If you leave the browser command window open you can see the newly-arrived scripts compiling while you watch the page develop in its own window.

When you finish with a piece of HTML you can remove it by setting the content of its parent to empty. Similarly, when you finish with a script you can call its exit command, which removes it completely from the browser's JavaScript space. This makes it very easy to build a single-page website of unlimited complexity, that pulls in resources as they are needed and disposes of them afterwards.

Development implications

With JavaScript running a single-page design the entire codebase must be loaded up front. Whatever programming framework is used, the code will be bulky and complex for all but the simplest web pages. Load-on-demand, as described above, is possible to do in JavaScript but makes the code even more complex and harder to understand. By comparison, EasyCoder only requires its own JavaScript modules to be loaded in the head of the document; the total size of this is something under 150Kb depending what plug-in extensions are required. The initial script - the only one that has to be present from the start - is probably only a few kilobytes as it's only dealing with the first things the user will see. Other scripts may be larger, but a good rule of thumb is to keep them to 300 lines or less in the interests of easy maintenance. A script of this size will be around 10Kb and compile in under 100ms.

By loading code and HTML on demand and releasing it afterwards there is no limit to the size of a single-page design. New components can be added with little risk of their interfering with what's already there. You can even operate your own plugin mechanism that loads new content without knowing anything about its internal workings.

The key features of a DSL/REST combination are:

  1. It can give a lower startup time than conventional practices.
  2. Increasing the size of the site has no effect at all on the load time.
  3. The software is largely a formal version of the customer's own stories.
  4. Part of all of the development can be done by teams without extensive JavaScript skills.
  5. Ongoing maintenance and updates are far easier and less expensive to manage.

Other Tools

When you store scripts and HTML in a database you must have some means to edit them. EasyCoder includes a set of editor scripts for this purpose. Scripts are just plain text but for HTML we use the CKEditor rich text editor; you will need to download and install this yourself. You are of course free to choose any other tools you like and use them to edit your scripts and HTML fragments.

Categories: Uncategorized