- Appleは顧客に安全で管理負担の少ないデバイスを提供する一方、個人開発者に対しては同じ水準の相互依存性を生み出していない、という経験的な結論に至った
- Google検索のダーク/ライトモードのバグは、技術力不足というより、収益に影響しない不便が長く放置され得ることを示す事例として使われている
- Appleの核心的価値はアプリエコシステムよりも、ユーザーが別途管理せずに使えるコンピュータやデバイスにあり、iPhoneやiPadはアプリがなくても購入する理由があると見ている
- 2016年に期待していたApple Music APIは、8年後もバグとアクセス制限が残っており、単に試すだけでも年100ドルの開発者アカウントが必要
- 単一企業が所有しないWebプラットフォームは不完全で危ういものの、特定企業のゼロサム構造に縛られにくくしたい開発者にとって、現実的な選択肢であり続けている
Appleは顧客には強いが、開発者には依存していない
- Appleは顧客である個人には明確な価値を提供しているが、個人開発者に同じように気を配る構造的な理由は弱い、という認識が中心にある
- 依存関係は
Developer -> Apple、Apple -> Consumer の方向に流れており、Appleから個人開発者へ向かう逆方向の依存はほとんどないと見ている
- すべての開発者がAppleプラットフォーム向け開発をやめても、Appleはおおむね生き残れる。それはAppleの中核的な価値提案が個々の開発者に依存していないため
- 企業開発者の「パートナー」との協力は必要かもしれないが、個人開発者への依存とは別の問題
- 一部の多国籍企業は開発者を戦略の中核に据えているが、Appleはそのタイプではないと見ている
- この区別を受け入れたあと、Apple製品を好きな気持ちと、Apple向けに開発したい気持ちを切り分けられるようになった
Googleの事例：収益に影響しないバグは長く残り得る
- Google検索には、システムが動的にライト/ダークモードへ切り替わる環境で、最初の検索結果ページが反対のテーマで表示される問題がある
- 夜はシステム全体が暗い状態なのに、最初の結果ページが明るく表示されて目が痛い
- 朝はノートPCがライトモードに戻ったあと、検索結果が読みにくい黒背景で表示される
- このバグは何年も続いており、大規模な改修の中で偶然直らない限り、修正される可能性は低いと見ている
- 原因はGoogleに直す能力がないからではなく、収益に影響がないためだと解釈している
- DDGのような代替検索エンジンを使う人はすでに離脱しており、圧倒的多数はGoogleに縛られている
- DDGはプライバシーに配慮している点を掲げるが、実際に使う理由は、初期のGoogleを思わせるシンプルなUX、質の高い正確な検索結果、邪魔にならない広告にある
- Googleはユーザーをゲーム理論上の目標として扱っておらず、Google製品を使わざるを得ないときに生じるユーザー敵対的な相互作用も、その構造の結果として受け止めるようになる
Appleの核心的価値：管理負担のない安全なコンピュータ
- 2009年ごろ、家族用のコンピュータを選ぶ際、当時のWindowsはセキュリティがあまりに脆弱で、Linuxは継続的な技術サポートが必要だと判断した
- 結局、OpenBSD、Firefox、標準ゲームをインストールしたコンピュータを用意したが、安全性とプライバシー、低いサポート負担を得る代わりに、使える範囲は大きく制限された
- iOSアプリ企業で業務用Macを使ったあと、「これこそ母に欲しかったコンピュータだ」という判断に至った
- お金を貯めてMacBookを買い、時間が経つにつれて家族が使うフォームファクタはノートPCからiPadへ変わったが、同じ核心的価値は満たされ続けた
- アプリのないiPhoneであっても自分なら買う可能性があり、家族にはほぼ確実に買うデバイスだと見ている
- Appleのビジネスモデルにおいて開発者は必須要素ではなく、開発者が幸せでも構わないが、幸せでなければならない構造ではないと解釈している
- Apple内部には開発者を気にかけ、改善しようとする個人はいるが、会社としての行動は一貫しないことがある
Apple Music APIへの期待と挫折
- 2016年ごろ、WWDCでApple Music APIが発表されたとき大きな期待を抱いたが、実際には「すべてが変わる」ことは起きなかった
- Apple純正の音楽プレイヤーはいまだに使いにくいと感じており、試した代替プレイヤーも概してSpotify式のアプローチに従っていると見ている
- WinampのJustin Frankel時代のように、高速で滑らかで、終わりなく続きながらも個人的な音楽プレイヤー体験をもう一度作れると期待した
- Appleの音楽カタログがあれば、かつてのように違法コピーに頼らず、そのような体験を再現できると見ている
- 余暇ができてFlowersという音楽プレイヤーを作り、他の人がそれぞれ自分の音楽プレイヤーを作れるようにチュートリアルも書こうとした
- 実装の過程で、8年が過ぎたあとでもAPIはバグがあり、公開されていないと判断した
- APIを試すだけでもAppleに年100ドルを支払う必要がある
- 費用は大量利用の料金ではなく、単なる試用アクセスにも必要
- 有料の開発者アカウントを使っても、得られるのは制限されたAPIだけ
- AppleのWeb音楽プレイヤーのブラウザコンソールで
MusicKit.getInstance().developerToken と入力すると、制限のないルートトークンを無料で取得できるため、開発者向け手続きは不合理だと見ている
Webは単一所有者のいない共有プラットフォーム
- 結論は、Webで実行されるコードを書け、という方向につながる
- Webは単一の主体が所有しない共有プラットフォームであり、善意でさえ無能によって壊され得るという点で、特定企業のプラットフォームとは異なる
- Webプラットフォームは次の要因により危うい状態にある
- 過度に介入する政府
- ブラウザの二強構造
- 複雑な開発者エコシステム
- Webが今後も繁栄し続ける保証はないが、これまで生き残ってきており、長く生き残るほど今後も繁栄する可能性は高まると見ている
- Webに関して最近書く必要があった回避コードは、Safari特有の挙動が原因だったという
- 同時にGoogleはWebのために素晴らしい仕事をしており、この文脈では良い役割を果たしていると評価している
企業との関係は固定された善悪で分けにくい
- 人を善人と悪人に固定分類することが有用でないのと同じように、企業も良い会社と悪い会社に恒久的に分類するのは難しいと見ている
- 企業は知能、性格、誕生と成長と消滅、法人格を持つという点で、人と似た属性を共有している
- 人なしでは生きられないように、企業なしでも生きられず、非人間的な特性があっても、人間組織のフラクタル的な形は存在し続けると見ている
- 企業を固定された善悪のカテゴリーに入れなければ、より流動的に関係を結べる
- 企業がゼロサムゲームへ押し込んでくるときは依存度を下げる
- より共生的な関係を許すときは再び関わる
- Steve Jobsは1996年に、大企業、中堅企業、小企業のすべてがWebを最終的な直接顧客流通網として見始めており、仲介者を迂回して供給者から消費者へ直接向かう経路だと語った
1件のコメント
Hacker News の意見
初期にネイティブモバイル開発を学ばないことにして、限られた時間をすべてWebに集中したが、今回ばかりは正しい選択だったと思う
今ではブラウザで驚くようなものを作れるし、ごく個人的な考えでは、Uber、Google Drive、ゲームくらいを除けば、ほとんどのアプリはWebアプリであるべきだった
メディア業界で働いていたが、うちの国の2010年代初頭は、たいして資金もない媒体がモバイルアプリを作るために予算をつぎ込んでいた時期で、私はその流行に逆らう目立つ存在だった
ほとんどのアプリの品質がよいはずがなく、企業がモバイルのフロントエンドを継続的に更新することもないだろうと分かっていたが、結局まさにその通りになった
今では、ほとんどメンテナンスもされていないアプリに閉じ込められていて、その大半は過ぎ去った時代の遺物のように見えるし、実際そうなのだ
しかし、なぜUberなのかは分からない。Uberには、乗車リクエストやアプリが行うほぼすべてのことをうまく処理するモバイルサイトがある、あるいはあったし、ネイティブアプリがユーザーにどんな価値を追加しているのかよく見えない
ほとんどのモバイルゲームも同じだ。たいていはブラウザが十分高性能にレンダリングできる単純なグラフィックで、共通UIコンポーネントを自前で作り直すことが多いため、ネイティブのシステムボタンを使えなくても大きな違いはない
PWAも、ローカル保存ファイルやゲームデータに必要なストレージを十分提供できる。もちろん、システムの限界まで押し込むゲームは例外だ
Death StrandingやRE4リメイクのようなゲームが、ネイティブのグラフィックアクセラレーションに直接アクセスせずにうまく動くとは期待していないし、単一のWebページとして読み込むには大きすぎる
だが、ほとんどのモバイルアプリ、さらにはWebに行けば売上の30%を余分に得られる高収益の無料プレイゲームでさえ、これには当てはまらない
では、なぜWebを狙わないのか。直感的には、モバイルユーザーはアプリやゲームをアプリストアで探すように慣らされており、デスクトップユーザーは一部の専門ツールや高性能ゲームを除けば、アプリはブラウザで提供されるものだと期待しているからだ
結局かなりの部分は文化的な問題であり、Appleの不十分なPWAサポートも助けになっていない
苛立ちの大部分はツール、特にTypeScriptから来ていて、簡単に表現するのは難しいが、ネイティブ側よりもTypeScriptの型システムと格闘することがずっと多かった
ただし、GoogleとAppleに、PWAをネイティブアプリと競争できるレベルまで改善する手助けをするインセンティブがあるのかは心配だ。その水準になれば彼らの収益に打撃が出る可能性がある
技術スタックの基礎構成要素に時間を投資したほうがよい
どれもWebで処理できるものだ
Appleが開発者を気にしない理由は、自ら説明しているように、ユーザー側に閉じた庭に近いカルトを作り上げているからだ
開発者は、そのプラットフォーム向けの製品を作らなければ市場の半分、あるいはそれ以上を失うことになる
大企業内の小さなスタジオでモバイルゲームを作る本業では、技術的な問題だけでなく、ポリシーや承認の問題でもAppleと常に戦わなければならない
しかし、iOSで実行する方法のないモバイルゲームを出すことは想像しにくいので、従うしかない
多くの面で、MicrosoftのもともとのPC戦略は正反対だった。開発者を大事にし、膨大なドキュメント、サンプル、ツールを提供していた
その開発者たちが所属する企業には、Microsoft向けソフトウェアを作り、宣伝し、販売する動機があり、個人開発者がWindowsソフトウェアを大量に生み出した波が、今も支配的なデスクトップOSを作り上げた
Appleエコシステムに貢献することは選択であって強制ではない。Appleエコシステムに貢献する開発者は、現在の状況に積極的に参加しているのだ
Appleは開発者に意地悪をする、より正確には開発者が顧客に意地悪できないようにすることで、これを実現している
供給業者に強い圧力をかけるやり方にも似ているが、最終的には健全で裕福なエコシステムが作られ、開発者や供給業者はいまもそこにアプリを提供している
ソーシャルネットワーク、デーティングアプリ、Reddit、Stack Overflowのようなものだ。Uberのように位置追跡が必要だったり、移動中にプレイするよう設計されたモバイルゲームのように、モバイル体験に依存するサービスではない
ビジネスがモバイル体験に依存していないなら、ネイティブアプリなしでもサービスを提供できる
モバイルユーザーもモバイルブラウザでアクセスできるし、理想的な体験ではないかもしれないが、選択肢にはなる
要点は、モバイルプラットフォームが必須でない、あるいはそこに依存していないなら、そのプラットフォーム向けに作るな、ということだと思う
数年前、Swift とネイティブ iOS 開発を学ぼうとかなり掘り下げたが、Xcode の使用にどうしても慣れられなかった
Xcode の UI/UX は言葉にしにくいほどひどく、直感的にまとまってもいないアイコンを押すために、パネルを開いたり閉じたりし続けなければならなかった
あるパネルを開くと別のパネルが強制的に最小化され、時間の 10 分の 1 は実質的に「パネル運転」に使っているような感覚だった
Apple のデザイナーは、開発者にとって摩擦の少ない IDE ではなく、見た目がきれいでミニマルな IDE を作りたかったのだと思う
しかし IDE はミニマルである必要はなく、各開発者が作ろうとしているものに合わせて、望むだけカスタマイズして散らかしておけるべきだ
物理的なガレージの作業台を想像すると、Visual Studio は作業スペースを好きなだけ散らかしてカスタマイズさせてくれるが、Apple は次の道具を手に取る前に毎回前の道具を箱にしまえと要求しているように感じる
私が言うパネル運転とはそういう意味で、他の開発者もこう感じているのか気になる
機能より形を優先しているという表現のおかげで、Xcode の何が嫌だったのかを言葉にできるようになった
10 年以上 JetBrains エコシステムにいて欠点もあるが、JetBrains が IDE を自分の望むやり方で動かせないようにしていると感じたことはなかった
ただ、Apple プラットフォーム向けのネイティブアプリ制作から私を本当に離れさせたのは、バグとドキュメント不足の組み合わせだった
1 年前に最後に使ったとき、SwiftUI は目的にかなう状態ではなく、より成熟したライブラリでさえドキュメントがほとんどないことが多かった
何が廃止されたものなのかを知るのも難しい
私の仕事では、ネイティブアプリの利点はユーザー視点ではそもそも小さく、主により安定したローカルストレージくらいだ
Web アプリを作るより生産性がはるかに低いなら、独占君主のような存在の慈悲にすがる追加コストとリスクを正当化するのは難しい
Xcode はまったく気にならないが、称賛されている IntelliJ ベースの Android Studio はずっと神経に障る
Visual Studio も同じように窮屈で変な制限がある。たとえば構文ハイライトでイタリックを使えないのはなぜなのか分からない
エディタも同じだ。VS Code は Sublime Text や TextMate と違って、細かく気になるところがある
昔ながらの重い IDE のような感じで、それに従うほど楽にはなるが、同時に自分が制御していないという感覚も残る
Apple が気にかけさえしていれば、VS Code ほどではなくても半分くらいはもっとキビキビさせられただろうし、明らかに今より良くできるはずだ
Vim キーバインド対応がひどいだけでも腹が立つ。たとえば
cやrのような大半の操作を再実行できない当時 SwiftUI を使っていたのか、UIKit のストーリーボードと格闘していたのかは分からないが、後者は最悪の体験で、敵にも勧めたくない
SwiftUI はまだ初期段階で磨くべき部分はあっても、それに比べれば未来のように感じる
以前、うちの自治体アプリの 1 つをこちらの所有として表示するために、Apple 開発者アカウント を設定しなければならなかったことがある
他のアプリでは不要だったのに、なぜそうだったのかは分からないが、とにかくそうする必要があり、かなりひどい体験だった
まず Apple アカウントが必要で、個人アカウントを使いたくなかったので業務用アカウントを新しく作らなければならなかった
「組織アカウント」を作れず、自分個人に紐づいてしまい、幸い廃棄予定だった古い iPhone があったのでそれを使えた
その後、Apple が私の身元を確認するまで数日待ったが、実質的には私が上司として記入した人に Apple が電話し、その人が本人だと言う手続きだった
もっと調査してくれていたことを願うが確信はなく、電話をかけてきた人たちの英語は私たちよりさらに拙かったので、少なくとも滑稽ではあった
次に決済を設定しなければならなかったが、どういうわけか Apple 開発者アカウントを持つにはお金を払う必要がある
人口 6 万人の都市の全体予算では目立ちもしない金額に思えるが、海外サブスクリプションであり、Apple が現地の税務当局に簡単に登録できる B2B 購入方式として処理する方法を提供していなかったため、毎年審査対象になった
支払いもクレジットカードのみで、組織カードも実在の人に紐づくため、更新を担当する人が必要になる
人は転職するし、所有者を変えるには Apple と実在の人間同士が連絡を取らなければならないので、どれほど楽しかったかは想像できるだろう
数年前のことなので変わっているかもしれないが、私が扱ってきた 300 以上の企業向け IT ソリューションの中で、Apple ほどひどいものはなかった
公平に言えば、私は開発者なのでなぜこの仕事を任されたのかも分からないし、IT 運用側ではこういうことがもっと普通なのかもしれない
ただし、書類作業を簡単に処理できる米国の大企業なら例外だ
いまだにランダムだ。すぐできることもあるし、運悪くこのプロセスのランダムなバグに当たると長い間失敗し続ける
いつ始まったのかは分からないが、ごく最近というわけではない
たまに、もともとのWeb/WWWがどれほど開かれていたか、そして今でもAppleとGoogleが独占する「アプリ・エコシステム」と比べると全体としてどれほど開かれているかを忘れてしまう
もちろん「クラウド」はあるが、サーバーを借りて自分のものを自分でホスティングすることを妨げるものはない
うまくいかなければ、そこから取り出して別のサーバーを借りればいい。ロックイン効果はあるし簡単ではないかもしれないが、不可能ではない
アプリ・エコシステム全体で見ると選択肢は2つしかなく、文字どおり彼らの慈悲にかかっている
個人的には絶対に「アプリ」1つに事業全体を賭けることはしない。オーディエンスが本当に求めるなら小さな補助手段としてアプリを置くことはあるかもしれないが、その程度だ
モバイル機器でアプリを強制してくる製品は嫌いだ。むしろ m.website.com のような方式が戻ってくるほうがよく、アプリ・エコシステム全体を避けたい
一晩で、理由があってもなくても「HNのトップページで助けを乞わなければならない」立場になり得る
EUの新しいサイドローディングの流れが米国でも似た要求を呼び起こすことを祈っているが、同時に「閉じた庭」や「サイドローディング」が何を意味するのかを知り、関心を持つ人が十分に多くなければ可能ではないこともよく分かっている
Webは理論上は素晴らしいが、ブラウザー環境があまりにも最低限しか提供しないため、Appleプラットフォームのようなバッテリー同梱型の開発体験に慣れていると、アプリ・プラットフォームとしてはあまり魅力的ではない
macOSでは、強力で洗練されたアプリでも依存関係と推移的依存関係は片手で数えられるほどで、少し努力すればまったくなしでも開発できる
一方、同等のWebアプリでは機能の空白を埋めるために数十から数百の依存関係が生じる
たとえば、ブラウザーがJavaScriptをまったく使わない、またはごく少ししか使わずにセルを効率よく再利用する基本的なリスト/テーブルビューを提供できない理由が分からない
数百から数千の項目をスクロールしても、デバイスがもたついたりメモリが枯渇したりしないようにする必要がある場面は珍しくない
AppKit、UIKit、SwiftUI、Android Framework、Compose、おそらくFlutterでもこれは標準でうまく処理されるが、ブラウザーではこのごく基本的な機能のためにライブラリを引っ張ってくるか、自分でコードを書かなければならない
ここにパッケージ管理や全般的なツールの問題まで加わると、解決策が入れ替わる間も同じ根本問題がしぶとく残り続ける
15年前からiOS/iPadアプリもかなり作ってきた
Webの良いところは、たいてい要件に合うライブラリやフレームワークがあることだ。Electronがその例だ
Apple側は良いライブラリがないことが多く、SwiftUIはバグが多すぎる
Reactはただ普通に動くし、概念的にもより単純だ。双方向データバインディングは悪い考えだ
Appleはすべてをより単純にしてくれるという考えを持っているが、実際にはより面倒で難しくしていることが多い
テーブルはサーバー側で必要なデータと正しい順序であらかじめ埋められている
そのためセルや行を再利用する必要がなく、数千行あってもデータはKB単位なのできびきび動く
WebAssemblyやFlutterのような代替案まで考慮すれば、ブラウザーの基本機能不足はもはや問題であるべきではない
開発者がAppleに何ももたらしていないというのは事実ではないと思う
iPhoneにサードパーティアプリがなければ、Appleはずっと少ない台数の携帯電話しか売れなかったはずだ
理論上、多くのアプリはWebへ移行できるかもしれないが、それでもサードパーティアプリがiPhoneをはるかに所有する価値のあるものにしている点は変わらない
まともな競争があれば、OSメーカーは開発者を引き付けようと懸命に努力する。昔のBallmerの「developers developers developers」動画を思い出せばいい
開発者がプラットフォームに価値を加え、消費者の選択に影響することを知っているからだ
最近の問題は、意味のある競争がないことだ
Appleの規則がどうであれ、開発者はiPhone向けに何かを提供しなければならず、Appleは第3のモバイル・プラットフォームが定着する可能性はほとんどないと安心していられる
Appleはそれを分かっており、厳格なポリシーによって状況を残酷にひっくり返した
開発者がiPhoneを所有する価値のあるものにするうえで大きな役割を果たしているにもかかわらず、Appleは自分たちがiPhone顧客へのアクセスを許してやっている恩恵を施しているとして、収益全体に税を課している
これは市場支配的地位の濫用であり、ブログが言うようにWebで配布すること以外にできることは多くない
完璧ではないが、規制以外で有意義な代替策はそれだけであり、Appleはアプリ開発者に課税して得ている数十億ドルの売上を自ら手放す理由がないので、規制を避けるためにあらゆる手を使うだろう
Webが濫用的なアプリ配布ルールを回避する方法として力を得ることを望む
毎日、Webがどれほど素晴らしいか、そしてAppleが開発者にWebアプリではなくiOSアプリを作らせることで、Webを可能な限り台無しにしようとしたことがどれほど残念かを考えている
App Storeがなければ、Webはずっと良くなっていたはずだ
コンテンツ消費、ソーシャルメディアの出どころ、アルゴリズムによる推薦、デジタル体験において、もっと多様性があったはずだ
Webはどこでも動き、WebXRのような没入型/次世代アプリケーションを作れる優れたAPIも多い
しかし誰かが自分のサイトでWebXRアプリを作って有料販売してもAppleには金にならないので、AppleはこうしたWebアプリを決して宣伝しない
長期的に見てWebは死なない。企業は参入して利益を搾り取り、去っていくが、Webは死なない
Appleは、プラットフォーム開発を容易にする数千のAPIを提供し、プラットフォームとうまく統合される独自のプログラミング言語を作り、その両方と連携する完全統合IDEも備えている。
そうだよ、「友だち」。彼らは自社プラットフォーム向けに開発しない限り、君のことなど気にしていない。
そして誰が責められるだろう？ 上に挙げたものは、ものすごく高価で時間のかかる投資なのだから。
SwiftとAppleのツールを使わずにmacOSで直接アプリを開発しようとしたことがあるが、ものすごく苦痛だった。
彼らは、自社ツールを推し進めるためという以外には説明しにくいほど、OpenGLを廃止してバージョンを固定してしまった。
外部DLLを1つロードすることさえ、ほとんど不可能だった。
VulkanをMetalに変換するように、クロスプラットフォームなものは何であれAppleのツール体系へ降りてこなければならない。
macOSは、どのLinuxディストリビューションよりも例外的で特殊なケースだ。
Windows開発がどれほど簡単かを見ると驚くほどだ。Microsoft側はほぼすべてがクロスプラットフォームだ。
挙げられたAppleのものの中に、プラットフォーム非依存で作業させてくれるものはない。
一方でWindowsは、DirectXのような独自技術もサポートしつつ、VulkanやOpenGLなどを直接実行することも許している。
ただ、筆者が音楽アプリの作業をしていてそこに踏み込んだという点は重要だ。AppleのオーディオAPIは完全にめちゃくちゃだ。
Media Player、AVPlayer、Core Audio、AVFoundation、AVAudioEngineなど、NeXT時代にまでさかのぼる競合チームがそれぞれライブラリを使っていて、どういうわけか全部がiPhone時代まで生き残ったように見える。
COVIDのロックダウン中にShoutcast/Icecastプレーヤーを作ろうとして3か月ほど費やしたが、本当に苦痛だった。
iOSで動くネイティブなクロスプラットフォームコードを書くことを事実上不可能にし、Webアプリがネイティブアプリと競争できないよう、政治的な制約の範囲内でできることをすべてやってきた。
大企業に対する筆者の健全な姿勢が気に入った。現代の基本的なサバイバルスキルだ。
自由にできるなら、iPhoneやiPadにどんなアプリもインストールしなくて済むとよいのだが、プラットフォームの制限のせいで現実的には必要になる。
SafariでX/TwitterのWebアプリが動画を再生しないのを見たし、XについてLockdown Modeをオフにしてもそうだった。
これがプラットフォームの不一致を生んだAppleのせいなのか、ユーザーにアプリをインストールさせようとするXの意図なのか知りたい。
私はディープラーニングとLLMを専門にしているが、Web開発もずっと楽しんできた。
足を引っ張っているのは、ツールが複雑すぎることだ。
それでも知人がClojureScript + Dartについて多く書いているので、一度試してみようかと思っている。
数日で学べて十分にサポートされているシンプルなWebアプリのスタックを見つけたいのだが、おすすめがあればうれしい。
Web開発のかなりの部分はブラウザをよく知ることで、web.devは優れた資料だ。
次にReact + TypeScriptを学べばいい。新しいreact.devも良い。
Reactは完璧ではないが、UIを作るためのパラダイムとしては非常に優れていて、AppleもSwiftUIを作るときにそれを真似した。
Viteを手に取ってコーディングを始めればいい。
いちばん勧めたいのは、それらの資料をきちんと勉強することだ。ドキュメントの最初のページから始めて、最後まで一歩ずつ追っていくべきだ。
ただし、数日で学べることは多くない。フロントエンド作業は、もっともな理由があって難しい。