Go to Qiita Advent Calendar Top
LoginSignup
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@minamo_labo(minamo labo)

なぜクロスプラットフォーム開発で、FlutterでもUnityでもなく「Web」を選ぶのか

Posted at

はじめに

この記事について

先日、OPFS内に保存したWebアプリ、ブラウザゲームを駆動させる開発・運用手法を解説した本をZennでリリースしました。

こちらの本ではOPFSジャックという技術的手法を中心に扱いましたが、Webのクロスプラットフォーム性そのものの掘り下げは文脈上控え目に抑えました。
本記事はその補足であり、同時に筆者自身の不完全燃焼解消のためのアウトプットでもあります。

筆者について

業務では.NetFrameworkやWordPressを扱い、趣味ではフロントエンド開発を続けています。
個人開発としてはMinecraftのModファイルに翻訳データを追加するWebアプリを個人サイトで公開済みです。
詳しくはこちらで自己紹介しております。

本記事で対象とするアプリの前提

本記事で対象とするのは、ブラウザ上で完結するGUIアプリです。
具体的には以下の条件を満たすものを想定します。

  1. GUI主体: コマンドライン実行・バックグラウンド常駐などは想定しない
  2. ブラウザで駆動: PWAを含むWebアプリで実装可能な範囲に収まるもの

これらの前提から外れるものは、そもそもWebアプリとして実現不可ですので、そもそも念頭に置きません。

この記事は、アプリをクロスプラットフォームで展開する際に、Webアプリ・ブラウザ向けとして作ることがいかに良い選択肢であるかを筆者目線で語る、ポエムです。
一般的なクロスプラットフォーム比較記事では、FlutterやReact Nativeなどのフレームワークが並びます。
しかし本稿ではあえて「Webそのもの」を選択肢として提示し、正面から論じます。
このWebを選択肢に加える特異性について、議論を誘発する意図はありませんので、その点をご理解ください。

TL;DR（忙しい人のための要約）

ここまでの前提を踏まえ、本記事の要点を簡潔にまとめます。

  • Webブラウザはクロスプラットフォーム基盤として盤石である
  • 標準仕様の徹底的浸透と継続する互換性、そして性能進化でネイティブに近い体験が可能になった
  • 結果、クロスプラットフォーム向けフレームワークやゲームエンジンを用いた場合に比べ、開発コストと維持コストは大幅に抑えられる
  • OPFSジャックはWebアプリを丸ごと格納・実行する新しい手法
  • OPFSジャックは資産保全・寿命延命・ChromeOSでのネイティブ化などWebアプリの新しい可能性を開く

詳細は以下の本文で解説いたします。
お時間のある方は、ぜひご一読ください。

余談: マルチプラットフォームとクロスプラットフォーム

筆者はこれまで、この両者を区別して使っていなかったんですが、厳密にはマルチプラットフォームとクロスプラットフォームは別のものという意見も散見されました。
本記事では、以下のように定義して話を進めます。

  • マルチプラットフォーム: 複数環境に展開する
  • クロスプラットフォーム: 同じコードで複数環境に対応

しいて言えば、クロスプラットフォームはマルチプラットフォームをワンコードで実現する手段、という関係性でしょうか。
結論を先取りすると本記事は、現状一番強固にクロスプラットフォーム原理(同じコードで、)を実現できているのが実はWebではないか、ともいえる話題です。

Webのもつ到達範囲の広さと高い互換性

アプリのクロスプラットフォーム展開を実現する手段は多様です。

  • アプリケーション開発用フレームワークの利用: Flutter, ReactNative, .NET MUIなど
  • ゲームエンジンの利用 : Unity, Unreal Engine, Godotなど
  • Webフロントエンド向け開発のWebアプリ: バニラのHTML/CSS/JavaScript, React, vue.jsなど
  • Webフロントエンドラップのフレームワーク利用: Electron, Ionicなど

