Dominic Myers, a senior UX developer at Arcus Global, describes an evidenced rapid prototyping approach for JavaScript development.

When asked which interface they started off writing JavaScript in, developers’ answers range from Vi, Emacs or Notepad; they might even mention online editors and the more modern IDEs or code editors such as Atom, Brackets or Sublime Text.

The writing of code has not changed - though that might transform - where the code is written, but changes constantly for many reasons: the dictates of an employer, technological improvements or even fashion.

What hasn’t changed is that the code becomes concretised in some manner, there is an artefact which a developer can point to and say: ‘This is the code I wrote’. In some cases, the code might not even be written as JS but, rather, in a different language such as TypeScript of CoffeScript, then transpiled into JS.

In the UK education system these artefacts of code act as ‘workings out’, evidence of the work carried out and a way of proving productivity for a coder. Importantly, they offer a way of mapping their thought processes as they developed the finished code.

Typical workflow

It is important to note that with the increased popularity of Node.js, not all JS code is for the consumption of a browser, but this is perhaps beyond this discussion. Browser-based JS developers typically start with some method of serving their code: either the editor / IDE can act as a server or it’s saved onto a server.

Once this infrastructure is in place, some further scaffolding is required. This is usually a basic HTML file with a script tag pointing to a JS file, or even code embedded within a script tag. The skeleton might be fleshed out with further elements which the JS might interact.

A serverless workflow?

This combination of a server and scaffolding has been replaced recently with the Read–Eval–Print Loop (REPL)-like environment of online code playgrounds like JSFiddle and alternatives. These allow a developer to dive straight into work, without having to worry about the underlying architecture.

JSFiddle has four panels for HTML, CSS, JS and the output. The JS panel can automatically include some frameworks/libraries. Other external resources can be referenced and included by URI.

JSFiddle allows the developer to keep a copy of their ‘workings out’ via versions. Fiddles can be saved and forked to share code. There is even an API which offers a way to search for a user's fiddles, and fiddles can be embedded, allowing the code to be shared easily.

Perhaps one of the most useful features of JSFiddle is the ability to mock AJAX requests; this example uses jQuery:

let obj = {

    "one": 1,

    "two": 2,

    "three": {

        "threeOne": 31,

        "threeTwo": 32


    "four": 4




    "type": "POST",

    "dataType": "json",

    "url": "/echo/json/",

    "data" : {

        "json": JSON.stringify(obj)


    "success": (data) => {




A playground

While it might be stretching the term ‘serverless’ to use it for JSFiddle, ‘Playground’ seems a perfect term. Developers can easily work up a proof-of-concept which can then be copied over to an editor/IDE.

Creating a fiddle is often far quicker than firing up a prototyping tool for illustrating a design concept. One thing that might be improved is the use of the developer console; when it’s opened the developer tools restricts the screen real estate unless it’s undocked into a separate window.

About the author

This blog is brought to you by the members of the BCS Internet specialist group and allows you to harness their skills, expertise and knowledge. The internet is ubiquitous and has a major impact on our daily lives, at work, at home on the move. The associated risks and security concerns are real, but the magic and advantages of the internet are significant.