More than 1 year has passed since last update.

2023年現在のBlazorに至るWEB技術の歴史というか雑なまとめ

Last updated at 2023-05-08Posted at 2023-05-07

これはなに？

WEBの、特にフロントエンド界隈の技術を取り巻く歴史をまとめてみた単発資料です。
自分の学習哲学として「技術を知るにはまず歴史から（※）」というものがあるため、Blazorについても取り急ぎまとめてみました。

※話が長くなるので手短にしますが、技術は「それが何を乗り越えようとして生まれた技術なのか」という歴史的背景を踏まえないと理解できません。それが何の役に立つのか、（今ある既存技術の）何を想定していなかったのか、当時あったどのような問題を解決したのか、なぜ流行ったのか、歴史の流れに埋もれたのか現役なのかこれから埋もれようとしてるのか、といったことは歴史を知らないと理解できないし考えられないのです。
生まれたときからスマホが身近にある子供たちが、ポケベルの技術的価値を理解できないのと同じ現象が、実はエンジニアリングの世界でもいろいろなところで起きています。

Blazorについて考えるのが主旨なので、C#以外の言語や、Blazor以外のWebAssembly関連技術については調べていません。Blazorに対しては近いポジションのJavaか、Rubyあたりが復権して対抗馬になっていくのではないかと考えていますが、Blazor + .NET + Visual Studioレベルの開発環境があるのかどうかよくわかっていません。Rustに至ってはWebAssembly界隈の盛り上がりは観測していますがUI分野においてどのようなツール、技術スタックが存在するのかもよくわかっていません。

上記の周辺知識に関して、ご存知の方がいらっしゃいましたらコメントください。また、Version番号とか発表年が違うじゃないか、けしからん！　というお声も歓迎します。資料をアップデートできるかもしれません（し、しないかもしれません）。

Blazorを取り巻くWEB関連技術とトレンドの変遷

大まかな流れ解説（※個人の感想です）

MicrosoftのASP.NETは実はインターネット初期から始まっており、1996年から続く技術（プロジェクト？　ブランド？）である。ただしクラウドとOSSの隆盛により途中で方針転換が起き、Windows Serverと.Net Frameworkという自社リソースのみにこだわるのをやめ、Linux化とOSS化というパラダイムシフトを自ら起こすに至った。これにより.NETおよびASP.NET Core（どちらもGitHubでリポジトリが公開されているし、実行環境はWindowsに縛られないマルチプラットフォームである）が現在MSのアプリケーション開発の主流となっている。その過程でXamarin（Mono）の買収と.NETの標準化という動きがあり.NET Standardが策定されたが標準化作業は一定の目的を達したらしく2.1で完了ということになっている。
WEB2.0などと持てはやされたことは（オジサンには）記憶に新しいが、リッチなWEB体験を求めてまずPCのWEBブラウザ上の表現力向上が図られた。その結果としてFlashやSilverlightといった実行環境がブラウザのプラグインとしてリリースされたが独自仕様の域を出ず、iPhoneの登場とスマホの普及、HTML5という新しい標準の登場で歴史の流れに消えていった。結局今はHTML Living Standardという形で標準が統一され、この過程でIEが（惜しまれずに）消え、MS、Google、Mozilla、AppleがW3C標準の元に手を取り合うという一昔前（いつ？　……うーん、2010年代前半かな）では考えられない奇跡も起きた。内実どうなのかは良く知らないが、外部から観測される事象は「平和」そのものと言えよう。へいわがいちばん。
上記と同期してJavascriptはリッチなWEB体験を生むための画面制御に不可欠な技術となり、その重要性は現在も高まり続けている。AJAXだRSSだなんだとゼロ年代に言っていたのが、急にブログ文化からSNS文化に移行し、React、Vue、Angularの3大WEBフレームワーク（※注：私が勝手に呼んでいるだけです）が急速に勢力を伸ばし時代は変わった。このJSフレームワークが三つ巴の争いを繰り広げている状況が今のSNS戦国時代という認識（※個人の感想です）。でも今はいろいろなWEB表現が出し尽くされて、カンブリア大爆発が落ち着いた後の「新しい生き物が出てきたけど目の数は同じだよね」みたいな状況とも言える（※個人の感想です）。
Javascriptがここまで普及してしまったことは功罪相半ばするようだが、中でも「型システムの支援が無い」ことはJSで開発をやっていく上で困難だったのでTypeScript が生まれた。TSはMicrosoftが生み出した言語だったので発表当時「MSも変わったな」などと思ったものだ。TSは多くの問題を解決し支持者を生み出した。また、Node.jsという環境も生まれた。Node.jsは「npm便利だなー(^q^)」くらいの知識・経験しか持ち合わせていないので言及を避けるが、とにかくJSというスタンダードを使いやすくする、適用範囲を広げる動きがここ10年くらい積極的になされてきた。それもこれもJSが遅く大規模開発に向かない言語だったからだ（※ミスリードになってしまうので注意しておくが、だからと言ってJSがWebAssemblyに対して極端に遅いというわけではない。問題は実行方式だったわけで改善の余地はあるし、スクリプト実行言語すべて悪、という見方は短絡的に過ぎる）。
JSに起因するWEB表現の「遅さ」や「効率の悪さ」に対して真面目に取り組んだ人たちもいて、それがNaClやasm.jsといったブラウザ上でバイトコードを実行できるようにしたり、他言語をJSへコンパイルして実行できるようにしたりする動きだ。これらの技術についても詳しくは知らないので詳細に立ち入るのは避けるが、これらがWebAssemblyを生み出す原動力になったそうだ。結果としてWebAssemblyはW3C標準となり、全てのブラウザが搭載すべき機能となった。ジャンプよろしく「ブラウザが読めるのはJavascriptだけ！」という長く続いた状況はこれにて終焉を迎えた。世はまさに、大バイトコード時代！！！（ド　ン！！）
WebAssembly界隈で特異な輝きを放っているRustについてはこれも触れたことが無いので言及は避ける。だが、やはり型システムの支援があり、メモリを安全に扱えて、マルチパラダイムで、速い言語というのは需要があり人気を得るのは当然と言える。私は都合上C#派だが、Rustの未来にも栄光があってほしい。……あと本当は「WebAssemblyはLispじゃねーか！　やっぱLisp最強！！！」という与太話もしたいのだがこれは本当に我慢する。
そういったいろいろな歴史的な経緯の結果、Blazorという技術は結実している。Razor構文というものをMSが持っていなかったら、LinuxやOSSへのシフトをしていなかったら、WebAssemblyという技術が開発されずW3C標準を取らなかったら、おそらくBlazorは存在しなかったか、現在のような形にはなっていない。