例示したものだけでも相当数の選択肢があり、分類だけでも4種類となりましたが、これらをさらに大別すると

  • 実行環境であるWebブラウザがクロスプラットフォームで利用可能である: Webフロントエンド向け開発
  • 各プラットフォーム向けネイティブ(あるいはWeb)としてビルドして利用する: その他全て

に二分されます。

では、この実行環境がクロスプラットフォームであるWebブラウザを利用するWebアプリが、なぜ優れたクロスプラットフォーム展開手段となるのでしょうか。

OS/CPUの壁を超える到達範囲の広さ

各プラットフォーム向けネイティブとしてビルドするコスト

各プラットフォームのネイティブアプリとして別個にビルドする場合、ただ同一のコードをビルドするだけでは終わりません。

  • UI/デザイン差異の対応
    • スマホだから、PCだからという入出力差異だけでなく、OSの思想・設計由来でさらに各OSごとへの調整が必要となる場合があります
  • OS固有APIや機能の差異対応
    • カメラ、GPS、通知、ファイルアクセスなど、各OS固有の権限やAPI呼び出しを追加実装する必要があります
  • テスト・検証コスト
    • 上記差異への対応の結果、各プラットフォームごとに実機テストが必要。UI表示、パフォーマンス、センサー挙動、通知などを個別に確認する必要があります
  • ビルド環境・ツールチェーンの維持
    • iOSはXcode、AndroidはAndroid Studio、WindowsはVisual Studioなど、複数の開発環境を並行して維持しなければなりません
    • これらの各環境は、OSアップデートやSDK更新に伴い、ビルド設定や依存関係を更新する手間が発生します
  • ストア配布・審査対応
    • iOS App Store、Google Play、Microsoft Storeなど、各ストアの審査基準や配布形式に合わせた調整が必要になります
    • アプリ署名、証明書管理、審査用ビルド提出などの追加作業が発生します
  • 保守・アップデートの二重管理
    • バグ修正や機能追加を行う際、各プラットフォームごとにビルド・提出・審査を繰り返す必要があります
    • OSアップデートによる非互換性対応もプラットフォームごとに発生します
  • パフォーマンス調整
    • ネイティブビルドでも、OSごとに描画エンジンやメモリ管理が異なるため、最適化ポイントが変わります
    • 特にゲームエンジン利用時はGPUやドライバ差異による調整が必要となる事が多いです

当然、それぞれのプラットフォームのネイティブアプリそのものを別個開発するよりは軽い負担で済むでしょうが、それを差し引いてもこれだけのコストが、展開するプラットフォームの数だけのしかかってきます。
このコストは開発時のみならず、リリース後の管理維持フェーズにおいても継続していくのです。

ブラウザという共通基盤が築く盤石なクロスプラットフォーム

これらの差異を、Webではブラウザという共通基盤が吸収してくれます。
どういう事かを把握するために、経緯を含めて掘り下げてみましょう。

Webブラウジングはプラットフォームの必須機能

Windows95の爆発的普及を境にした30年ほど、インターネットは情報配信手段の最前線を走り続けています。
このインターネットでの情報閲覧を実行するクライアントアプリケーションが、Webブラウザです。
そのため、情報処理端末として普及しているPCやスマートフォンでは、必ずと言っていいほどブラウザが搭載され、あるいはインストール可能です。
高性能な端末、革新的なOS、全く新しい高効率な処理系のCPU・・・何かしらの新しいプラットフォームが誕生したとして、もしそこにまともに動くWebブラウザが存在しない・インストールできない場合、恐らく多くの一般ユーザーには見向きもされない可能性が高い1でしょう。

結果、Webブラウザで動作できるように開発されたアプリは、OSバージョンとブラウザバージョン差異から来る対応APIの差異と要求スペックをクリアすれば2、ほとんどのプラットフォームで動作可能となるのです。

このように、汎用的な情報処理端末に対してWebブラウジングが必須機能とみなされています。
そのため、ゲーム機を除く3現役のプラットフォームにはほぼ確実に、その時点でのWeb標準に準拠したWebブラウザが対応してると考えてよいでしょう。

Web標準仕様の徹底的な浸透

