# Web terms [![hackmd-github-sync-badge](https://hackmd.io/eAomrtSKT8KWBfoN5vIzGw/badge)](https://hackmd.io/eAomrtSKT8KWBfoN5vIzGw) ## Ways to deliver HTML from the server to a browser - **Static Web Page** - page that already existed somewhere as `.html` and you are sending it as is, sometimes modifying headers and appying gzip (or other) encoding, encryption (SSL) and routing (redirects and rewrites), but not much more than you would expect a CDN server can do. - **Dynamic Web Page** - page that is generated by some sort of software (importantly this software is more capable than just regular CDN software) during request time. So your hosting should be able to "run" your application files, that could be `.exe`, `.php` or `.js`, but could also mean that you are configuring some 3rd party app that your hosting provider "runs" for you. This category already has some middle ground where it's hard to say which is which and it can already mess up with your perception. Because to write my static web page with Github Pages I'm going to author it in `.rb` to generate it with Jekyll, but if I put static `.html` file in my S3 I'm going to run slightly more complicated software than a "regular CDN" (validating signed token for example). How people de-facto separe the two is with the perception of execution time per request. Static pages were prepared in advance and can be delivered quickly and cheaply, Dynamic pages are prepared during request time. --- In practice Static vs Dynamic just means that if you have 10x traffic to your website are you going to pay 10x in your compute costs? If yes, probably **Dynamic**. And if you need to add 10x more pages to your website are you going to store 10x more html files on your CDN? If yes, probably **Static**. ## Ways to describe interactivity of the page once it's in the browser - **Static Page** - once the page is loaded in the browser it will not be interactive more than you would expect from built-in browser functions, for example you can click links and interact with forms and (sometimes) have interactions performed by CSS - **Dynamic Page** - page that has interactions custom to the website you are on instead of using browser built-in. This is a very broad category, I would say if your page is doing `document.write` or interacts with [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) you are in it. - **Web Application** - technically a subset of **Dynamic Page** but charectirized by a *feeling* of the app taking over the page. This could be because of the technical implementation detail like using [Flash](https://en.wikipedia.org/wiki/Adobe_Flash) or [Stadia](https://stadia.google.com/gg/) or just shere scope of customization like [Flutter Web](https://flutter.dev/multi-platform/web) or (especially early days) the fact that application overtakes some of the browser concerns like page navigation (**client side nagigation**) or native UI elements (custom select/dialog/alert). This category is very tricky, because how hard it would be to find a page that would be truly Static. So people give a lot of affordances to that category, so is the page still static if it feels static but for example downloads 1 megabyte of google analytics code? You can't see it there unless you notice slight delays or open your dev tools. Also you can do A LOT with just CSS these days. And obviosly because of how broad Web Application and Dynamic Page categories are in the modern web it feels kind of pointless trying to define them, or try to differenciate. --- In practice, will your application work the same if you disable javascript in the browsers? If yes, it's probably **Static**. Will a lay person be able to tell if you are showing them a browser or a native mobile/deskop app? If no, it's probably **Web Application**. ## TODO - Routing approaches - server routing, client routing - other: SSR, SSG, SPA, MPA, Transitional apps - other: server only, client only, progressive enhancment - vercel/next specific: ISR, SSR, SSG - streaming: Streaming HTML, Streaming JSON, Streaming JS - other: monolith, micro-services, micro-frontends - interop: web components, iframe, separate routes, micro-frontends - hydration: isomorphic, resumability, RSC, islands, automatic islands, partial hydration, progressive hydration, no hydration - SPA fallback: no shell, static shell, Partial Prerendering - rendering environment: edge rendering, serverless, servers - prerendering ideas for terms: - https://2023.stateofjs.com/en-US/usage/#js_app_patterns - https://web.dev/articles/rendering-on-the-web ## License <p xmlns:cc="http://creativecommons.org/ns#" xmlns:dct="http://purl.org/dc/terms/"><a property="dct:title" rel="cc:attributionURL" href="https://github.com/JLarky/web-terms">Web Terms</a> by <a rel="cc:attributionURL dct:creator" property="cc:attributionName" href="https://github.com/JLarky">JLarky</a> is licensed under <a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1" target="_blank" rel="license noopener noreferrer" style="display:inline-block;">CC BY-SA 4.0<img style="height:22px!important;margin-left:3px;vertical-align:bottom;" src="https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1" alt=""><img style="height:22px!important;margin-left:3px;vertical-align:bottom;" src="https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1" alt=""><img style="height:22px!important;margin-left:3px;vertical-align:bottom;" src="https://mirrors.creativecommons.org/presskit/icons/sa.svg?ref=chooser-v1" alt=""></a></p>