0

Let there be a static web application.

Let the following be a priority:

  1. First loading time (ignore cache etc)
  2. User experience
  3. Search Engine Optimization (meta tags & bot friendliness)

When writing a web application, there are two broad approaches:

  1. Single Page Application (AngularJS, Vue.JS, React, ...)
    • Benefits:
      • Load once, highly responsive UX
      • Less bandwidth usage
    • Drawbacks:
      • Relies on JavaScript (not friendly to bots that don't run JS)
      • Long initial load (may be render blocking)
  2. Multi Page Application (Traditional)
    • Benefits:
      • Friendly to bots
      • Lightweight (load only what you need for each page)
    • Drawbacks:
      • Loading when switching pages (hits UX)

A single page application can be made friendly to robots using server side pre-rendering, but that would mean the application is no longer static and would incur an operations (hosting) cost.

Given the priorities and possible options, which approach would be optimal?

  • If its static you can cheat, have a tiny first page which dynamically loads all the others. building up a spa – Ewan Mar 11 '18 at 20:33
  • What you're proposing is to have an MPA, but each page loads the entire app in the background in a non render blocking way, meaning when a navigation occurs the thing's already in the cache? – Ivan Rubinson Mar 11 '18 at 20:35
  • not quite, but something like that might work just as well. A lot of work to save a few seconds though – Ewan Mar 11 '18 at 20:36
2

If you use React, Vue or Angular(1.5+) and ES201(X) its very simple.

You make a separate module for each section in your application (e.g. user, order, products, etc...), than you make a root-entry-point (e.g. app.js) and a bootstrap.js where you do your complete bootstrapping process without dependencies of app.js.

if you use webpack+babel you can choose if you wanna have one entry point or multiple.

than you put on each index.js of module an if statement for e.g.

if(document.querySelector('#my-module-root').length) {
// ... import & load bootstrap
// ... render module 
}

so you can choose at the last step if you wanna make a complete spa solution (import all modules to app.js) or an mpa solution (load & bootstrap each module separate) by requesting a page from server and rendering each module separate.

there is no better one, it depends mostly on the size and resources of your application. e.g. your application has 10 modules with each 150 submodule with each 20 components, than the final spa file is very big, for sure you can chunk (separate in parts) the file but the user have to load your complete application.

if your application is slim you can do it as spa.

for bot´s and better ux (user experience) it´s better to render the javascript-application on the server (SSR = server - side - rendering). the user and the bot has a very very small longer loading (depends on the nodejs engine to render and the caching process in background) at the beginning and than the user and the bot see an consumable result, a few seconds later the client-side-js is loaded and the whole functionality is available. BUT(!!) There are many many small hints to build a SSR-MPA/SPA some parts working a lil different. if you dont familiar with SSR you better choose CSR (client-side-rendering)... It´s also possible with both variants (MPA/SPA).

i prefer the mpa solution, cause the most web-apps has module based resources like translations, privileges, etc... e.g. you have 2k descriptions in you translation and 500 privileges for the user, on an mpa you have to load the resources just for the module instead of the whole application.

an traditional mpa (no client side application, angular, vue, react...) is mostly a lil simpler to maintain, cause your complete business logic is at the server. BUT(!) the ux is less than an mpa/spa with client application and your browser have to render the complete ui for each single request/call/command...

EDIT: i forget a very important thing about SSR, if you have a lot (500+) users at the same time on your application, you have in mind SSR means your server make the same work as the client. the server renders 500 applications at the same time. this is not impossible with good caching strategy and outsourcing the rendering to a different server in your prv-network. But mostly you have other problems with scaling by 500+ users at the same time and you can scale/outsource this part later when you application grows and needs more resources...

sorry for my bad english ... :D

1

Its on point 2 that everything hinges and its subjective.

You can make a super fast MPA that looks great and does the job, but not if you want clever dynamic effects. That tends to require javascript calling services.

Having said that, most of those 'clever' effects revolve around pulling in dynamic data and updating in real time and you have specified a static app.

Clearly you could do some clever preloading tricks to get around the second page load etc in a MPA, blurring the lines between the two approaches and some browsers already do stuff like preloading links you haven't clicked on yet.

But you would really have to question the worth of the investment in development time vs buying more/faster/closer servers

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.