Times have changed. Interactive websites are at the heart of a lot of businesses and no longer an afterthought tacked on after the “real” development has been completed.
JS and HTML
On traditional web apps it worked mostly like this:
- The server spits out HTML which is the baseline and users should be able to use the app/website even with JS disabled
This meant that the widgets the frontend developers built were really hard to test, due to the fact that HTML and JS were largely separated. The widget expected a certain kind of HTML to operate on and if this structure wasn’t there, mostly the JS widget would just not work.
Activating one of these widgets would often work something like this
and this would assume a DOM structure which would look something like this
<div class="my-widget"> <input type="text"> <div class="dropdown"></div> </div>
But a new style of programming the DOM, fuelled by the rise of client-side MVC frameworks like Backbone, came into being: the UI became parcelled up into components, views or whatever you might want to call them. This meant that a frontend developer wouldn’t have to build a certain HTML structure and then call some jQuery plugin on it.
Instead, the HTML isn’t rendered on the server but the component you are trying to build comes with its own HTML. Rather than the above you would do something like this:
var view = new DatepickerView(); var rendered = view.render(); $(".my-widget").append(rendered);
Can you spot the difference here? The component itself brings its own HTML to the table instead of manipulating some globally available DOM.
How is this different?
If we write our UI widgets in this style testing is rather easy. Before, if you wanted to really test your JS you had to test both the HTML the server produced as well as the widget code that operated on it. That would mean to somehow also build up the entire context of the server-side templating language and render a full response.
Whilst before you were never quite sure that the HTML you produced was matching the expectations the JS had, it is now rather easy to assert against the widget.
This new-found engineering rigour means that JS code can be as easily tested as server side code, if not easier. What has made the difference is the coupling of JS with the HTML it operates on (and produces). In my opinion, that’s the qualitative distinction.
In fact, if all your server produces is JSON asserting against that becomes easy too. You no longer have to do some DOM gymnastics to find out if your server has generated the correct response: just parse the JSON and assert against that.
Nowadays, JS-heavy projects are thought of as API clients to the server that
produces JSON. This has enabled a style of frontend development that takes
raw data as its input and not data mixed with a sprinkling of presentation
layer. I think that this is a good thing. Frontend developers are now
writing programs, apps and no longer just spice up your