# Single-page Applications AKA JavaScript eats the world --- ## Brief history of web dev --- ### Back in the day: server rendering (SSR) What we've done with Node so far: 1. Browser requests a page 2. Server does some processing 3. Server responds with HTML for browser to render --- ### MVC "Model View Controller" is the old-school architecture: - Controllers are handlers that receive user input and ask model for data - Model looks after data access/storage - View takes data from the model and renders it into an HTML template --- Generally the browser is a "thin client". It just displays what the server gives it and handles no logic. --- ### Client-side enhancement Client-side JS used to add some interactivity (modals etc) but the heavy lifting is done server-side. --- ### SSR advantages --- #### Simplicity Browsers handle a ton of stuff for you - Routing (links, loading new content, caching, back button) - Submitting data (`<form action="/submit">`) --- #### Other languages You can write server code in any language. Vast majority of servers don't use Node (PHP, Ruby, C#, Python, Java etc) --- #### Hardware Web servers usually run on powerful dedicated hardware. Client-side code runs on the user's device (generally underpowered mobile phones). --- #### Security Server code is hidden from the user. No access to secrets, API keys, database access. Can't trust any code executed in the browser (e.g. because of devtools) --- ### SSR disadvantages --- #### Perceived performance Everything requires a network round-trip to the server and back. Full page loads can make interactions feel slower. --- #### Interactivity Hard to build dynamic interactive "apps" that compete with native mobile. --- #### Maintaining a server Deploying, securing and maintaining a server can be difficult (and expensive). --- #### Separate devs Historically backend has been a separate skillset. Different devs writing different languages can be expensive/inefficient for companies. --- ## Single-page applications (SPAs) All the logic runs on the client. Only one request for HTML: the first page load. After that all templating and page creations happens in JS in the browser. --- ### Architecture MVC is less relevant. Generally the model is still server-side (for database access), but logic and templating is client-side. `fetch` data from JSON APIs (either 3rd party or in-house) and use that to render. --- ### SPA advantages --- #### Perceived performance No network round-trips to render new "pages". Once the JS has loaded you can render new stuff almost instantly. --- #### Interactivity Much more complex dynamic interactions are possible as you can immediately update small parts of the page in response to user action. E.g. filtering a list, deleting a single thing, animated page transitions are all easier without full page reloads. --- #### No server If you're only using 3rd party APIs (or fetch no extra data) then you don't need your own server. Can use high-performance (free!) static hosts like Netlify for your HTML/CSS/JS files and lose all the complexity/expense of managing a server. --- #### "Full stack JavaScript" You can have the same software engineers write your frontend and backend code if it's all in JavaScript. --- ### SPA disadvantages --- #### Complexity Building a non-trivial app in client-side JS is tough. Managing ongoing "application state" as the user browses is complex. Server rendering can be much simpler for sites that don't need tons of interactivity. --- #### Mandatory JS You can't run any language but JS in the browser. There are some compile-to-JS languages, but the final output must be JS. JS isn't necessarily the best language for some stuff (e.g. precision currency calculations). --- #### Hardware All your code executes on whatever device the user browses with. This is often a £100 low-powered Android phone with a CPU from 5 years ago. JS is _expensive_ to parse and execute. --- #### Security If all your code executes in the browser you can't hide anything (like API keys). You also can't trust any user input. --- #### Initial load speed Generally SPAs render all elements with JS. This means until your JS loads (if it loads!), parses and executes (with no errors!) your user will be looking at a blank screen. --- #### Heavy page weight Putting _all_ app logic on the client forces every user to download a full copy of your app's source code. 1. slow network connections will take a long time to download the JS 2. under-powered CPUs (e.g. on phones) will take a long time to parse JS --- #### Search engine optimisation Google's crawler does understand JS, but it 1. uses a really old version of Chrome 2. does a first pass without JS so you'll get better SEO by having some HTML available before JS loads. --- ## How do frontend frameworks like React fit in --- Help manage complexity. Give everyone a shared structure so you don't reinvent the wheel. Also they often abstract away the DOM.