Why use a (custom) scripting language?

Traditional websites are built in the server and the finished HTML is then sent to the browser. This approach is tried and tested but suffers from some limitations. Firstly, all the work is done by a single computer serving a large number of visitors, even though these visitors' browsers have as much computing power as the server. This is a waste of resources; if some of the heavy lifting were transferred to the browser then the server could handle more visitors at once.

Secondly, when the user interacts with the page, in the traditional model the browser sends a request to the server, which then generates a new page. This takes time, often a noticeable time, and while it's happening the browser flashes up a blank screen. All rather clunky.

Thirdly, although it doesn't affect the user experience, the developer is dealing with code running on a machine a long way from his own terminal. When bugs occur it can be a tiresome job tracking them down. Seldom-visited parts of the code have an unpleasant habit of harboring all the remaining bugs and tripping over them at the most inconvenient times.

This website belongs to a relatively new class of site in which the controlling code is all running in the browser. In that respect it's like any other program that runs on your computer, except that the code downloads each time the page is visited, just like the HTML and the CSS stylsheets. When the program decides that it needs information held by the server it sends a request to ask for it, then it processes the result, usually without redrawing the entire screen, just one part of it. The user experience is as a result much smoother.

This particular website goes one step further. The only programming language understood by a browser is JavaScript, and the great majority of modern websites are built using a lot of JavaScript. The language is hard to learn and easy to make mistakes with, mistakes that can be very difficult to track down. A lot of effort has gone in recent years into building frameworks that wrap around JavaScript to give it extra features and to deal with complex data structures. React, developed by Facebook, is currently the best-known of these and the conventional wisdom now is that all websites should be built using it.

This is putting the cart before the horse. Most websites are not Facebook; they don't have thousands of programmers working on them so the approach that works for them won't fit everyone. Don't start with the system language; start with the user language. The structure, appearance and behavior of most websites can be described in plain English 'stories', and often are at the start of a project because this provides an audit trail that can be examined later if needed. EasyCoder is an example of a language that describes in very English-like terms what the program is doing; descriptions that can be compiled into working code. Scripts of this kind can be easily understood by website designers, developers and anyone else interested in knowing what goes on under the hood.

Each of the words in the language is a "wrapper" round some property of the browser and its environment. The DOM is the obvious place to start; each of its types has a corresponding variable type in EasyCoder. These variables can be attached to DOM elements of that type if you know the CSS ID of the element, or alternatively the variable can construct an element of that type itself and attach it to some other DOM variable. Commands are available to set properties, attributes, styles etc. and to handle events arising from interactions with the elements. All this is done with only plain English words; no mysterious braces, fat arrows, triple-equals or dollar signs are ever seen outside of a string variable.

Larger items of functionality can be represented by just a few words. JSON data can be read and written, AJAX calls can be made to REST servers and complex widgets reduced to a few simple interface definitions. All the code to handle the complexity is still there but it's hidden in the runtime layer, that supplies each piece of functionality on demand. Anything with an API can be turned into script code and few will ever see the complexity that lurks beneath.

This is not really any different to using JavaScript/React functions to encapsulate complexities, except in one important regard. When you build a project you create a host of special-purpose functions with names that describe their purpose, but these names really only apply to that project and any others in which you may personally use the same functionality. The functions you build and the names you give them are specific to your project, so they are unfamiliar to any other programmer. When you put functions into script, however, you are following the rules of the scripting language, so the meanings of the commands become familiar across all projects and little if no training is needed to use them.

Script keywords get used over and over again, so there are few places for bugs to hide once you get past the inevitable settling period. The keyword handlers use a small set of functions over and over again; tokenizers, symbol tables, event handlers and so on, and there's a central dispatcher for both the compiler and the runtime. So it's very easy to know where the program is at any point, and there's a runtime debugger that can pause the run and examine variables to help you debug your code. When an error does occur, mostly as a result of bad syntax tripping up the compiler, it knows exactly where the problem is and can offer hints as to the cause if it's not immediately obvious.

The benefits brought by coding with a high-level script are

  1. Faster development
  2. Less code
  3. Fewer bugs
  4. Better reliability
  5. Easier maintenance
    and the bottom line is, of course,
  6. Lower cost

In other pages I will describe the scripts used by this website and explain how it all fits together.