Windows95以降の爆発的普及とともに、Windows付属のInternetExplorer(IE)が圧倒的なシェアを獲得。
デファクトスタンダードであることを背景に、IEは独自仕様を乱発し、互換性の低さからサイトごとに「対応ブラウザ」が明記されるのが当たり前でした。

しかし2000年代後半以降、FirefoxやGoogleChromeの登場とHTML/CSS/JavaScriptそれぞれの仕様と実装の標準化が進んだことで、各ブラウザは互換性を重視する方向に収束しました。

現在では主要ブラウザが同じ標準仕様に準拠し、差異は最小化されています。
ブラウザエンジン間による最新APIへの対応速度などの差異はあれど、各ブラウザの競争は主に、UIやUX、拡張機能などの付加価値が主となっています。
個々のブラウザの差異を考えた実装の手間は、ごく一部を除いてPC/スマホ間のレイアウトや入力手段差などに限定される程度にとどまる4のです。

互換性維持への懸念と教訓

もちろん「将来も互換性が維持されるのか」という懸念は常に存在します。

  • IEの教訓: 上記の通り独自仕様を乱発した結果、互換性を損ない、最終的に市場から退場しました。現在はこの反省が生かされ、主要ブラウザは標準準拠を重視しています。
  • Flashの終焉: 大きな破壊的変更に見えましたが、そもそもFlashはWeb標準仕様外のデファクトスタンダード技術でした。標準仕様に基づくWeb技術は継続性が高いことを示す事例です。後述するCanvasなどのWeb標準技術が、Flashの担っていたインタラクティブなコンテンツ表現の手段として、台頭してきています。

万が一、将来の互換性が大きく揺らぐ場合でも、ブラウザエンジンを内蔵してネイティブアプリとしてラップするElectronで、互換性が確保されたバージョンのブラウザエンジンを固定化してアプリに組み込む選択肢があります。
これは容量増のトレードオフはあるものの、アプリの互換性を長期的に維持する保険として機能します。

ブラウザという共通基盤がもたらす強大なメリット

こうして、Webブラウザでアクセスしたときに取得できる内容は、ディスプレイサイズや入力手段の違いからくるPC/スマホ間のレイアウト差を除いて、どのプラットフォーム・どのブラウザでもほとんど変わらないように、様々な仕様が標準化されています。

つまり、Webブラウザという共通基盤をプラットフォーム側やブラウザベンダー側が自律的に整え、維持し続ける体制が整っているのです。
そしてそれは、まだ見ぬ新しいプラットフォームも含めて当面継続される見込みが、非常に高いと考えてよいのです。

開発・管理コスト面でのその恩恵は凄まじく、Webブラウザで動作するアプリを作るだけで、マルチプラットフォーム対応を周辺環境が維持してくれるに等しい状態です。
つまり、Webブラウザ向けにアプリを作るだけで、結果的にそれはクロスプラットフォーム対応アプリになるのです。
これは、様々なマルチプラットフォームのフレームワーク・エンジンが各個のプラットフォームへの対応に腐心し続ける必要に迫られるのとは対照的です。
これらの背景により、Webアプリは「同じコードが多様な環境で動く」という本来的な強みを、かつてないほど安定して享受できるようになっています。

ゲーム機への非対応の補足

一方、一般的なコンシューマーゲーム機の多くは、PCやスマホと違い、Web標準準拠を徹底したWebブラウザの搭載をされていないことの方が多い5です。
その為、Webブラウザ向けに作る場合、これらへの対応は除外するのが現実的です。

汎用的な情報処理端末ではないゲーム機では、Webブラウジングの需要が薄いためと考えられます。
致し方のないことです。

Web向けのビルドもゲーム機向けのビルドも可能なUnityなどのゲームエンジンを利用する開発をする場合、前述した各ネイティブプラットフォーム向けの「開発・保守コスト」を受け入れることで、対応プラットフォームを広げられるというメリットは、確かに存在します。
この場合も、PC/スマホOSをWeb向けビルド一本で対応することで、それらに対しての「開発・保守コスト」は抑えられます。

