WPA 時代、Web browser 向けの DOM を作る
「DOM を作る」とは HTML text を作ったり ECMAScriptECMAScript.icon で DOM (document object model) を作ったりする事をここでは言ふ事にする。SSR (server side rendering) や virtual DOM 等を話題とする 方式
HTML text を書く
書く
(この樣に書くのは例。象徴例なのでそれぞれ同じ抽象度とは限らない。一つの例が複數の分類に登場もするから、その例がこの文書で省略してゐても必ずしもその分類にしか屬さない訣でもない)
authoring tool で作る
Dreamweaver
server side で (HTTP request に合はせて) 作る
Web server、application server で作る
application server やそれに似たもの
CGI (Common Gateway Interface)、FastCGI、PHPPHP.icon (※PHP-FPM (FastCGI Process Manager))、WordpressPHP.icon、Ruby on RailsRuby.icon (※Unicorn、Puma)、Jakarta EEJava.icon、ASP.NET (Active Server Pages .NET)、Phoenix LiveViewElixir.icon JSPJava.icon (Java Server Pages)、eRubyRuby.icon (embedded Ruby; ERB) の樣な template engine
HamlRuby.icon、PugNode.js.icon、XSLT (eXtensible Stylesheet Language Transformations) の樣な木構造を持つ template engine も大體ここ
Web server 上で組み立てる
Web server 上で application を實行する
nginx-luaLua.icon、nginx-mrubyNginx.iconRuby.icon
mod_perl、Passenger、Nginx UnitNginx.icon の如く主要であるがこの枠組みで分類し辛いものも有る
Web browser 上で DOM を作る仕事を引き受ける (SSR; Server Side Rendering)
新顏
ReactDOM.hydrate()、Next.jsNext.js.icon、Nuxt.js stream render
ReactDOMServer.renderToNodeStream()、ReactDOMServer.renderToStaticNodeStream()
reverse proxy、CDN (Content Delivery Network) で作る
proxy上で組み立てる
SPA みたいな速さで動作可能……
proxy 上で application を實行する
VCL (Vernish Configiration Laguage)、Lambda@Edge、Cloudfrare Workers、Akamai EdgeWorkers
dynamic rendering。crawler から access が來たら headless browser で render して返す
server side で作った DOM を、Web browser で編緝する
DHTML (Dynamic HTML)、XSLT、jQuery、document.createElement()
program で事前に作る
古典的 SSG (靜的 site generator。static site generator)
SPA を吐く SSG (a.k.a. Jamstack)
新顏
headless CMS (contents management system)
全面的にWeb browserで作る
新顏
Vue.js
Angular ($ \neAngularJS.icon)
Web Component
Web は document から application に成った
何故上記新顏が登場し流行するのか
document からUI (User Interface) へ
HTML は document を書くものではなく UI を作るものと成った
document は UI の中の content として有る
keywords
目指す方向性。native application の樣に UX (User eXperience) の好い Web application を作りたい、と云ふ心意氣
AMP (Accelerated Mobile Pages) の話を一瞬出したい
但し Web by Google
Google Chrome / Chromium もな?
AMP Email
Gmail を抱へる Google として。Email を application 化する
SPA (Single Page Application)
server と front との責務の分離
server team と front team とで communication が發生するから、兩方に跨る DOM 生成はどちらかに寄せるのが樂
一人で遣ってるとしても心の內での調整 cost が掛かる
server で document を生成し、Web browser で動きを附けるなら、server で HTML を作れば好かった
UI は大半が Web browser 上の動作に依り變更される (native application と同樣)
最早こちらが主
なので front に寄せる
server は headless に成る
副作用として、native application と Web application とで同じ API server を使へる
team 內向け管理畫面等 SPA 面倒と云ふ話は有る
performance
LCP (Largest Contentful Paint)
first view 內の主な content が表示されるまでの時閒
「頁全體が完全に表示される迄」と云ふ指標は Web vitals に無い
load 時以外にも遣る事は有るので、load 時に限った時の話
FID (First Input Delay)
最初に操作できるようになるまでの時閒
CLS (Cumulative Layout Shift)
表示されたものをガタガタ動かすな
これは style を作ったり弄ったりする時の注意であり、今囘の話題と遠い
單純に、どの手法はその指標に有利と云ふものは無い
作り方や瓶首によりだうとでもなりますね
SPA は js の size が膨れがちではある
二囘目以降の訪問時では Web browser の cache に乘ってる筈
但しSSGは一般に速い
Web browser の cache や CDN にまるごと乘せられるので
SEO (Search Engine Optimization)、SMO (Social Media Optimization) TL;DR
SEO / SMO で飯を食ってく (includes 我々) は SSR しなければならないでせう 「Google で檢索される爲」だけならば不要
SMO はどうやってるんだ? (UA 見て head だけ書いたりしてるのだらうか)