Scato Eggen
February 29, 2016
In the first part of JavaScript, the Universe and Everything, I tried to explain what JavaScript really is. In this second part, we’ll take a look at the things that are important for PHP developers that are trying to get a grip on JavaScript.
A couple of years ago, the term “full stack developer” became fashionable. It wasn’t enough to be just a PHP developer, you should be able to do HTML, CSS and JavaScript as well. Not everyone was happy with the idea, saying that this prevents developers from really mastering any one of the parts of the stack. It does address the problem of two teams working at cross purposes. So what are the things a full stack developers should know about JavaScript?
Turn-based execution model
When you take a look at Node, you might say that one of it’s keys to success is JavaScript’s turn-based execution model. This is ironic, since this is one of the most important gotcha’s for working with JavaScript in the browser.
When you execute a JavaScript program, execution runs from the top to the bottom, but that does not mean that the program is finished. The code that was executed can register timeouts and event handlers. Every time a timeout is reached, or an event is dispatched, the handler is executed. However, no two handlers are ever executed at the same time. Every handler has to await its turn, hence the name “turn-based execution”.
Users have grown accustomed to smooth interfaces with lots of animations and interactivity. To make this happen, it’s important that the application itself does not interfere with the rendering of the user interface. Since all JavaScript code is executed on a single thread, these two are already separated naturally. Because of the turn-based execution model, keeping the interface smooth is much easier than it used to be for example in Java. This partly explains the success of JavaScript in both the browser and on mobile.
Another important difference between how PHP and JavaScript works is that JavaScript applications are long running processes. This requires a slightly different way of thinking. Memory leaks, in particular, are something to look out for.
Single page applications
In order to create smooth interfaces, functionality has been gradually moved from the server to the browser. This started with client-side form validation, but nowadays, entire front-ends are built in React, which talk to headless Drupal back-ends, for example.
If all the functionality is implemented client-side, the browser only has to load HTML, CSS and JavaScript once and all subsequent communication with the server is done in JSON through a web API. This is what’s called a single page application (SPA). The browser doesn’t have to do a full page rerender, which makes the application feel more performant.
Note that the core of the application has not been made faster, it just feels faster. This is what user perceived performance is all about. Instead of waiting for the browser to load a page with search results, the user will get a spinner or some other kind of animation. The server can take the same amount of time returning the actual results, but because of the instant feedback it feels shorter.
A good example of the use of SPAs is the Airbnb site. If you look at the network monitor, you’ll see that everything you see is on the same page, right up to the moment you click a room. No doubt this increases the conversion.
One downside of SPAs is SEO. SPAs are not nearly as easy to crawl as traditional web applications, but this problem will no doubt be solved as more and more SPAs are built.
From DHTML to SPA
The choice between an SPA or a traditional web application is far from black and white. There is an entire spectrum in between. I haven’t been able to find good names for the different levels, so I’ll try to give them names myself.
Lot’s of times, you just need JavaScript to toggle menus and such. An example of a framework that provides this kind of functionality is Bootstrap. You don’t have to write any JavaScript yourself, just include the right attributes and classes in your HTML. I call this level DHTML, which is a reference to the origins of JavaScript.
The next level are AJAX applications. One way to do this is to download data or snippets of HTML rendered by the server. The user interface stays smooth because there’s no page refresh, but the application still runs on the server.
Then there is a group of applications in a weird sort of in-between level. Most of the pages belong to one of the first two levels, except for one or more pages that have a bit more interaction. For those pages, you can use an MV* framework. You don’t have to go all the way. For example: no routing, just one view, just one controller… but it prevents your front-end from turning into spaghetti. I call this the MV* level, for lack of a better name.
Finally, there are single page applications (SPA) that run almost completely on the client. For these applications, you would also use an MV* framework.
For each of these levels, you’ll need some server-side code that exposes the web API that the front-end needs. The difference between the levels is in the balance between the server-side and the client-side.
Server-side JavaScript
If we are using JavaScript on the client-side, why not use JavaScript on the server-side as well? Stay tuned for the third part of this blog post series, in which I will compare Node to PHP.