You're in
Iker Hurtado's pro blog
Developer | Entrepreneur | Investor
Software engineer (entrepreneur and investor at times). These days doing performant frontend and graphics on the web platform at Barcelona Supercomputing Center

Approaching a challenging Single Page Application

6 Apr 2016   |   iker hurtado  
Share on Twitter Share on Google+ Share on Facebook
In this post I gather the highest level thoughts and technical decisions about the project based in my time of research. I link other articules that go deep into the topics introduced here, too.

I approach an interesting project about searching, discovery and visualization of materials: The Novel Materials Discovery (NOMAD) Laboratory.

It's my first project related to computational science; in particular, it's about computational materials science. It's an effort to unify codes, data and people in the field in Europe. My role in the project is to develop the web client of the Encyclopedia subsystem.

In order to give a rich and profesional user experinece, the web client will require very fluid behavior and rich functionality, and graphical-interactive views of the materials -3D representations included. This application fits in the trendy concept of SPA (single page application) web application.

It's an interesting challenge for me: this type of apps were unthinkable on the browser few years ago.


A short and clear definition:

The idea behind single page applications (SPA) is to create a smooth browsing experience like the one found in native desktop apps. All of the necessary code for the page is loaded only once and its content gets changed dynamically through JavaScript.

Because of the importance of understanding properly this type (SPA) of applications, I edited a brief introductory article:

Intro to Single Page Applications - ikerhurtado.com

JavaScript issues, libraries and tools

A SPA application requires a heavy use of JavaScript, of course. After diving in the JavaScript ecosystem trends I realized how fast it is evolving, mostly libraries and tools.

Aside from fads and noise, useful tools are emerging in order to solve the main JavaScript flaws: the language doesn't provide a convenient manner to structure/organize and reuse/uncouple code, what is very advisable for large projects. That is not rare: JavaScript was born as a toy language, to add small features in the browser as validations of forms and stuff like that.

Particularly regarding reuse and modularity of code, specifically in the use of modules, is where I see that things have changed a lot, especially after the success of node.js and its manager of modules (npm).

Main JavaScript issue: lack of modularity

I liked this extract from this article on 0fps.net to get started with the issue:

However, while there are many good reasons to use JavaScript, it has a reputation for scaling poorly with project size. In my opinion, the main cause of this is that JavaScript lacks anything even remotely resembling a coherent module system. This omission makes it inordinately difficult to apply sensible practices like:

  • Hiding implementation details behind interfaces
  • Splitting large projects into multiple files
  • Reusing functionality from libraries and other code bases

Fortunately there are two module management systems that solve that limitation: AMD and CommonJS. I link two comparative articles:

unscriptable.com » AMD versus CJS. What’s the best format?

Why AMD? CommonJS - requirejs.org

It seems that the second one (CommonJS) is catching recently. I extract a brief explanation of the article CommonJS: Why and How - 0fps.net:

The CommonJS module system solves all these problems. The way it works is that instead of running your JavaScript code from a global scope, CommonJS starts out each of your JavaScript files in their own unique module context (just like wrapping it in a closure). In this scope, it adds two new variables which you can use to import and export other modules: module.exports and require. The first of these can be used to expose variables to other libraries ... And you can import it in another module using the “require” function

Regarding tooling for client-side module management there are several tools available. My choice was Webpack. In the next post I gather info about this powerful tool:

Webpack notes - ikerhurtado.com

Vanilla JavaScript versus the library/framework mess

I've been some time involved in the JavaScript ecosystem and my intuition tells me that, in addition to fast innovation, there is a lot of fad and noise. I think the library/framework inflation distracts us from the relevant issues. That idea led me to write this post:

Less reuse code and more reuse knowledge - ikerhurtado.com

As said, the main issue of the browser development environment is the lack of modularity in JavaScript -that I'll manage with Webpack.

As for the remaining important issues for developing a Single Page Application can all be solved through knowledge application instead of external, non-standard and unsuitable software use:

  • The historical JavaScript language limitations or drawbacks are a myth nowadays using the ECMAScript 6 (ECMAScript 6 analysis for Encyclopedia GUI - ikerhurtado.com).
  • UI Views can be created without much effort by using standard technologies and applying principles and techniques for maintainable JavaScript components.
  • A suitable architecture for this particular application can be implemented easily applying proper architectural design patterns.

So, I will use pure JavaScript and standard APIs as much as possible and implement the patterns and techniques necessary to get a well designed and structured Single Page Application. I could use small libraries dedicated to solve concrete aspects of the application.

Regarding the browsers support, it seems it's not necessary to support old IE versions due to the fast pace of decrease in the use of those versions. A brief study:

Browser Statistics issue - ikerhurtado.com

Architecture and Code Organization

A very good introduction to what this section is about (from this great resource: singlepageappbook.com) would be:

... let's look at how a modern web app is structured from three different perspectives:

  • Architecture: what (conceptual) parts does our app consist of? How do the different parts communicate with each other? How do they depend on each other?
  • Asset packaging: how is our app structured into files and files into logical modules? How are these modules built and loaded into the browser? How can the modules be loaded for unit testing?
  • Run-time state: when loaded into the browser, what parts of the app are in memory? How do we perform transitions between states and gain visibility into the current state for troubleshooting?

I write this analysis down on this long article: Notes on SPA Design and Architecture (NOMAD Encyclopedia project) - ikerhurtado.com