近年のWeb技術進化と性能改善

プラットフォームの盤石性とは少し話題がずれますが、近年のWeb技術の性能改善には注目するべきです。
かつて「ブラウザは遅い」という印象が強くありましたが、近年のWeb技術の進化はこのイメージを大きく覆しています。

Canvas / OffscreenCanvas による高速で安定した描画処理

Canvas APIの登場により、いわゆるHTMLタグで記述するDOM APIとは違うアプローチで描画処理を行うことが可能です。
Canvasでの描画は、DOMのような意味的な文書構造を持たないため、テキストベースのSEOの恩恵を受けにくいことや、描画の手法が違うことによる学習コストの発生などのデメリットはあります。
ですが、抽象化した木構造をたどる処理を連続するDOMの描画に比べ、ピクセル単位で直接描画するため高速で安定した描画を実現できます。

さらにこのCanvasを、JavaScriptにおける別スレッドから直接描画制御が可能なOffscreenCanvasの仕組みが導入されました。
従来のWeb標準仕様では、必ず描画処理をメインスレッドで行う必要があったため、複雑な描画処理にはメインスレッドの停止リスクが付いて回りました。
ですが、このOffscreenCanvasの導入により、このリスクを大幅に低減できるため、より安定した処理が可能となります。

WebGPU によるGPUアクセラレーションの標準化

さらに、このCanvasの描画手段として従来から3D描画の手法として用いられてきた、OpenGL ESベースのWebGLに変わる、WebGPUの標準化が現在推し進められています。
WebGPUは、各OSで使われるDirect3D 12やVulkan・Metalといったネイティブレベルの描画用APIの概念（モダンなGPUアーキテクチャ）に合わせて設計された、Web用の新しい抽象化APIです。
そのため、3D描画やAIに用いられる機械学習・汎用GPU計算（GPGPU）などにおいて、よりネイティブに近づく高性能化が図られることとなります。

PWAによるネイティブライクなWebアプリ利用の確立

ブラウザのアドレス・検索欄などで、インストールする・ホーム画面に追加といった表示が出てくることはないでしょうか？
これを了承すると、そのWebサイト・Webアプリは利用端末にインストールされます。
この仕組みで端末に保存、いわば擬似的にインストールされたサイトとその技術が、PWAです。

端末に保存されることにより、ホーム画面に専用のアイコンを配置することができ、そこから起動可能。
開かれるウィンドウは(内部的にはブラウザなのですが)、ブラウザとは分離された専用のウィンドウで、アドレスバーやブラウザメニューも非表示にすることが可能。
また従来暗黙的に利用されてきたブラウザキャッシュを明示的に活用するCache APIと、Service Workerによるネットワーク接続への割込みによるCacheの呼び出し制御により、オフラインでの利用やオンライン時を含む高速な起動が可能。
さらにOSのバックグラウンドで動作可能なService Workerにより、OSへの通知機能なども活用可能です。
Webアプリの利用体験をネイティブライクに大幅に近づける技術です。

Wasmによるバイナリを利用した高速な演算処理の実現

従来のWebアプリは、基本的にJavaScriptで記述されたコードをブラウザが逐次解釈・実行する仕組みでした。
JITコンパイル等の最適化はあるものの、ネイティブコードに比べるとオーバーヘッドのある仕組みのため、ネイティブアプリに比べると処理速度や効率の面で見劣りする場面がありました。

そこで登場したのが WebAssembly(Wasm)です。

  • バイナリ形式のコードを直接ブラウザで実行可能: JavaScriptのように逐次解釈するのではなく、事前にコンパイルされたバイナリを高速に読み込んで実行できます。
  • C/C++やRustなどの言語からコンパイル可能: 既存のネイティブコード資産をWebに移植しやすく、計算処理や画像処理など重い処理をWeb上で実現可能。
  • 安全性を担保した設計: メモリ管理やサンドボックス化が徹底されており、ブラウザ環境で安全に高速処理を行える。

