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
};
$.ajax({
"type": "POST",
"dataType": "json",
"url": "/echo/json/",
"data" : {
"json": JSON.stringify(obj)
},
"success": (data) => {
alert(data.three.threeOne)
}
});
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.