おわりに

近頃ChatGPTでMSがまた覇権を取りそうな勢いだが、ビル・ゲイツ後のMSは時代の流れを乗り切った、と言えやしないか。言い過ぎだろうか。いや、Blazorに対する期待はそれがホンモノだと思うからだ。

参考文献

追記

WebAssemblyおよびBlazorに対するよくある誤解というか過剰な期待として「JSより速い」というイメージがあるが、どうもそうではない。もしそうであればベンチマーク結果が、それこそQiitaあたりで大々的に紹介されていてもおかしくなさそうだが、そうでもない。そもそも「速度」の単純比較に意味があるのかどうかもわからない。

つまりどういうことかというと「直接DOMを操作できないWebAssemblyと、近年十分に高速化されたJSとでは、単純な比較ができない」ということだ。例えば何らかのベンチマーク関数（竹内関数とかコラッツ数列演算関数とか）を使ってある端末内で処理速度を比較したとしても、それがChromeやEdge上でのSPAの画面切り替えやヌルリとしたアニメーションの「速さ」にどれだけ相関性があるのか、には疑問が残る。第一、人やNWはベンチマーク関数ほどのオーダーで処理できない。同接10万人の負荷テストみたいなことをしたら結果らしきものは出せるかもしれないが、今のところそんなデータも見当たらない。

であれば、JSフレームワークではなくBlazorを選択する積極的な理由は何かと言われればそれは「開発効率」だと言える。現代的なアジャイル・スクラム型の開発スタイルとCI/CDによってサービスを成長させ続けるにはそれが最も大切だと言える。コード量と技術スタックが小さいということは、機能追加も作り直しも、開発に関わる全てが「簡単で速く」なる。これが2023年時点でBlazorの持つ最も強力なメリットだろう。

速さはチューニングできる。むしろそれをすることがエンジニアの腕の見せ所ではないか。

なお、余談ではあるが、私は最適化の力を甘くは見ていないので、最終的にWebAssemblyが速度の面でも勝利する可能性もあると見ている。WebAssemblyは新しい技術であり、ということは新しい最適化問題の宝庫ということだ。今はサンドボックスで囲われているためDOM操作ができないが、それも永久不滅の法則というわけでもない。WebAssemblyはW3C標準の元ブラウザ開発会社各社がもたらした奇跡だ。であるならば、今後も似たような奇跡が起きないとも限らない。そう思っていた方が面白い。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up