これにより、Webアプリでも動画編集、CAD、科学計算、ゲームエンジンなど、従来はネイティブアプリでなければ実現が困難だった領域に踏み込めるようになりました。
つまりWasmは、「Webは遅い」という旧来のイメージを覆す決定打の一つなのです。

ファイル単位での永続化ストレージ運用が可能なOPFSの登場

OPFSは、2023年に主要ブラウザで実装が完了した最新の永続化ストレージ技術です。
従来のWebストレージ（localStorageやIndexedDB）が「キーと値」や「オブジェクトストア」単位での管理だったのに対し、OPFSはフォルダツリー構造を持つ仮想的なファイルシステムとして利用できます。

保存されたデータは、そのWebアプリのオリジンからしかアクセスできない6ため、セキュリティ面でも安心です。
そのため通常のOSファイルシステムとブラウザがやり取りする場合に必ず発生する、明示的な許可とパス選択操作を必要としません。
さらにファイル単位で直接読み書きできるため、IndexedDBよりも高速で、Wasmのような高負荷処理と組み合わせることで強力なストレージ基盤となります。
Wasm用のSQLiteとOPFSの連携は、急速に認知が高まっているOPFS定番の活用法です。

これにより、動画編集やCAD、科学計算、ゲームのセーブデータ管理など、従来はファイルアクセスへの柔軟性の問題からネイティブアプリでなければ困難だった領域を、Webアプリでも現実的にカバーできるようになりました。

これらの技術は、従来ネイティブアプリでしか実現できなかった表現力や速度をWebに持ち込み、ブラウザ上でのアプリ体験を大幅に改善しています。
ブラウザは、着実にネイティブアプリの性能に近づいているのです。

ここまでのまとめ

ここまで見てきたように、Webブラウザは

  • 各プラットフォームに必須機能として搭載されている
  • 標準仕様の徹底浸透により互換性が高い
  • ネイティブアプリに近い性能を着実に獲得している（Canvas, WebGPU, PWA, Wasm, OPFS）

という特徴を備えています。

つまり、Webアプリは「同じコードが多様な環境で動く」という本来的な強みを、かつてないほど安定して享受できるようになったのです。
このことにより、Webは

  • Webブラウザ用として開発するだけでクロスプラットフォーム性が確保されるという開発コストの低さ
  • 実行環境の継続的なメンテナンスをプラットフォームとブラウザベンダーが担うことによる維持コストの低さ
  • Webブラウジングが必須機能とされるがゆえに新しいプラットフォームへの対応も素早い将来性の高さ
  • 新しい技術群（Canvas, WebGPU, PWA, Wasm, OPFS）の登場によってネイティブアプリに近い性能を獲得しつつある

という、クロスプラットフォーム基盤としての好条件が揃い始めているのです。

ここまでが、OPFSジャックを語る前提となる“Web一般論”の整理です。
次章では、この基盤の上でOPFSがどのように新しい可能性を切り拓くのかを掘り下げていきます。

「配信」から「インストール」へ：OPFSジャックの可能性

ここまでの時点で、Webブラウザがいかにクロスプラットフォーム基盤として優れているかを存分に提示できました。
よってここで当記事は締めくくってもよいのですが、そこは諸般の事情につき(笑)筆者の提唱するOPFSジャックを絡めたさらなる掘り下げを続けさせていただきます。

OPFSジャックのとても簡潔な説明

先ほど紹介したOPFSは、Web標準としての最新ストレージ技術でした。
筆者が提唱する「OPFSジャック」は、そのOPFSをアプリ配信の基盤そのものに転用する技術です。
その効果の体験や詳しい実装は私のZennの本に譲るとしまして、手短にどのようなことが実現できるかを説明いたします。

  • Webサイト上で、あらかじめWebアプリやブラウザゲームのソースフォルダ(HTML/CSS/JavaScriptを含む)を丸ごとOPFSに保存(インストール)し、それを起動・実行する技術
  • あらかじめ決められた処理を実装済みのURLにアクセスした際に、インストールしたフォルダ内容を実行することができる。
  • 「OPFS内のどのフォルダを実行するか」が選択可能であるため、実行フォルダ=実行するWebアプリを選択・切り替えが可能
  • また、OPFS内のWebアプリフォルダ内容をインストール時・またはインストール後に修正可能

