ウェブサイト本当にいる？驚きの「プレーンバニラ」思考でビジネスをシンプルに！
引用元：https://news.ycombinator.com/item?id=43954896
バニラかフレームワークかじゃなくて”そもそもウェブサイトいる？”って考えたら驚くかもね。特にB2B SaaSで。ウェブアプリ作りの時間の大半って、管理者がDBいじるためのUI/UXなんだ。それならExcelとかで設定ファイル送ってもらってDBに流し込む方が全然速くてラクじゃん。ウェブはUI/UXの選択肢の一つ。メールとかファイルの方がよっぽど柔軟だよ。
俺、オンラインで骨壷売ってるんだけど、サイトにはメールリンクだけだよ。カート無し。実店舗の骨壷屋にカートないのと同じ感覚。木工ツールの専門品買った時は、フォーム入力だけ。後で品物と請求書来て払った。払わない選択肢もあるんだよ。
ネットでもリアルでも商売のやり方って色々あるし、よく見ると面白いことやってる人、周りにいっぱいいるよ。
＞ 木工ツールの専門品買った時は、フォーム入力だけ。後で品物と請求書来て払った。払わない選択肢もあるんだよ。
こういうビジネスをロマンチックに語る人いるけど、リンク貼ってない理由があるんだよ。知ってる人だけの小規模グループで、信用できる買い手を紹介し合う場合にしか通用しない。
これの全ての問題を回避できるオンライン購入オプションなんて、ちょっとした費用でいくらでも簡単に設定できるしね。
多分、未払いとか、頼んだ品物が届かないとか、そういうのに懲りすぎたから、もうこういうのロマンチックに見えないわ。
Uber Eatsの注文追跡画面使うたび同じこと思うんだよね。俺に必要なのは、このシンプルなテキスト履歴だけだよ。
7:40 - Bobは5分遅れてる。到着予定7:45
7:35 - Bobがそっちに向かってる。到着予定7:40
7:20 - Bobがピザ屋さんで注文品を受け取った
＞ リンク貼ってない理由があるんだよ
そうそう、HNにブラスtacksの注文が殺到するの心配だったんだ。それは正しい。
＞ 多分、未払いとか、頼んだ品物が届かないとか、そういうのに懲りすぎたから、もうこういうのロマンチックに見えないわ。
この件に関しては選択肢があんまり無いのよ。最後に残ったブラスtacksの製造所が閉まった時、Johnが機械を買い取って、彼がUSでちゃんとしたshakerスタイルのブラスtacksを手に入れられる唯一の場所なんだ。tacksが欲しかったから、支払い方法を選ぶ余地は無かった。
言いたいことは分かるけど、USでは昔ガソリン入れてから払うのが普通だったし、今もそうしてる場所はあるよ。レストランみたいにまだ後払いできるとこもあるけど、客を信用してくれる場所は減ったよね。
＞ 特にB2B SaaSの…驚くかもね。
B2B SaaSの自己管理にブラウザ不要？驚きだね。
＞ ウェブサイトやアプリ作りの…UI/UXだったんだよね。
管理UI/UXの多さね。検証が無いと疑問。
＞ Excelとかで…ラクじゃん。
ExcelでDB直入れは、システム本来の価値（検証、ワークフロー、アクセス制御）を捨ててる。スケールしないし、絶対破綻するよ。
なんで？俺がもっと欲しいのは「配達員が[X]分圏内に入ったら通知して。着信音[R]を使って」みたいな機能だよ。Xは俺が階段降りて門を開けるのに必要な時間。顧客は物流の詳細で頭を clutter する必要ないじゃん。
＞ USでは長い間ガソリン入れてから払うのが普通だったし…
ガソリンスタンドでバイトしてたけど、未払いは日常茶飯事だった。防犯カメラとかで追跡してたからhonor systemじゃないよ。後払いビジネスには未払いコストがかかる（他の客負担）。システム悪用されるリスクも。こういうのは秘密が広まると続かないよ。
＞ スケールしないし、どっかで確実に破綻するよ。
USの銀行業務の多くは、ほぼ完全にこの前提で運営されてるし、ずっとそうだよ。
＞ エラー検出/報告、ビジネスワークフロー、役割ベースのアクセス制御
洗練されたビジネスワークフローがフラットファイルと非同期送信の上でも構築できるか疑うなら、Nacha (ACH) operating rulesを見てみなよ。
https://www.nacha.org/newrules
場所がズレてること多いから、ドライバーの位置が分かれば来てもらいやすいんだよね。Uber Eatsだとたまに変な場所案内されて、ドライバーがどこにいるか教えてくれないと道案内できないことあったし。
後払いビジネスって未払いが出るから、その分値段を高くしないといけないんだよね（それは他の客が負担してる）。高信頼社会を経験したことない人には、それが低信頼社会よりどれだけずっとうまくいくか理解できないのかも。悪意ある奴が数人いるだけで高信頼は簡単に壊れるけどね。そういう奴をすぐに厳しく拒否しないと…。
東南アジアに引っ越したら“ホットライン”ってやつにびっくりしたよ。だいたいどのビジネスもメッセージできる電話番号だけなの。ピザ買うのも家具買うのもホテル予約するのも、ソファ掃除頼むのも。ウェブサイトなし。フォーム入力もなし。プラットフォーム手数料もなし。
＞場所が分かれば来てもらいやすい
それってロジスティクスサポートの仕事をお金払って自分でやってるってこと？
木工会社はどうやって確実に支払いを受けてるの？特別なものだから“本物”の客しか買わないの？信頼関係？法的手段？逆で、会社が支払いの後ちゃんと商品を届けるかどうかってのが普通ってのは分かる。でも今の一般的な文化としては、会社は信頼できて客はそうじゃないってこと。ちょっと議論あるけどまあ分かるかな。
いやいや…みんなが本当に必要としてるのは、CRUDアプリとかをその場でシンプルに作ってくれるAIチャットボットだけだよ。そうすればExcelとか何もいらなくなるし、ネット全体が賢いデータベースになるんだ。b2bとかsaasとかadminとか？（笑）何それ？そしたらあとは外でリラックスするだけ。
変な話だけど、これってSatya Nadellaが言ってたことと似てるな。SaaSアプリとかビジネスアプリはエージェント時代に全部一緒になるかもって。なぜなら、それらは基本的にCRUDデータベースにビジネスロジックがあるだけだけど、ロジックは全部AIエージェントに行って複数のデータベースを扱うからだ。ロジックがAI階層に行ったらバックエンドを置き換え始めるだろうね。
「スプレッドシート送ってくれたらアップロードするよ」って、ユーザー体験としてはイマイチだと思う。ただのセルの集まりで説明もないし、ユーザーは山ほど間違える可能性があるのにフィードバックがない。入力できる選択肢も分からず変な値も簡単に入れられる。ヘッダーのタイプミスでデータ消えることも。ユーザーの間違い全てに対応するのは大変だよ。
うん。どんな状況でも一番いいやり方でやるのが好きだよ。「この問題を簡単に解決して、みんなにもっと良くなるのに、問題解決は仕事だし仕事は従業員だけがすることだからやめとこう」なんて今まで一度も思ったことないし。
東南アジアだと、そんなに良い電話とかスマホを持ってない人も多いから、テキストメッセージが便利なんだろうね。ガラケーがまだ主流の多くのアフリカの国でも同じだよ。
これが機能するには、社会全体が執行に参加する必要があるんだね。でも、現状だとそんなこと考えられない環境を作っちゃった。やろうとしないんじゃなくて、やると法的な面倒に巻き込まれるだけだからね。だから、特に米国の西洋社会の一般市民のやり方は、関わらないで全部法執行機関に任せることなんだ。
＞多くの状況で、ビジネスに設定のテンプレート（Excelファイル）を送って、その結果を直接同じSQLテーブルに読み込んでマージする方が、明らかに100倍速くて簡単でくだらないことがない。
＞Eメールやフラットファイルは、どんなウェブソリューションよりもはるかに柔軟だ。
HNを読んでると時々、自分がどうかしてるんじゃないかと思うよ。リクエストをメールでやり取りして、相手に手作業でSQLテーブルへのデータマージまでさせるなんて、見るのが奇妙な主張だね。たまにこういうやり方してる会社に出くわすけど、顧客としてもパートナーとしても、必然的に悪夢だよ。それに、詐欺から担当者が突然辞めて会社が立ち行かなくなるまで、あらゆるリスクの温床だ。これは、古き良きやり方を懐かしむ色眼鏡と、今の全てがダメに見える燃え尽き症候群が混ざってる感じだね。こういうやり方の会社と取引するのは、全然良くないよ。
＞多くの米国の銀行業務は、ほぼ完全にこの前提で、ずっとそうやってる。
フィンテックのスタートアップで金融機関とやり取りしてた時に、まさに同じような気付きがあったよ。ウェブサイトは、日々の業務の一部では全然必要ないんだ。CSVやExcelファイルを送り合うだけで、照合、決済、会計目的には十分なんだよね。
＞払わないことを選ぶこともできる。
この売り手が詐欺師の餌食になるのは時間の問題だね。見つかり次第だけど。昔、出版社のeコマース担当だったんだけど、当時はネット以前の”後払い”（acceptgiro）って支払い方法があったんだ。サイト公開から数ヶ月もしないうちに、誰かが数百ユーロ分の本を注文して、レンタル倉庫の住所に届けさせたことがあったよ。それ以来、一定金額以上の注文には後払いを止めたし、後には後払いは全部廃止して、前払い方法にしたと思う。最近はKlarnaとか新しい後払いスキームもあるけど、リスクと債権回収はこの決済プロバイダに移るんだ。もちろん、Klarnaは融資/クレジット会社なのに適切な法律表記をしてなかったって、最近法的トラブルになったけどね。
＞どんな状況でも一番理にかなうことを喜んでやるよ
この状況で一番理にかなうことって何？一番近いピザ屋まで歩いて行って、ピザ買って、おしまい。健常者なら5分もかからないはずだよ。おまけに、家までの帰り道もわかるだろ。
＞だって問題解決は仕事だから
他の人の問題を問題＝解決問題にしたのは誰？君だよ。配達員はそのうち君の場所を見つけるか、何かしらの理由で違うルートを使ってるだけだ。なんで君がソファから、人の仕事のやり方を指図できると思うほど傲慢なの？君の他人の行動をマイクロマネジメントする執着は、ただ君が高い不安を抱えてるって言ってるだけだよ。それで皆が良くなるとか、それは君が自分に言い聞かせてるだけだ。
実際、僕は真逆の方向に行ったんだ。職場にはメニューのウェブサイトがある社内カフェがあるんだけど、全部見るのにいっぱいクリックが必要なんだ。最初はデータをスクレイピングして、もっと良い（僕的に）コントロールができる独自のウェブサイトを作ろうと思ったんだけど、v0はデータをGoogle Sheetsに入れることにしたんだ。v1は必要なかった。Google Sheetsの”UI”でフィルタリング（朝食かランチかとか）、アクセス制御、基本的な分析（〜7人の同僚も毎日使ってる）は解決できちゃったからね。
これはピザ配達のアイデアに対する、全く常軌を逸した反応だね…
これはB2B SaaSが登場する前の100％B2Bがどう機能してたか、そして今でも99％のB2Bがこうやってるってことだね。
＞特殊な木工ツールをオンラインで買ったんだけど、単にフォームを埋めるだけだった。後で請求書と一緒に部品が届いて、代金を送金したんだ。払わないことを選ぶこともできる。
スイスでは支払い後の受領はすごく一般的だけど、詐欺はほとんどないらしい。君の名前は債務者登録に乗るだろうし、それは持ちたくない類の悪い信用履歴だね。どこかの時点で警察/債権回収が関わってきて、その住所に送られるとか諸々ある。平均的な人にとっては、無料のスポークシェーブ（木工工具）のために自分の名前と住所を潰す価値はないんだ。
＞ウェブサイトは、日々の業務の一部では全然必要ないんだ。CSVやExcelファイルを送り合うだけで、照合、決済、会計目的には十分なんだよね。
これが何十万もの”照合、決済、会計目的”をサポートしないといけなくなると、うまく終わらないんだ。
Excelファイル提供で似た経験あるよ。ぶっちゃけウェブアプリの最大のライバルって、昔ながらのExcel（かクラウド版）なんだよね。これに勝つのがマジで大変。
もっとコメントを表示（1）
フレームワーク反対じゃないけど、いらないことも多いよね。なんでコード書く前にまず100KBもJS足すんだろ？
うちのチームは https://restofworld.org をフレームワークなしで作ったんだ。そしたら、使いやすさとか読みやすさについて、 surveys やメールでめちゃくちゃ良い feedback が来たよ。
いつかフレームワーク使うかもだけど（決められたルールで議論が減るのは良いよね）、今は普通の JavaScript で十分うまくいってる。
こういう話っていつもズレてる例だよね。片方には30人以上のチームで本格的な ウェブアプリ 作ってる人がいて、フレームワークなしの話聞くと、自社の必須機能がどう動く？って質問攻め。
でもそれは blog だからそんな機能いらない。一方、大規模 ウェブアプリ 経験ない人は blog くらい簡単に作れるのにフレームワークなんて何で？って。
ウェブには色んな software があるんだから、何について話してるかハッキリさせようぜ。
これは WordPress の blog だしね。
別の見方だと、静的な ウェブページ 作るのに React とか framework 使う人もいるんだよね…
MVC framework の上に jQuery ちょっとだけの framework なし site で働いてる。
最初は良かったけど事業が伸びて software がデカくなり、一人じゃ抱えきれなくなった。問題だらけだよ。
例えば、ページ表示に5秒、 form 送信後も5秒。反応ないから何回もクリックしてエラー。注文できたの？
エンジニアとしても、触った JS file が関係ないとこに影響しないかとか、 template に手を入れると N+1 が何件起きるかとか、データがどこで読み込まれるかとか、追うのがマジ大変。
インタラクティブな部分は React で作り始めた。比較すると結構いい感じ。完璧じゃないけど components で考えるように促されるのが助かるよ。
他の部分にも導入したいけど framework が邪魔してきて時間かかりそう。
一部の人だけじゃない。 marketing ページとか簡単な form だけのページを React で作る例がマジで多すぎる。
会社で vanilla css+html とか静的 generator に移行しようって言うと、 assembly で書き直すのかよ！みたいな反応。
デフォルトのツールもっとシンプルにすべき。 React は分かるけど、最初から何も考えずに使うのは無駄に複雑。 html+css から framework に移る方が、 framework から他の何かに移るより100倍簡単だし。
どっちの方向にも大きく依存性があるんだよね。君のコメントの兄弟コメントがうまく説明してた。
ウェブサイト 作るか application 作るか、早い段階で理解するのに代わるものはないよ。
大昔—2002年！— Joel Spolsky って人が書いた記事：https://www.joelonsoftware.com/2002/05/06/five-worlds/
彼の主張は、 software 開発のツールや手法を議論する前に、どんな開発してるか決めるのが超重要ってこと。それぞれの「世界」には独自の要件があって、それが手法やツールを左右するから。
彼は Shrink-wrap、 Internal、 Embedded、 Games、 Throwaway を挙げた。 Shrink-wrap は今は過去のものだけど、彼の基本的なアドバイスは今も通じる。
ツールの議論をする時は、どんな開発に取り組んでるか明確にして、それぞれの世界のニーズが違うことを理解する必要があるんだ。
確実な答えが出るまでは、シンプルな方を選んどけってこと。
確実な答えなんて絶対に出ないよ。いつも確率論。その時点で一番成功しそうな可能性が高いと思う決定をするんだ。
これの良いところは、履歴の戻る・進むがめっちゃサクサクなことだよ。iPhoneで戻るとき、ページ全部リロードされるのに慣れてたからさ。
SPAsって必要なデータだけロードするから効率良いはずなのに、なぜか静的なページとか少しJSがあるページの方が戻る・進むがめちゃ速いし、戻るボタンも壊れないんだよね。SPAsっていつもなんかモッサリしてる気がする。
このバニラJSの例って、超シンプルなページと基本的な操作ばっかじゃん。検索付きのちゃんとしたテーブルとか、ラベルやバリデーション付きのフォームとか、リアクティブなやつ作るのにどんだけ時間かかるか見せてくれよ。
SvelteとかUIライブラリ入れれば数行でできるのに、それをゼロからなんでやるの？25kbのオーバーヘッドで、週かかる作業がもっと良い・見た目良い・テスト済みプロダクトになるじゃん。
今の要件で成功？それとも想像してる未来での成功の話？
コードがぐちゃぐちゃで、どっか触ったら50ページに影響するか分かんなくなるなんて、理解できないんだよね。それって構造が悪くて、抽象化が下手で、1つのモジュールに詰め込みすぎか、古い言語ならファイルに詰め込みすぎだよ。
特にウェブサイトってページを表示する流れはハッキリしてるはずじゃん。変なJSメニュー？menu.jsに入れればいい。
変更範囲が不明確で、何に影響するかすぐ分かんないなんて例が思いつかないんだ。WordPressとかのぐちゃぐちゃなら想像できるけど、ゼロから作ったなら設計か構造が悪いの。straw man（詭弁）で作っただけでは？
（2662への返信）想像してる未来のためだよ。
仕様が決まってるなら何の話？建てたいもの建てればいいじゃん。
でもこのスレッドは分からない時の話なんだ。『一番シンプルに始めろ』が常に正解じゃないのは、何を建てたいかの情報が少しはあるからだよ。全部がハイパーリンクのウェブページじゃないし、最初からそれは分かることが多いじゃん。
このコメントは、この手の会話がいつも全然かみ合ってない良い例だよ。
俺はフレームワークが常に必要じゃないって言っただけだろ。
”この場合：これはWordPressブログだ。”
違う。「ブログ」じゃない。ニュースサイトだよ。CMSとしてWPを使ってるだけだ。それがブログにするわけじゃないし、見下してるだけに見える。NYTも90年アーカイブ含めてWPでやってた時期がある。
他のニュースサイト、NYTimes, Polygon, Verge, Wiredとか見てみろよ、ほとんど何かしらフレームワーク使ってる。React, Preact, Svelte、なんでも。彼らにはこれで良いんだよ。UnderscoreとBackboneはNYTで開発されたフレームワークだ。常に必要じゃないし、無くても沢山できるんだ。
”A good example are pages that take 5 seconds to load… uniqueness constraints.”
提出ボタンを押したら無効にするのは25年以上前から標準的なやり方だよ。
もし開発者がこれをしてないなら、自らトラブルを招いてるようなものだし、トラブルを避けるのはすごく簡単なのに。
”how your frameworkless design handles a dozen different features that their use case absolutely requires”
そういう開発チームが絶対必要とする機能ってどんなの？1つか2つ教えてくれない？
一方には、30人以上のチームでフル機能のWebアプリを作ってる人たちがいるよね。Photopeaはフレームワークなしで一人で作られたフル機能のWebアプリだよ。流行りのフレームワークを使わなくても、機能満載のアプリを作るのは全然可能だよ。
あ～、そうだね、カテゴリーを一つ忘れてたわ。どれだけ状況を説明しても、恥ずかしげもなく他の人の仕事をけなして、自分ならもっとうまくできるって言い張る人たちだね。このグループは、内容のない、人をバカにしたコメントを残すのが特に好きだよね。ドグマはヤバいドラッグだわ。
＜br＞常に疑問に思ってたんだけど、一行もコードを書く前にページに100KBのJavaScriptを追加する必要ってあるの？＜br＞100KBなんて、俺が（契約社員として корпорацияで）関わったアプリでは考慮にも入らない量だったな。ほとんど大規模チームで働いてて、時には様々な業務ラインのアプリがReactを使ったマルチチームモノレポに入ってたよ。LoBとかB2B向けだと、初回のページ読み込みなんて誰も気にしないから、100KBなんて完全にどうでもいいんだ。＜br＞ユーザーは毎日アプリを使うから、ほぼ常にJS/CSS/静的アセット全部をブラウザキャッシュから読み込むし、新しい本番デプロイ（たいてい数週間ごと）があるまでね。それに、ユーザーはいつもEthernetかWiFiを使ってるから、砂漠の3G回線なんて使ってないよ。＜br＞Next.jsみたいな賢いフレームワークを使うと、ルートごとにJSが賢く分割されるし、それはイミュータブル（ファイル名に内容のsha256ハッシュが含まれる）なんだ。WebサーバーでCache-Control: immutableで配信するように設定してる。新しいバージョンがないかチェックするための往復通信すらないんだよ。＜br＞それに加えて、Next.jsにはバックグラウンドでのチャンクのプリロードとか、リンクにホバーした時に読み込むとか、他にもたくさんの機能がある。ホバーしてからクリックするまでの時間を使って、もうチャンクを読み込んでくれるんだ。初期レンダリングは静的HTMLで、ハイドレーションはユーザーに全く気づかれずに起こるなんて言うまでもないよね。
まさに言い当ててるね。で、「これはアプリケーションっぽいから、アプリフレームワークを選ぼう」って最初から言う人たちの多くは、君が今経験してることを既に経験してる人たちだよ。でも、同じ経験をしたことない人に、説得力のある形で説明するのはすごく難しいんだ。
これは決してけなそうとしてるわけじゃないんだけど、俺が知る限り、ニュースサイトとブログって同じ機能要件を持ってるんだよね。主な違いは、ニュースサイトの方がトラフィックと記事が多いから、より良いキャッシュが必要になるくらいかな。＜br＞もしニュースサイトがブログにはない要件を知ってるなら（記事のOPでサイトの作者だから知ってると思うけど）、ぜひ聞かせてほしいな。
やれるけど、それは論点がずれるからやらないよ。俺が言いたいのは、Webにはものすごい多様な要件を持つ、ものすごい数のアプリがデプロイされてるってことなんだ。もし具体例を挙げたら、その特定の例が本当にフレームワークを必要とするのかどうかの議論になっちゃう。そしたら、それが正当化される状況とか、されない状況とか、色々な仮説のオンパレードになっちゃうからね。＜br＞そんなややこしいことにはしたくないから、言いたいことは言ったつもりだよ。
＜br＞常に疑問に思ってたんだけど、一行もコードを書く前にページに100KBのJavaScriptを追加する必要ってあるの？＜br＞ほとんどのフレームワークでは、100KBのJSコードなんて必要ないよ。＜br＞正直、Mithrilならコンポーネント、vdom、ルーター、httpクライアントがgzipで10KBくらいに収まるんだぜ。
＜br＞このコメントは、こういう会話がいつも完全に断絶してることの素晴らしい例だと思うね。＜br＞正直に言うなら、いくつかの憶測をしてるこのコメントについても同じことが言えるかもね。ある人がWebアプリじゃない逸話を出したからといって、大した証明にはならないよ。俺はProgressive Enhancementを使った受賞歴のあるWebアプリを構築したことがあるんだ。コードは少なく、時間もかからず、パフォーマンスも良いし、同じくらいインタラクティブにできるんだ。お互いの議論の弱点を探すのはやめて、強みを探すべきだよ。俺もこれに関しては罪を犯してるけどね。
彼らは時間を気にするし、絶対に気にするよ。巨大な仮想DOMのゴタゴタが、ユーザーのインタラクションごとに応答に10倍も時間がかかったら、絶対気づくって。開発者だけが気にしてないんだよ、フレームワークから外れると仕事が危なくなるからね。
それはbackend-renderedのサイトはめちゃくちゃcachingが必要だからだよ。SPAsは普通、cachedされないAPIsを使う傾向があるし。
2k人くらいのusers向けに仕事してるけど、reactivityなんてマジで誰も気にしないよ…。monolithで作って、comfyにして、page refreshを受け入れようぜ（real worldじゃ誰もそんなの気にしないって）、そしてshitをdoneしちゃおう。
反論だけど、元々native desktop applicationsだったsystemが、たくさんwebに移行してるよね。これってtechnicalな理由ってより、practicalな理由が大きいんだ。deploying native applicationsはsimply too costly。
webはfinalmente applicationsをinexpensively deployするためのwidespread standardを提供してくれてる。unfortunately、webのuser interfacesのtechnologyはstill somewhat mediocreだけどね。
it’s unfortunate that history took some wrong turns with x11、java、flash、silverlight、.netとか、自分が経験してないのも含めて、historyが間違った方向に進んじゃったのは残念かな。
hopefully、someone will eventually find a way to make developing web applications comfortable and the broader community will embrace it。
もっとコメントを表示（2）
それでも、npm packagesを何もimportしなくても、cssとjsだけでめっちゃsimpleなrefreshing dynamicsはできるんだよ。
まあね、でもruntimeは、これやるのにbest wayにguideしてくれないんだ。hence frameworksがso prevalentなんだよ。
正直、ブラウザの挙動を調べるより新しいframework学ぶ方がマシってくらい、ブラウザはひどいと思ってる。
追記: マジか、みんなtechnologyへの真面目なapproach嫌いなんだな。
＞ native applicationsのdeployingはsimply too costly.
特にcorporate environmentsでなんでpeopleがthis impression holdしてるのか理解できない。windowsはsystemとper-user deployments両方support、後者ならadmin rightsすら不要。intuneでpull/push可能。
many desktop applicationsは.netでwritten、runtimeはpreinstalled。
clickonce deploymentsでさえpainless。
edit: naysayersへ: why steam is so successful at deploying large games on multiple platforms? 説明してくれ。
mpaよりbroken spAsをたくさんseenしてきた、by far. ironic、spAsはconversion ratesとuser experienceをimprove supposed to.
big companiesですらreddit (phonesでunusable)、x (mobile image loadingがbroken)。
if you’re writing an spA、twitter or content consumption platformでもなく、api-driven necessaryでもないなら、seriously stop. you’re not clever、experience improveしてない、only appealing to other programmers tastes. if billion-dollar companies can’t get them working perfectly、you certainly won’t.
huh? built-in APIs aren’t perfect、but simple as<br>fetch(’/my-content’).then(async res =＞ {<br> if(res.ok) {<br> document.getElementById(’my-element’).innerHtml = await res.text();<br> }<br>})<br>
something like that. doesn’t get much easier. gone are browser inconsistencies days、at least if you stick to “baseline widely available” APIs on mdn.
framework使わないweb tinkererだけど。document.getElementByIdをtypingするのにspentした人生のevery secondにnickelもらえるなら、new fingers affordできるわ。getId()にrenamedしてglobal scopeにputしとくべきだったtwo decades ago、if not three。at least querySelector()はfew characters shorter、but i always feel bad using such an alarmingly overdesigned tool for anything trivial.
FlashとかSilverlightはさ、それぞれが一社に牛耳られてたこと以外は全然問題なかったんだよね。俺はああいう技術好きだったな。Adobe Flexも当時のプログラミングとしてはすごく良かったし、使いやすかったよ。
どっちもクソ遅くて、めっちゃリソース食ったじゃん。
まあ、ちょっと選択バイアスもあるかもだけどね。SPAsが流行る前はダメなMPAsがいっぱいあったの、俺はハッキリ覚えてるよ。そのクソさがSPAsがメインになったらこっちに移っただけなのかもね。全体的に見ると、MPAsの方がデフォルトとしては優秀だと思うな。でも、良いSPAsを作るのは本当に本当に骨が折れるけどね。
＠view-transitionを使えばさ、cssだけでも滑らかな画面遷移できるんだよ。
これ見てみて→ https://developer.mozilla.org/en-US/docs/Web/CSS/＠view-trans…
そもそもMPAsへの不満って、ページ移動が遅かったのが一部の原因だったじゃん、新しいページ読み込むのが手間だったから。でも今のSPAsも、コンテンツ出てくるのさらに遅くて、ユーザーはスピナーをずーっと眺めてることもあるじゃんね。大事なのは、SPAだろうがMPAだろうが、サーバーの応答がクイックで効率的なことだよ。
そうなんだよね。理論上はSPAsが速いはずなんだけど、実際、テンプレート全部レンダリングして送るのも、そこまで悪くないんだよ。それに、君も言ってたけど、キャッシュ効かないAPIとかDBの呼び出しのせいで、どっちも遅くなる可能性あるし…結局さ…
俺たちは、要求を過剰に詰め込むことばっか目指す開発者を生み出しちゃった…それに合わせて、めちゃくちゃ普及したフレームワークも出しちゃったし…うちの会社は、React使えない人はもう採用できないんだよ…最近の奴らは、マジでゴミみたいなもんしか作れないんだ…
うわ、やだ、あんたも問題抱えてるじゃん :(
＞多くのデスクトップアプリは.Netで書かれてるから、ランタイムがOSに入ってるからインストール要らないんだよ。って書いてるけど、そんな風にデプロイされてた最後の.Netのバージョンは、もう10年も前の機能レベルだよ。今は必要な.Netの部分をアプリと一緒に固めて配るのが普通だよ。
なんでそんなに何度も書いてんの？10秒でエイリアス作れるじゃん？function getId(v) {return document.getElementById(v)}とかさ。Dev toolsなら$とか$$使えるし、マクロでも作ったらどうよ？
getElementById とか querySelector を document に直接使わなくてもいいんだよ。特定のノードから検索を絞ることもできるんだ。ほとんどの人は document がグローバルだからデフォルトで使ってるけどね。
ClickOnceよりウェブアプリのデプロイは全然楽！”いつものURLにアクセスしてね”で済むし、ユーザーのPC環境（謎のantivirusとか変な設定）に左右されないのが最高なんだ。ブラウザさえ動けば、みんな最新版を使える。ブラウザ動かない問題はどっちにしてもサポート対応でしょ。
view-transition はまだ Firefox でサポートされてないって言う価値あるね。
理論上でも、JSON生成って通常HTML生成より遅いんだ。直感に反するみたいだけど、reflectionでオブジェクトツリーを辿ってJSON作る方が、たぶん rope データ構造なHTMLテンプレート使うより遅いんだよ。
これって PowerPoint のスライド間のウザいアニメーションをウェブに持ってきたみたいだね。リンクされてるデモのトランジション、スムーズどころかかなり耳障りだよ。
ページ間のリロードは別に問題ない。
でも、入力時のフォーム更新ラグは許せない。
フロントエンドUIの良さって、大きいモニターとか速いPCみたいに、一度良いのを経験すると古い使い勝手には戻れなくなるんだよね。
”誰も何もやり方を知らないし、クソみたいに非効率で遅いし、なんでこのソフトウェア全部ダメなんだよ”
- フレームワーク使って作られたけど、抽象化されてるシステムの理解がない開発者によるものの顧客の声だよ。
古い iMac G5 をぶっ壊す勢いだったのは Flash だけだよ。
フルスペックの3D MMORPG、あの World of Warcraft ですら Flash ほどヤバくなかった。
消えてくれて本当に嬉しかった。
システムリソースを完全に無視する態度が許せなかったんだ。
.NET Core でもシステム全体デプロイはまだできるよ、 .NET 5+って呼びたいならそう呼んで。
https://learn.microsoft.com/en-us/dotnet/core/install/window…
