WeBlog
  • Agile Trends
  • People & Organization
  • Tech & Digital
  • Transformation & Change
  • EN
    • FR
    • EN
    • NL
No result found
View all result
Discover Wemanity
WeBlog
  • Agile Trends
  • People & Organization
  • Tech & Digital
  • Transformation & Change
  • EN
    • FR
    • EN
    • NL
No result found
View all result
Discover Wemanity
WeBlog

Isomorphism, and How to Bring Your Webapp to the Next Level

Wemanity by Wemanity
5 years ago
in Tech & Digital
Reading time: 5 mins read
Picture of code lines representing isomorphism

Isomorphism or how to handle complex webapps development with both front & server rendering?

A brief web app history

Under the dinosaurs area (I mean a long time ago, before 2010), Web used to belong to the server (I will not speak about flash). Front-end development was not a job, all app logic was handled by the server in a server specific language (php, C#, java…). JavaScript was just here to bring some sugar to the pages, with the help of jQuery (slideshows etc.).

No problems then, but not a very friendly environment for webapps, constant page reloading, poor UI interactivity and reactivity, heavy bandwidth usage etc.

And here came the JavaScript MVC frameworks (AngularJS, Backbone, Amber…), revolution!

Goodbye server side rendering and hello single page applications! No more page reloading, more reactive and complex interface… But all that goodness came with one painful cost: Initial page is just blank.

  • Longer perceived loading time (with the Flash Of Unstyled Content, aka FOUC). Obviously all JavaScript has to be loaded before rendering start.
  • Poor SEO. Despite of the enhancement of Google crawler JavaScript interpretation, single page application SEO is still very poor and uncertain.

So we fall into a hybrid approach almost every times: serve a fully or partially rendered page to the client and then take over with complex JavaScript.

Every developer who did that know how the Hell it is to build and to maintain. Many pieces of code (string formatting, templates…) have to be written on the server (in php, java, C#…) and on the client (JavaScript). You inevitably ends up with errors.

Here came NodeJS

With the revolution (once again) of NodeJs, a magic thing occurs: we can execute JavaScript code on the server. Yes, the same exact language which is executed by browsers.

Imagine you could, on the server, get your front JavaScript code, write something like “App.render()”, exactly the same way you do it on the client, and end up with a fully rendered page?

That what is Isomorphism, the JavaScript application of the old well known java paradigm “Write once run everywhere”. You write your logic one time in JavaScript, render it to string on the server, send it to the client and then execute the same application on the client.

Practice over theory

Look simple and obvious, but an issue quickly rise, the DOM.

Indeed, many popular JavaScript libraries heavily depend upon the DOM, which do not exist in server environment. Frameworks like AngularJS or jQuery are not environment agnostic, they depend upon the DOM and thus can be rendered only in a browser.

That’s why a new kind of view framework appear: ReactJS-like frameworks.

These frameworks abstract the DOM, so every piece of the app can be renderer to string.

Another gap is still there (at least for a NodeJS driven app). The language is the same, but there are still differences between the NodeJs dependencies management, driven by npm and require([modulename]) and front end, driven by bower and import statements.

Here come some nice tools to our rescue: Babel, Webpack and Browserify. These tools mimic the NodeJs dependencies management for the browser. They pack all your app into a single file, browser compliant application.

Grasp the ideal architecture

There is some all-in-one frameworks for building Isomorphic applications, like Meteor, but I will present a more tunable and handcrafted architecture.

For example I set up a little git project implementing these features :

  • Server-side rendering
  • Standard rendering server (for performances comparison)
  • Standalone rest server (API)
  • App working on browser without javascript (try is by disabling js in the dev console)

The view

The ideal is to have a standalone NodeJs server, the entry point of the app. It would be handling first user request, rendering template (Written with a framework like ReactJs) and serving rendered pages and packed app files (with the help of Webpack) to the client. No data here, just views!

It is a good practice to ensure that the app runs well without javascript, it’s tricky but it brings reliability to the app.

The data

We would develop an API only server, with whatever language you want. This server will handle all application logic and data. As the server is only handling json or XML and no html it can be more performant than classic full stack framework (no heavy rendering libraries like twig or Razor, lighter dataflow).

Upload / Content / Images etc …

Uploads (images, files) would be stored on a specific server, like amazon service or similar.

Conclusion

Yes, isomorphism is not an easy thing to setup, but it is worth it, it brings to the user a huge enhancement in reliability and performance, and to the developer an easy way to maintain app.

Moreover isomorphic architecture presents some very good side effects: a complete separation of concern. You have independent tiles doing only one task at a time. So very maintainable, easily expandable (imagine you want to add a mobile app tile, you already have a working Api and uploads management).

With the arrival of Angular V2 (which is not as coupled on the DOM as V1), the acceleration of NodeJs development and new ES2015 browser and server capacities, isomorphic JavaScript should evolve more quickly and should be more and more used in a near future !

Sources and resources:

  • http://isomorphic.net/
  • http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
  • http://maketea.co.uk/2014/06/30/building-robust-web-apps-with-react-part-4.html
  • https://docs.google.com/document/d/1q6g9UlmEZDXgrkY88AJZ6MUrUxcnwhBGS0EXbVlYicY/edit

ShareShareTweetSend
Wemanity

Wemanity

The Agile Driving Force 💫

Related posts

Green motherboard, photographed with red-gelled flashes.
Tech & Digital

IT Panorama: A Lexicon for Non-IT People

We propose to give you all the answers to questions you never dared to ask an IT expert. We worked...

3 years ago
A drawing with the title "From doing to Being Agile", or how to make be more future proof in being an Agile organization
Agile Trends

Agile Makes You Future Proof It Facilitates the Digital Ever Changing Era

Agile as a whole makes organizations future proof. Agile organizations are highly responsive, able to keep up and excel the...

4 years ago
Get Your Docker Registry – Docker Hub, at Home, for Free!
Tech & Digital

Get Your Docker Registry – Docker Hub, at Home, for Free!

Docker containers are everywhere. You can find them on Docker Hub, Quay.io,… You can easily register a working container for your purpose...

5 years ago
A case with a sentence "How was your day" and a green and red smiley in the two borders of a line, representing of the KPIs we can use with the teams
Tech & Digital

Why Your Well-Paid Developers Hate Your KPIs

Stop using fancy KPIs tools and charts and hoping they will look at them. Maybe ‘hate’ is a strong word,...

5 years ago
Next Post
Get Your Docker Registry – Docker Hub, at Home, for Free!

Get Your Docker Registry – Docker Hub, at Home, for Free!

Quiz: How Agile Is Your Organisation?

Quiz: How Agile Is Your Organisation?

Comments 1

  1. Pingback: Get Your Docker Registry – Docker Hub, at Home, for Free! - WeBlog

Recommended

A guy standing before a paper board with post-its wearing a t-shirt "Back to the future"

What companies can learn from “Back to the future” (Part II)

December 11, 2018
Why Your Test Automation Fails, and How to Succeed

Why Test Automation Fails (And How You Can Succeed)

May 19, 2016
The DeLorean from "Back to the future", used by Marty and Doc to travel in 2015, the future of 1985, which doesn't correspond to the 2015 we know. It shows the importance of flexible plan

What companies can learn from “Back to the future” (Part III)

December 18, 2018
2 people standing in front of a White Board, visualizing a workflow with post-its. It represents the most up-to-date information, or documentation

The Power of Visualisation over Documentation

October 9, 2017

Categories

  • Agile Trends
  • People & Organization
  • Tech & Digital
  • Transformation & Change

Categories

  • Agile Trends
  • People & Organization
  • Tech & Digital
  • Transformation & Change

Join our community and receive our newsletter.

Rejoignez notre communauté et recevez nos dernières actus.

Sluit je aan bij onze community en verkrijg onze newsletter.

No result found
View all result
  • Agile Trends
  • People & Organization
  • Tech & Digital
  • Transformation & Change
  • EN
    • FR
    • EN
    • NL