つまり、

OPFSそのものをWebアプリの実行場所とすることで、
URLに対応した配信内容を実行するという、Webの根本的制限をキャンセルする手法です。

なお、これらの処理に関してサーバーサイドから借りる力は、URLに応じてファイルやヘッダなどを返すWebサーバーの基本機能と、OPFSの利用条件であるHTTPSだけです。
フロントエンド完結型の徹底されたサーバーレス技術なのです。

では、この仕組みをどう活用できるのでしょうか？

具体的な活用例

私の本のシリーズでは、このOPFSジャックの活用手段として、

  • ネイティブゲームで見られるModsフォルダにModを保存すればModが利用可能になる、ゲーム側が標準でMod対応機能を備えたWebゲームの実現

を掲げており、そのために必要な管理機能としての

  • Mod対応を担保し続けるために、クライアントサイドGitライブラリを活用して、OPFSに保存するゲームバージョンを指定できるバージョン管理機能
  • Modの追加・削除・機能オンオフの設定等を行えるMod管理機能
  • Modの有無・バージョン違いなどでプレイ環境をコンテナ的に分離・切り替え可能とするためのプロファイル管理機能

を備えた、いわばMinecraftランチャー兼Steamワークショップともいうべきゲームランチャーを構築するための技術を、解説していく予定です。

余談ですが、この技術自体は提唱を始めたばかりの新しい技術である(と思われる)ため、実際の活用事例はなく、また上記以外の活用方法の実証もまだまだこれからです。
私の本でもいくつか、想定できる活用例を載せておりますが、この記事をお読みの皆様も是非、OPFSジャックを記憶にとどめ、活用方法を編み出していただければと思います。
編み出して実装した方が、先駆者となれます。

OPFSジャックが生み出す、Webを選ぶさらなる理由

OPFSはWebアプリが必要とする永続化データを保存するためのストレージです。
これを、OPFSジャックによってアプリを丸ごと格納するコンテナ群化することにより、Webのクロスプラットフォーム基盤としての価値はさらに高まります。

ローカルインストール・バックアップと資産保全

OPFSにアプリを丸ごと格納することで、ユーザーは自分の手元にアプリの「完全コピー」を持つことができます。
これまでWebアプリの「オワコン」は、配信Webサーバーの「オワコン」とイコールでした。
ですが、この完全コピーをバックアップとして取得可能にすることで、このサーバー依存の制約を大幅に緩和することが可能です。
OPFSジャック自体は「ただのWebサーバー」以外に必要とするものが何もないため、Webアプリの実装次第ではlocalhostサーバーで利用し続けることも可能なのです。

アプリケーション寿命の延命

この資産保全は、ユーザーサイドだけのメリットではありません。

ネイティブアプリはOSのアップデート、ゲーム機の世代交代、配信ストアの審査判断の変化で寿命が左右されます。
当然、ネイティブアプリにビルドするクロスプラットフォームフレームワークやゲームエンジンも、それぞれのビルドについてネイティブの事情に左右されます。
さらには、フレームワークやエンジンのアップデート対応も必要であり、またアップデートしなくなり現存のプラットフォームにビルド不可能となった場合は、別エンジンなどへの移植が必要となります。

それに対してWebアプリは、ホスティングサーバーの状況に左右されます。
ですがネイティブアプリの別プラットフォームへの移植、エンジンやフレームワークの移行に比べれば、ただデータを引っ越すだけで済むホスティングサーバーの移行は一般的に簡単です。
サーバーサイドに特別な要件があればまた違う難しさがあるでしょうが、少なくともOPFSジャック機能そのものは「ただのWebサーバー」で十分です。

ユーザーのデータ移行も前述したとおり、バックアップの移行で済みます。

Webアプリケーションがメンテナンスされることなく、アプリに対するWeb標準技術の互換性が失われても、前述したElectronのブラウザエンジン固定でラップすることで、さらなる延命すら可能です。
ネイティブアプリやネイティブアプリをラップするクロスプラットフォーム基盤に比べ、OPFSジャックを利用したWebアプリケーションは、その寿命を飛躍的に高めることが可能です。

ChromeOSの実質的なネイティブアプリケーションとなれる可能性

ChromeOSの進歩は目覚ましく、LinuxやAndroidのアプリケーションも仮想マシン(VM)経由で動作させることが可能となっています。
しかし、VMを介するオーバーヘッドは無視し得るものではありません。
特に、教育用途などで提供されがちな低スペックのChromeBook端末では、マシンスペック上の問題でVM経由のアプリケーションは動作困難なケースも多々、考えられます。

Web標準技術が根幹となるChromeOSにとって、一番負荷が少ないのがWebアプリになります。
PWAはそのWebアプリをネイティブアプリライクに、個別のアプリとしてChromeOSでも起動可能にします。
ここに、OPFSジャックによる実質的な、アプリを丸ごとローカルに保存する手法と組み合わせることで、ユーザーストレージに完全保存された、実質的なネイティブアプリが誕生するはずです。

OPFSジャックは、ChromeOS市場にとって、主役となりえるポテンシャルを秘めているのかもしれません。

おわりに

本記事では、Webブラウザがクロスプラットフォーム基盤としていかに盤石であるかを整理し、さらにOPFSジャックという新しい技術がその価値を拡張する可能性を示しました。

標準仕様の徹底的浸透と継続した互換性、そして新しい技術群による性能進化によって、Webは「同じコードが多様な環境で動く」という本来的な強みを、かつてないほど、安定して享受できるようになっています。
これにより、開発コストのみならず、維持コストまでも抑えられるようになったのです。
そしてOPFSジャックは、その強みを「資産保全」「寿命延命」「ChromeOSでのネイティブ化」といった新しい方向へ広げる可能性を秘めています。

この記事を読んでくださった皆様が、Webを選ぶ理由を再確認しつつ、OPFSジャックの活用を思い描いていただければ幸いです。

OPFSジャックにつきましては、拙著OPFSジャックでURLを拡張！OPFSでWebゲームをインストールしようをお読みいただけますと幸いです。
前述したとおり、Webで実現できるとは思われていなかった動作を実現する技術ですので、コンピュータープログラマーの方にとってご一読の価値は十分、あるかと存じます。
無料公開部分にて、「OPFSにWebアプリをインストールして指定URLから実行」というOPFSジャックの中核処理を体験していただけます。

それでは、ご静読誠にありがとうございました。

  1. 逆説的に言えば、情報配信手段の大幅なパラダイムシフトが起きてインターネットが見向きもされなくなるまで、OSやCPU処理系の変遷に関わりなく、Webブラウザという仕組みそのものは盤石であると考えられます。 ↩

  2. 古いOSやブラウザ・あるいはまだ普及前のブラウザAPIや、アプリの処理が要求するスペックに端末が満たない場合は対応できない、ということ ↩

  3. ゲーム機はビデオゲーム専用機であるため、「汎用的な情報処理端末ではないため」Webブラウザが必須だと認識されていないと考えられます。 ↩

  4. これらの分岐は必要ですが、主に CSS と入力周りのイベント処理で対処可能です。個々の Web アプリが要求する処理能力やハードウェア依存機能（カメラ、GPS、専用センサー等）は別途考慮が必要です。 ↩

  5. Xbox Series X/Sには、Microsoft Edgeが搭載され、Web標準APIに準拠したブラウザをユーザーが利用可能なようです。これが数少ない例外といえるでしょう。 ↩

  6. OSのファイルシステムからユーザーがアクセスすることもできません。そのため、誤って削除したり、他のアプリから不正に書き換えられるリスクもありません。 ↩

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?