#静的サイトのパラドックス #十09
https://kristoff.it/blog/static-site-paradox/
より翻訳
あなたの前には2 つの個人的なウェブサイトがあり、それぞれがブログとして使用され、所有者の基本的な連絡先情報を表示するために使用されます:1 つは PHP で書かれた複雑な CMS で、Web サーバー、複数のワーカー、Redis キャッシュ、SQL データベースが必要です。このサイトには、シングル ページ アプリケーションとしてロードされ、JSON フォームでコンテンツを要求することでナビゲーションを実行し、クライアント側で「再水和」される大きなフロントエンド コンポーネントもあります。
もう 1 つは、静的 HTML ファイルと 1 つまたは 2 つの CSS ファイルのコレクションです。どこにもjavascriptはありません。
これ以上よくわからない場合は、ほぼすべての通常のユーザーが [2] を持ち、プロのエンジニアが [1] のようなものを持っていると予想されますが、実際にはその逆です。個人の Web サイトとして 2 番目のオプションがあり、ほとんどすべての通常のユーザーは複雑すぎるソリューションに悩まされています。
奇妙なことかもしれませんが、それはなぜそれが大きな謎ではありません: それはあなた自身ですべての中間ステップを理解するよりもWordpressブログをスピンアップする方が簡単です:ドメインを購入する
ホスティングプラットフォームを見つける
Dns を設定
SSGを見つける（または自分ですべてをハンドクラフトする）
デプロイ パイプラインのセットアップ方法について説明します
そのため、私たちソフトウェア エンジニアは GitHub Pages / Cloudflare Pages / などによる無料のホスティングとカスタム ドメインのサポートを楽しんでいますが、通常のユーザーは多数のユーザーに悩まされています 貪欲なピエロ そのため、99% のケースで静的な Web サイトであるはずの Web サイトをレンダリングするために不敬虔な量の計算能力を無駄にしながら、あらゆる小さなことの費用を支払わなければなりません。
先週、私はボストンの SquiggleConf で、HTML 用の言語サーバーを作成した経験について話しました。トークのほとんどは、導入時に何をすべきか（または避けるべきか）に関する戦術的なアドバイスですが、よりハイレベルな論点でトークを締めくくりました。これについては、このブログ投稿の結論としてここで完全に報告します。
SuperHTMLを公開したとき、私はそれがそうであることを発見しました 史上初の HTML 用言語サーバー 診断をユーザーに報告しました。それについてブログ記事を書きました hacker Newsの一面にて そして誰も私を訂正しなかったので、それが真実であることがわかります。
もともと面白いと思いましたが、もっと考えてみると、こんなことになるのは少し悲しいです。リンターは存在しており、人々はエディターで診断を取得できますが、通常、それはバニラ HTML ではなく特定のフロントエンド フレームワークに結び付けられたツールであるため、人々は、実際にはすべての複雑さを本当に必要としていなくても、フレームワークを使用することを選択することになります。それらのフレームワークがもたらすもの。
そしてそれは私の意見では悪いことです。シンプルさに対する抽象的な認識のためではなく、そのためです web はソフトウェア エンジニアだけのものではありません. 。Web を複雑にすればするほど、通常のユーザーを呼び出したいエンクロージャに押し込みます ソーシャルネットワーク.
弁護士や会計士がそれぞれのドメインがどのように機能するかを明確にできず、理論的には自分で操作できるはずのシステムの避けられない仲介者になってしまうのは腹立たしいと思いませんか？
ソフトウェア エンジニアリング、特に Webdev で単純なことを簡単にできないときはいつでも、まったく同じように社会を失敗させます。
これはスタートアップや大手テクノロジーが私たちにとって解決できることではありません。彼らの経済的インセンティブがあまりにもずれているため、部分的には私たちの技術に誇りを持っているという問題として、また部分的には、ウェブをよりアクセスしやすくするために皆さんにご協力ください。かつては、私たちとは異なる人々によってウェブが作られていたため、ウェブはより面白くなっていました。
私たちは今、アッシュビルでこの大事な時期に対処しています。細胞サービスがまったく戻ってきたとき、誰もがクソ断続的な 3G を持っており、基本的な生存情報に必要な Web サイトはどれもロードされませんでした。多くの善良な人々がいくつかのテキストのみのニュース サイトを作成しました。今日、バンコム郡の Web サイトにはついに低帯域幅のサイトがあることに気づきましたが、それでも調べてみると、130 k のブートストラップ css と 50 k の jQuery ブロッキング レンダリングがありました。人々がこの仕事をしているのは素晴らしいことですが、市民は 1 週間半前にこれを必要としていました。今では、水、食べ物、非飲料水などをどこで入手できるかを考え出しました。これらすべてを通じてテクノロジーがひどく失敗するのを見ることは、私にとって憂鬱な意味で目を見張るものでした。
それほど壊滅的ではありませんが、近所の停電時には、通常、セル信号が貧弱になります（ケーブル インターネット ボックスにバックアップがありません）。電力会社の停電マップはログイン (！) の後ろに隠されています そして、ファンシーなクラスタリングや、まともな接続であってもすでに遅いその他の UI 機能を使用してレンダリングされます。そのため、ステータスを確認したり、障害を報告したりするにはかなりの時間がかかります。
I could call the utlity company, but for some reason, they chose voice navigation (instead of keypad tones) for their menu, and it is not good at recognizing distorted voice (over bad 4G or 2G connection).
うわー、他のすべての Web サイトよりも著しく速いのは驚くべきことです。私たちは本当にインターネットをめちゃくちゃにしました。
そんな状況だったので、アマチュア無線の免許をまた取得しようかと考えました。アシュビルだけでなく、はるかに広い地域を含むノースカロライナ州西部に起こったような災害では、私はインターネットに基づいたものには何も依存したくありません。波長が長く、出力が低いものが欲しいです。しかし、それは非常にアクセスしにくいので、それが正当な理由があるかどうかはわかりません。
Connectivity was knocked out from Black Mountain all the way to the Tennessee and Georgia borders. I'd be surprised if many people even have shitty 3G back yet. What I know is remaining in touch with people who live there has been hard.
無免許で聴くことができます。$15 ハンドヘルドですべてを聞くことができ、非常に役に立ちました。
In an emergency you are allowed to transmit without a license. There were plenty of unlicensed calls going to the Mt. Mitchell repeater.
All that being said, I am definitely getting my license once this is over.
私が望んでいるのは、すべてのスマートフォンに FM ラジオが組み込まれていることです。FMラジオのICチップはありますし、Android携帯にもあるようです。緊急時にスマートフォンにスマートフォンの搭載を義務付けるのは当然のことのようだ。一体何が起こっているのかラジオで聞くためだけに、最初は車を走らせて貴重なガスを燃やさなければなりませんでした。
選択バイアスかもしれませんが、私の印象では、この機能のない携帯電話を見つけるのは非常に難しいということでした（Windows Phone やセミスマート フィーチャー フォン時代にも遡ります）。通常の欠点は、ケーブルがアンテナとして使用されるため、有線ヘッドフォンが接続されていない限り、ヘッドフォンが生き返らないことです。
あっ うん。アンテナなしでどうやって動くのか不思議でした。FM アンテナは、携帯電話に組み込まれている 5G アンテナよりも大きくする必要があると思います。
CBはおよそ11mの波長で、トン単位の電力を必要とせず、ライセンスも必要ありません。
2016年、私は地元企業向けのパンフレットウェアを製造する代理店で働いていました。私たちのクライアントの 1 人が、自分たちが構築した Web サイトに予約システム用の小さな iframe を追加することを望んでいたのを覚えています。彼らは私たちに一言の文書を送ってくれました。彼らはそれをHTMLとしてエクスポートしていただけであることが判明しました（Wordは現在でもサポートしているようです！) そして、それを安価な共有 Web ホスティング プロバイダーに投げ込みます。彼らにとってそれはとてもうまくいきました。印刷メニューを作成する単語 doc からエクスポートされるため、オンライン メニューを常に更新しておくことができます。当時、私たちは社内で彼らをからかっていました...今考えると残念です。レストランで他にやるべきことが 100 万あるとき、それは実際には天才的なアイデアです。
静的なサイトを作るのはまだ簡単です。HTML を生成するためのオーサリング ツールは現在最悪だと思います。そうでない場合は、サイトにサービスを提供するためにサーバー上で実行する必要があるプロセスがあると思います。
私は企業がこのようなことをするのが大好きです。うまくいけば、うまくいく。
私の仕事は、彼らがもっと良くなるかもしれないから彼らを嘲笑することではなく、彼らの解決策をより良くし、彼らがすでに行っていたことですでに成功したことを妨げることなく、彼らに対する私の解決策が、より良いとは言わないまでも、彼らの解決策と同じように機能するようにすることです。
多くの開発者は、私の経験を認めたくありません。少なくとも、これらのアドホック Web ソリューションの多くは、経験豊富な Web 開発者が独自に実装する大量の戦略よりも実際にうまく機能します。
重要なのは、ビジネスが何を提供し、顧客とどのように関係し、対話するかということです。場合によっては、単語ドキュメントが HTML にエクスポートされるだけで済むこともあります。私たちはスキルを使ってそれを向上させることができますが、本当の魔法はビジネスを運営する人間にあります。大好きだ。
私が楽しいと思うのは、これらのソリューションを改善する方法を見つけるのは、実際には本当に難しいことです。確かに、より良い Web サイトを作成したり、洗練されたインフラストラクチャなどで展開したりすることはできますが、結局のところ、顧客はそれを好むのでしょうか？それは彼らのビジネスを改善しますか？時々、その部分はまったく些細なことではありません。
完全に！印刷メニューの単語ドキュメントを Web サイトとして使用する魔法は、サイトを更新し続けるためのほとんど機能しません。トロント郊外のファミリー レストランに視覚的に素晴らしいウェブサイトがあるとは誰も気にしません。メニュー、営業時間、住所、電話番号を確認したいだけです。それは常に更新され、実際に支払う印刷メニューとまったく同じ内容であり、物事を言葉で読みやすくする方法をすでに知っていました。
この特定のレストラン（悲しいことに今は閉店）は 60-70 歳の男性によって経営されていたため、実際には私たちが提供することになったどのソリューションよりもさらに魅力的です。その男性は、切り取ったポートレート写真がロゴであり、index。html のヘッダーにある `float:left` でした。Word からエクスポートされました。そんな真贋は買えないと思いますよ。
もちろん、私は 19 歳で愚かだったので、これは面白いと思いました。最初のテクノロジー関連の仕事では、私は CodeIgniter ベースのお問い合わせフォームと静的な About Us ページを作成する非常にプロフェッショナルだと考えていました。
振り返ってみると、私たちはそれらを汚してやったと確信しています。私たちがそれらを販売したソリューションが何であれ（IIRC では、カスタム テーマの wordpress サイトが提供されました）、おそらくあまり役に立たなかったでしょう。どれが最悪ですか。
私は地元の政党と協力して、主にウェブ上でテクノロジーに関する意思決定を支援してきました。そして、この経験とこれまでの経験に基づいて、代理店は顧客を頻繁に汚しているという結論に達しました。意図的に境界線に見える場合もあれば、クライアントのニーズ、代理店の機能、コミュニケーション、そして最終的に提供されるものとの間の断絶であると思われる場合もあります。
非常に多くの人がそれを頼りにしているので、それを言うのは奇妙に思えますが、wordpressは非常に多くの点でやりすぎです。非常に多くのクライアントを際限なくイライラさせ、継続的なメンテナンスを必要とし、場合によっては非常に費用がかかります。また、サーバーのレンダリングやフォームの送信などを処理するアクティブなサーバーも必要です。大多数のクライアントはそれを必要としません。テーマさえ必要ないのです。
私が支援しているこのパーティーには、7 つのワードプレス サイトが点在しており、それらはすべてコストがかかりすぎるホスト上にあり、中にはまったく更新も保守もされていないホストもあり、使用率が約 40% でピークに達するサーバー上にあり、それ以外の場合はほぼ 40% でハミングしています。wordpress が必要とする以上のゼロ使用率。
これはインターネットの多くです。これらの人々との経験は、彼らのニーズを満たす何かを構築するきっかけになりましたが、それはこれらのものの 1 つです... わからない、もし私がそれを建てたら、誰かが来るとは思えない。でも ええ。インターネットに対するほとんどの人のニーズは非常に単純です。Wix やそれに類するものでさえ、あまりにも多すぎます。しかし、これらの基本的なブログ エンジンもまったく的外れです。これらのビジネス ユーザーのほとんどはブログに興味がありません。彼らはただ、さまざまな種類の情報を捨てて、それを永遠にぶらぶらさせることができるシンプルな本拠地を望んでいます。
これを修正することを目的とした製品がいくつか考えられますが、それらは私たちが説明しているタイプの人々にとって十分に単純ではありません。オンラインで何かが必要であることはわかっていても、それについてあまり知りたくないし、あまり学びたくない人々。
私はいくつかのレストランでコンサルティングを行っており、フルスタックの Web アプリケーションを構築した経験があるにもかかわらず、ほとんどの成果物について Excel にリーチしていることに気づきました。これらは、「非技術的な」レストラン経営者が快適に過ごすために必要な「アプリケーション」です。データを貼り付けて必要な出力を取得するシートを作成するには、最小限の継続的なメンテナンスとトレーニングが必要でした。Dropbox / Google ドライブでファイルをドラッグすると、うまくいきます。
私は今でも、構成やデータの正規化などから派生データから生の入力を分離することをできる限り「エンジニアリング」しようとしています。Excel の Lambda 関数を使用すると、FRP エディター/ランタイム環境で Lisp を作成しているふりをするだけです。PowerQuery を備えた ETL ツールは、これらのレストランの営業規模に非常に適しています。
Excel が何年も前に実現した機能をうまく再現できないという任務を負っているとき、フルタイムの仕事で頭がおかしくなるのは難しいです。
人々は物事を行うのにどれくらいの時間がかかるかを追跡することを忘れています。
「時間推定に長けている人」と「時間推定が常に間違っていると思っている人」に分岐しているのを見ます。前者は軌道に乗り、継続的に改善され、良好になりました。後者には手がかりがありません。
Web サイトを最初からセットアップするのは難しくありませんが、特にメンテナンスを行う場合は時間がかかります。
ビンゴ。これが、google シートが最高の cm である理由です。データをリッピングして Web サーバーにアップロードするデータ パイプラインがあるだけです
この夏、CDMX で私が行ったレストランがあり、そのメニューは Figma のドキュメントへのパブリック プレビュー リンクでした。私はその事実を見て笑いが止まらなかったが、それがうまく機能したことに喜んだ。こんなの好き。
私は、この [Vueテンプレート]（から作る小さな単一のHTMLファイルサイトのトンを持っています）https://vue-template。spaghet。me/) を。また、パブリック Notion ドキュメントとして公開されたばかりのサイトや、iCloud からのインライン写真ライブラリなどもあります。物を接続するだけで簡単かつ利用可能であること、そして、物をリンクするだけで済むのに、物事を過度に複雑にして最初から何かを構築したいと思うことがどれほど多いかは驚くべきことです。
余談ですが、私は [mmm。page] (https://mmm。page/)他のことをする時間がない場合は、小さなマイクロサイトや使い捨てサイトをすばやくつなぎ合わせます。これらすべてのツールを探索する楽しみ
私はフロントページの死を長い間呪ってきました。そうですね、私たちがそれをからかったのは、それが作成した HTML がひどい/ひどいからです。しかし、それはまた、通常の企業/人々が、適切なパスワードを選択する以外にセキュリティを心配することなく、小規模で安価な Web サイトを更新するために使用できるプログラムでもありました。
私はここ数年、words HTML エクスポーターよりも多くのオプションを提供する、より正しい HTML を作成できる優れた代替手段を探してきました。
つまり、ウェブのアイデア全体ではありません ブラウザ ウェブという理想に反するものでしょうか？それは暗黙のうちに人々をスピーカーとリスナーに分けます。
並行世界では、web ブラウザはウェビターと呼ばれ、Web サイトを編集したり表示したりできます。人々は変化を提案することができます。人々は注釈を公開することができます。Web ホスティングは、電子メールで好きなサービスを選択（または構築）し、好きなクライアントを選択（または構築）するようなものです。プロトコルが解決します。
ボンネットの下には、そのシステムの骨がそこにあります！`PATCH` はHTTP動詞には理由があります。
ただし、Web をこれほど公に編集可能な大量のドキュメントにすると、多くのスパムが発生することになります。Web サイトにフォームがある場合は、すでに多くのフィルタリングを行う必要があります。構造化データをフィルタリングする代わりに、差分をフィルタリングする必要がある場合を想像してください。
おそらく良い半分の対策は、Web オーサリング ツールを Web ブラウザに戻すことだと思います！私の記憶が正しければ、Netscape Navigator にはそれがありました。ただし、これにより HTML ファイルをディスクに書き込むことができるだけです。
HTTP Basic Auth および POST/PUT/PATCH/DELETE HTML を使用してページに直接ログインする標準プロトコルのボーナス ポイント。それを理解できる特別なサーバーが必要ですが、理想的には誰でも実装できるサーバーです。あなたはブラウザを指示します https://yoursite。com/my/page。html マート、HTTP基本 Auth 出ナーク、マート、HTTPベーシック Auth 出ナーク、マート、HTTPベーシック Auth 出ナーク、マート、HTTPベーシック Auth 出ナート、マート、HTTPベーシック Auth 出ナート、マート、HTTPベーシック Auth 出ナート、マート、HTTPベーシック Auth 出ナート、マート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベー
編集: プロトコルは間違った言葉です。誰かがこれを実際に何と呼んでいるのか訂正してくれました。HTTPベース...編集？標準のAPI？それは今私が作りたいものなので、それを理解する必要があります。
編集 2: ウィキについて言及した兄弟コメントの CamperBob2。私がウィキについて説明していることに気づきました（笑）
あなたが探している用語は存在します: ユーザーエージェント。
https://en。wikipedia。org/wiki/User_agent
あなたが説明したものは、Facebook のようなサイロの均質化効果の下に組み込まれて行ったり来たりしました。マッシュアップは大きな新しいものでした。それを元に戻そうとするさまざまな試みが行われてきましたが、サイロの慣性により、興味のある人を見つけるのは困難です。
それは真実ではないと思います。Figma はブラウザで実行され、HN も実行されます。
ブラウザの仕事は _render_ です。コンテンツを作成しているのか、単に読んでいるだけなのかはわかりません。
昔、mozilla（mozilla org が firefox を作成する前のブラウザ）は wysiwyg 方式で html を編集していました。私の初期のウェブサイトはすべてこれで作られていました。<br> を削除する方法を考えたことはありません
それは Wiki の背後にあるアイデアのようなものですよね？
そこ た ユーザーが既存の Web ページをマークアップ、編集、注釈を付けることができるブラウザ拡張機能を、ユーザーのコミュニティに表示される方法で提供するという何年も前の取り組み。残念ながら、おそらく穴が開いていたため、どこにも行きませんでした ウェイ 神聖な牛が多すぎる。（そして/またはスパマーによって採用され、ソーシャル ネットワーキング/評判管理プロジェクトに変わったでしょう。)
そうですね、それは 30 年前には良いアイデアでした。今では、Web は約 14 分でスパムと AI 生成のドライブでいっぱいになるでしょう。
現在では、コンテンツを適切にキュレーションすることがこれまで以上に重要になっています。
Web 開発者の個人 Web サイトには、履歴書駆動開発（RDD）という複雑な要因があります。
RDD のために個人的なサイド プロジェクトを使用しようとする専門家向け。そうすることで、雇用主が行うプロジェクトほど多くのプロジェクトを妨害する必要がなくなります。
たとえば、今朝につながります... インディーズ Web サイトの場合、私はこれから立ち上げようとしています - そして、主に RDD の理由から、人気のある最新の Web フレームワークを使用しています - - Web サイトを更新できなくなりました。
NPM パッケージには重大なセキュリティ上の問題があり、アップデートを取得しようとして NPM が相互依存関係の競合に悩まされ、自動的に解決できなかったためです。（皮肉なことに、これにより、セキュリティ アップデートを本番サイトにプッシュすることができなくなりました。)
このサイトには、インラインで JS が散りばめられた 5 つの単純な手書き HTML ファイルと、2 つの小さな Perl CGI スクリプトが含まれる可能性があります。そしてそれは25年間、そして今後も完璧に機能するでしょう。
代わりに、サイトの NodeJS 部分だけを対象とした 129 NPM パッケージと、頻繁にセキュリティ更新プログラム、および暗号ソース ファイル（テンプレート フラグメント、TS 構成、ハンドラー）の大きなツリーが必要になります。
しかし、ばかばかしいほど複雑な方法でそれを行うことは、専門家には余裕がありません ない する こと。（たとえば、履歴書に Perl を付けることは、雇用適性のための死の接吻になります）。年齢差別を理由にあなたの履歴書を捨てなかった人たちは、それでもあなたが RDD をやらなかったのは馬鹿に違いないと思うでしょう。
> web はソフトウェア エンジニアだけのものではありません。Web を複雑にすればするほど、通常のユーザーをソーシャル ネットワークと呼びたいエンクロージャに押し込みます。
この著者を大きくしてください。これは最近の会議に関する最近のポッドキャストです この引用は（Squiggle Conf）から来ました、 https://changelog。com/jsparty/339
彼らの「単純な」流れの最後の数点でさえ、過度に複雑です。すべての CMS の前に、テキスト エディターや Front-page などの WYSIWYG エディターを使用して、デスクトップ上のファイルに HTML と CSS を作成しました。専用の Web サーバーと同じように、ローカル ファイルから簡単にレンダリングできます。満足したら、SFTP 経由でファイルをサーバーにコピーします。Frontpage がそれを処理してくれるでしょう。現在でも同じ流れでうまくいっています。
ドットコムブームの頃、ウェブサイトを作成するための高品質のデスクトップエディターが数十台ありました。これらすべてのホスト型 SaaS システムは、プログラマー以外の人が Web サイトを作成しやすくすることを目的として、普及し始めたばかりでした。でも本当にそうだったのか？そうは思えない。現在、これらのシステムは非常に複雑であるため、使用するには誰かを雇う必要があります。しかし、プログラミングの背景すらなかったコンピューター科学の 1 年生は、依然として HTML と CSS を手書きで書いています。WordPress 用のテンプレートはこれらの複雑なプログラムですが、HTML と CSS 用のテンプレートは Hello World の例と同じくらい簡単です。
WordPress のキラーアプリはコメントです。SSG は、ほぼ定義上、コメントを許可しません。WordPress ブログには、ほとんどの場合、コメントが組み込まれています。
Hugoのようなものが本当にブログの球で離陸したい場合は、あなたがする必要があるのは、いくつかの良い見栄えのテーマを作成することだけです コメントあり。おそらく、1 ドル 1 ペニーでサードパーティとしてホストできるブログごとのシャード SQLite を使用して、それを大規模に把握してください。手には小さな金色のガチョウがいます。
ブログの時代にはそうだったと思いますが、今ではそうではありません。
投稿に対するコメントやディスカッションは、reddit、hn、さらには Facebook などのサードパーティ コミュニティで見つけることができます。たとえば、サブスタックの投稿の下にあるコメントのリストをスキャンした人のうち何人が、同じ投稿の HN コメントの 1 ～ 2 ページをスクロールしますか？
IMO では、HN に関するディスカッションは、特定の投稿に対するコメント チェーンよりもテクノロジー関連の投稿の方が質が高いという当然の結論です。HN はすでに全ブログの 99。9% よりも幅広い読者を魅了しているからです。
ブログ投稿に直接コメントする主な利点は、投稿が HN の一面にある一時的な状態と比較して、作成者がブログ投稿を見る可能性がはるかに高いことです。
ソーシャルメディアサイトに参加する人が増えれば増えるほど、会話は悪化します。
テクノロジー関係者がレディットから逃亡する中、これはすでにHNにも起こっている。
特定の投稿に対する新しいコメントのほとんどは、リンクされたコンテンツを読まず、2 番目の段落で取り上げられた内容について苦情を言った人たちです。
これは進化のプロセスであり、最も多くのエンゲージメントを獲得するのは、最初に反応または反応するコメント投稿者です。先行者アドバンテージは、そのポストが受けるエンゲージメントによってさらに高くなるにつれて確立されます。
回答する前に深く考える人は、よく考えられたコメントが第一印象の海の下に埋もれてしまうと落胆します。
すべての人にとってトップコメントやトップページを共有するプラットフォームではエンゲージメントが非常に不平等であるため、この報酬サイクルはより多くの人によって増幅されます。最初のいくつかのコメントに進むか、何も得られません。
Discord や Facebook などのサイトは、ユーザーをより小さなグループに分割することで、衝動的な少数の人々によるエンゲージメントの独占に対抗しようとしています。社会的交流をめぐる競争が減少すると、勝利戦略の多様性が高まります。進化のプレッシャーは依然として存在しますが、プラットフォーム上の他の人々と対話するためだけに「勝利戦略」を完成させる必要はありません。
コントラスト Reddit または YouTube ビデオ。注意の集中は、SEO、製品レビュー、または広告により金銭的価値があることを意味します。大規模な視聴者の価値により、プラットフォームの競争力が高まります。競争力とは、多くの YouTuber や Redditor が注目を集める行動を専門化することを意味します。これには品質が犠牲になります。
おろしポスト！「WordPress ブログ」に関する私の Web サイトをチェックしてください https://www。sevarg。net/ 気に入ると思う！; の
Are you 確かに コメントはまだ望ましいですか？インターネットのステップ1 はもう「コメントを読まない」ではありませんか？
そうは言っても、私は実際に、ホスト型サービスを利用する意欲があれば、多くの人にとって簡単に実行できる、ブログ上の「動的なコメントを含む静的サイト」のソリューションを考案しました。Discourse（PHPBB の後に多くの場所が移行した最新のフォーラム ソフトウェア）には、コメント用のページと統合する方法があるため、私は少なくとも 3 年間、特に問題なくそれを使用してきました。私は自分の Discourse install をホストしていますが（変です。データセンターにサーバーがまだラックアップされています）、他の人に料金を払ってそれを行ってコメントを提供できない理由はありません。
興味深いことに、discourse のコメントで得たスパムの量は、Blogger でホストしていたときに得たスパムの量のほんの一部です。それは私にとってもう大きな問題ではなく、PHPBB フォーラムや Blogger では常に迷惑でした。
サイトの残りの部分は、私が購入したテンプレートをベースにした Jekyll だけです（まともな外観の Web サイトを作ることができないため）。その後、私が望むことを実行させるために、長年にわたって何度もハッキングしてきましたが（応答性の高い画像、主に - 私は依然として低帯域幅接続の人々に敏感です）、メンテナンスの点ではまったく悪くありません。レンダージョブを起動するだけで、いくつかのスクリプトが新しいファイルをアップロードします。
>コメントはまだ望ましいと思いますか？インターネットのステップ1 はもう「コメントを読まない」ではありませんか？
それは誰に尋ねるかによって大きく異なります。読者として、私は いつも 記事のコメントを確認してください。私にとって、これはインターネットの楽しみの 75% にすぎません。クソ番組ならなおさらです。誰もが同じように感じているわけではないことは理解できます。私は何年もの間、さまざまな人々から Twitter がゴミ捨て場であることを聞いてきましたが、私にとって Twitter は、人々がお互いに反応できる他の場所よりも劣ったり、優れているわけではありません。
もちろん、この質問をコメント スレッドの 3 レベルの深さで行うと、このような答えが得られます。生存者バイアス。
Wordpress のキラー アプリはコメントではなく、プラグインのエコシステムです。Hugo で週末に設定するのに費やすすべてのプラグインが Wordpress にあり、お母さんが 2 回クリックするだけで有効にできます。
私自身 Hugo を使用していますが、エンジニアリングの観点からフットプリントが不要であっても、Wordpress ではユーザー エクスペリエンスがはるかに優れています。
もう 1 つの「対話型」部分: お問い合わせフォーム。
すべてのビジネス サイトがコメントを求めているわけではありませんが、おそらくお問い合わせフォームが欲しいでしょう。電子メール アドレスを入力する方が代替手段ですが、入力パイプラインの処理の方が適しています。
静的サイトでは、送信を処理し、サイトに正しく接続するために信頼できるサービスを見つける必要があります。それは別の可動部分となり、場合によっては別々に支払う必要がある別の請求書、業界が統合されるときに対処する必要がある別のビットなどになります。
そうは思えない。コメントは以前は大変なことでしたが、最近ではスパムやモデレーションに関する多くの問題に対処するためにサインアップしています。
正直に言うと、私が最も望んでいないのは、私の個人サイトを汚すために土地に自由にアクセスできるようにすることです。もしかしたら、どこかの人に価値をもたらすのかもしれませんが、ついにその人の電源を切ったことで、私の精神的健康は良くなりました。
私は静的になることを検討していますが、これが文字通り私が抱えている問題です。静的サイトにコメントをボルトで固定する、すぐに使える方法（例: Javascript の何か）はありますか？
おそらくdisqusでしょうか？サイト所有者にとっては不透明だと思います。ユーザーは Disqus に認証するため、db は必要ありません。
私は私の手でコード化されたサイトで SuperHTML を試しましたが、報告された問題は 1 つだけであり、その問題は私の知る限り間違っています。`</html>` タグが HTML 5 ドキュメント上で `<！で開かれることはないことがわかります！DOCTYPE html>` opening tag。著者は、これは完璧ではないと言っており、念のため私の理解を再確認する必要があるでしょう。いずれにせよ、それは役に立つことのようで、それが欠けているとは思わなかったことにも驚いています。
私のような人で、この用語を知らない人のために説明すると、「HTML 用言語サーバー」とは、HTML 構文を評価するプラグインを指します。これはツールの狭い説明かもしれませんが、それが私が試してみた基本的なアイデアです。
Web サイト所有者の観点から UX を考えると、これは実際には矛盾ではありません。Wordpress を使用すると、たとえオーバーヘッドがはるかに大きかったとしても、物事を簡単に行うことができます。
トレードオフが物事の構成に時間を費やすことだと考えている場合、それは単なる矛盾です。いいえ、ほとんどの人にとっての選択肢は、誰かにお金を払ってウェブサイトを立ち上げてもらうことです。
誰かが Hugo 用に WYSIWYG エディターをセットアップし、数回のクリックでドメイン登録から公開サイトに移行すると、大儲けするでしょう。
>>> 誰かが Hugo 用に WYSIWYG エディタをセットアップし、数回のクリックでドメイン登録から公開サイトに移行すると、大儲けするでしょう。
これはNetlify、Squarespace、Github Pagesのような企業がやっていることではないでしょうか？netlify を使用すると、パークされたドメインを転送し、テンプレートを選択すると、構成の大部分が実行され、数分で起動して実行され、ドメインが通過するまでに約 24 時間かかることがわかります。
しかし、あなたの言っていることはわかります。たとえあなたが話していることに近い企業であっても、マイナーな仲介業者のステップに対処することは、それを理解できる人にとって恩恵となるでしょう。
「基本的な Web サイト」が何をすべきかについてのほとんどの人の期待は、時間の経過とともに大きく高まりました。
プログラマーである私も、静的サイト ジェネレーターのトラップに何度か陥ったことがあります。
静的サイト ジェネレーターを使用してサイド プロジェクトを開始すると、小さな機能を追加したいことに気づき、突然、単純な Rails または PHP アプリで開始したいと思うのは迷惑です。
最近では、静的サイトが必要な場合は、html ファイルのフォルダーから始めるだけです。バイクのシェディングやツールの先延ばしをせずに、アイデア -> の実行から実行するのがはるかに複雑ではなく、より迅速になります。
html と css を手動で書くのはとても嬉しいですが、—I は誰にでもお勧めしません。
もう 1 つの素晴らしい点は、レールに「中止」することにした場合です.。 html ファイルのフォルダーを rails パブリック/フォルダーにコピーできます。かなり簡単なアップグレード パスです。
> プログラマーとしても、私は静的サイト ジェネレーターのトラップに何度か陥りました。
> 静的サイト ジェネレーターを使用してサイド プロジェクトを開始すると、小さな機能を追加したいことに気づき、突然、単純な Rails または PHP アプリで始めたらよかったと思うのは迷惑です。
例がなければ議論するのは難しいです。私は 10 年以上前に Pelican を使い始めましたが、今でも満足しています。時々、動作をカスタマイズするためにコードを書きますが、それは数年に一度です。シンプルで、そして ただ働く.
ダイナミック サイトで見逃している点はありますが、HTML ファイルの単純なフォルダーが Pelican よりもいかに優れているかはわかりません...
私は 20+ 年間、自分の個人 Web サイトに投稿してきましたが、それは次のようなものでした。basic HTML -> Drupal（whew）-> Wordpress -> basic HTML（jekyll 経由）。
私の Web サイトの機能肥大化に対して私が設定した基本的なルールは、私がウェブサイトに何を求めるか、つまり私が行ったことのアーカイブを定義することです。アーカイブとして、時間内に非常に耐久性のあるものにしたいと考えています。したがって、コピーしたり、ミラーリングしたり、あらゆるホスティング プラットフォームで動作させたりするのが非常に簡単な静的ファイルです。
バイリンガルサイトを持つことを釘付けにするのに時間がかかりましたが、:)しかし、少なくともそれは私が一度支払った代償です。
ブログでは Hugo を使用します。スタイルではなくコンテンツに集中する方が簡単だからです。だからこそ、私は純粋な html ファイルを書くのが好きではありません。何かが html ファイルにハードコードされている場合、スタイルの変更も問題になる可能性があります。
より高度なタスクの場合は、機能を追加するのが非常に簡単なので、django で書きます。
もしかしたら、ニーズに合った静的サイト ジェネレーターが見つからないだけかもしれません？
Jekyll は Ruby 分野で最もよく知られていますが、特定のニッチ分野に合わせて調整されており、Markdown または別の軽量マークアップ言語でブログを作成しています。確かに他のことを行うようにマッサージすることはできますが、汎用の静的サイト ジェネレーターとしてはそれほど人間工学に基づいたものではありません。
レールにコピー/貼り付けが簡単なものが必要な場合は、erb/haml と ActiveSupport で最初から書き始めることができるため、middleman のようなラックベースの静的サイト ジェネレーターが最適です。
HTML と CSS の手書きのシンプルさを求めているが、インクルード、部分テンプレート、リンク ヘルパーなどの優れた機能が必要な場合、nanoc は進歩的な優れた静的サイト ジェネレーターです。プレーン HTML/CSS から始めて、必要に応じて追加機能のみを追加します。
プレーンな html ページを持つページ間の共通性をどのように扱っていますか？iframe を使用しない限り、すべてのページ（ヘッダー、フッター、ナビゲーション）で共有されているもの、またはほぼ同じものをすべて手動で同期する必要があります。かなり迷惑だ。
確かに、親は実際にはすべてに対してプレーンな html ファイルを意味していたわけではありませんが、もし意味を持っていたとしても、おそらくサーバー側のインクルードを使用しているでしょう。
私は組織のためにブログを運営しています。平均して 1 営業日あたり 1 件の投稿を行っており、通常は約 3 件の投稿があります。私は何年も前に Django/Wagtail/Puput と一緒にこの曲をセットアップしましたが、それ以来、それは幸せに動き続けています。人々が投稿ごとに独自の新しいファイルを作成し、独自の HTML を作成しているとしたら、管理するのがどれほど迷惑になるか想像できません...
ただし、その Python/Django スタックとサーバーを維持する必要がありました.。 だろ？！私は何百もの Django リリースのアップグレードを行ってきました。自動的でも時間フリーでもありません。
ほとんどの SSG、特にブログ向けの SSG は、Markdown などのより優れたマークアップ システムを受け入れます。マルチユーザー システムであっても、物事を追跡するのは難しくありません。
技術者以外の人々に git ワークフローに慣れてもらうのは最も難しい部分です。
> 最近では、静的サイトが必要な場合は、html ファイルのフォルダーから始めるだけです。
ここも同じ。コンテンツに。md —>。html ステップを追加することを検討しましたが、まだ必要な — が見つかりませんでした。
> もう一つ素晴らしいことは...
私は、ローカル サーバー経由で自分のサイトを —easily—view できるのが好きです。最良のケースは、file:// でも表示できるケースですが、組織を完全に把握することができず、ファイルベースの表示用に別のコピーを生成する「make local」ステップになってしまいました。
今、私はあなたがサーバー側のコードを必要とするあなたのウェブサイトにどのような機能を追加することになるのか疑問に思っています。コメントシステム？
理想的な世界ではそうです。しかし、過去の経験から、多くのユーザーは mailto リンクの関連付けが誤って設定されています。
ひどいユーザー体験です。
はい、対象者によります。この記事の内容が個人的な Web サイトの場合、ほとんどのハッカー ニュース ユーザーにとっては問題ないでしょう。誰かが私にメールを送ることができなければ、おそらく私のウェブサイトはまったく表示されないでしょう。ただし、祖父母の個人 Web サイトを作成する場合は、バックエンドを備えた適切なフォームの方が適しています。
このコメントの下には、「ああ、適切な SSG が見つかっていないだけだ。これは良いことだ」というコメントがいくつかあるのが面白いです。善意ではありますが、完全に的外れです。
私はそのパラドックスに当てはまりました - 私はフレームワークやデータベースなしで最新の PHP で自分の個人 Web サイトを書き直しました。ほとんどが静的サイトですが、PHP を使用してヘッダーを追加したり、リスト（ブログ投稿用）に対処したりします。そうでない方が少し便利だと感じました 完全に 静的。記事を書いて、コミットして、プッシュするだけで、オンラインになります。ほとんどの静的サイト ジェネレーターは複雑すぎることがわかりました。
単一のページのコードは次のようになります: <?php $this->title = "Blog Article Title"; $this->shortTitle = "Title"; $this->date = mktime(0,0,0,1,27,2024); if ($this->mode == PageMode::Meta) return; ?> <p>Raw HTML content here<p>
サイトヘッダーとフッターを自動的に追加するルーターがあり、フォルダーに「_layout。php」ファイルを追加して、子ページの別のレベルのレイアウトを追加できます。ブログ リスト ページでは、フォルダー内のすべての個々の記事ファイルをスキャンしてインデックスを作成するだけです。それ どこ その $this->mode == PageMode::Meta 入ってきます - 各ファイルのコードを実行し（メタ データを取得するため）、残りをレンダリングする前に終了します。多くのコンテンツに拡大するつもりはありませんが、問題になった場合は調整します。
私の「フレームワーク」の PHP コード全体は、わずか 4 つの PHP ファイル（init。php、functions。php、Layout。php、および Page。php）です。
開発者であることの利点は、構成やデータの代わりにコードを使用できることです。また、コードを使用してコンテンツをより効率的に書き込むことができます。
結果は（まだかなり不完全ですが）次のとおりです: https://www。codaris。com/
私はちょうど私のウェブサイトの1 つ、ヘッダーのための90% htmlしかしphpのために同じことをし、少数の奇数の全体的なビットのためのinclude()を始めた。
初期の Web ブラウザは、Web サイトを表示するだけでなく編集するように設計されていると思いました。
そのアイデアはもうなくなってしまったと思います...
> これ以上よく知らない場合は、ほぼすべての通常のユーザーが [2] を持ち、プロのエンジニアが [1] のようなものを持っていると予想されますが、実際にはその逆です。個人の Web サイトとして 2 番目のオプションを使用しており、ほとんどすべての通常のユーザーは複雑すぎるソリューションに悩まされています。
私は混乱しています。その逆は、プロのエンジニアが [2] を持ち、通常のユーザーが [1] を持っているということです。しかしその後、プロのエンジニアはほとんど誰も [2] を「余裕」がないと彼らは書いているので、誰もが [1] を持っているようです...？
読み続けると、次の文にその理由が示されます:
> 奇妙かもしれませんが、その理由は大きな謎ではありません。Wordpress ブログをスピンアップする方が、すべての中間ステップを自分で理解するよりも簡単です。
これは、プロのソフトウェア エンジニアである少数の人だけが 2 番目のオプションを利用できることを意味していたと思います。
将来的には、変更の公開の容易さが、比較において考慮されるべき差別化要因となります
It is indeed written as you say; I suspect - but cannot confirm - that author meaning: それは確かにあなたが言うように書かれている; 私は疑うが、確認できない - 作者が意味していた:
> ... プロのソフトウェア エンジニアである少数の人だけが「余裕」を持っています ...
それは逆になります。
ただし、読書の期待を覆すものであっても、書かれているとおりに読む場合は、多数（ほとんど？)の場合があります プロのソフトウェア エンジニアは COTS システムを使用して公開していますが、独自のサイトをゼロから生成している人はほんのわずかです。
私はそれを次のように読みました:「私の個人的なxのためにそのような複雑なスタックを実行することの複雑さのオーバーヘッドを買う余裕はありません」
> SuperHTML を公開したとき、それがユーザーに診断を報告する史上初の HTML 用言語サーバーであることを発見しました。私はそれについてブログ投稿を書き、ハッカーニュースの一面に掲載されましたが、誰も私を訂正しなかったので、それが真実であることはご存知でしょう。
おそらく、これは Microsoft が LSP を思いつく前に、ほとんどの IDE が何年も行ってきたことだからです。
最も人気のあるエディターの中で、バニラ HTML の診断を提供する方法を持っていたエディターは誰もいなかったと思います。私が知っている唯一の例外は Webstorm です。
Vim、Neovim、Helix、Zed、VSCode はすべて、診断サポートのない同じ基本実装を共有していました。
Helix では、次のリリースから、SuperHTML がデフォルトで有効になります: https://github。com/helix-editor/helix/pull/11609
私はエディタではなく IDE を書きました。ASP。NET と Java EE/Spring の開発を行った数年間は、2001 年以来修正するのに十分な HTML 診断があったと確信しています。
矛盾はまったくありません。シンプルさは美しいですが、複雑さは売れます。著者は、価値は実現された効用から得られると考えています。しかし、ほとんどの市場セグメントでは、価値は認識から来ていました。複雑さ（役に立たないものでも）を使用すると、知覚される価値を高めることができます。すべての偉大さがボンネットの下にあるとき、あなたはどのように人々を感動させますか？
私はいくつかの SSG を使用しており、自分で 1 つ書きました。支払い意思のある人にはまだ SSG を推奨できません。
> 著者は、価値は実現された効用から得られると考えています。
世界の大多数にとって、Wordpress は確かに SSG よりも多くのユーティリティを提供します。Wordpress は 5 分間のインストールで有名で、その後すべてがインストールされます ただ働く.
_realized_ ユーティリティ。
また、記事はフルマネージドWordpress vs セルフホスト（またはPaaSホスト）SSGについてです。セルフホストWordpress vs セルフホストSSGのどちらかを選択する場合、結果は大きく異なることに私は賭けます。
さて、あなたはなぜOPがアップル対アップルの比較をしなかったのか疑問に思うかもしれません、フルマネージドWordpress対フルマネージドSSGのように まあ、フルマネージドSSGは存在しません、それは売れないからです！
インターネット接続についても同様です（使用量が減り、消費者がより多くの料金を支払う）。技術者は、たとえば 200mbps を超える量は必要ないか、飽和することはないことを知っています。一方、消費者は「200/500/1G」オファーを見て、その中間のオファーを選択します。
これが私を静的サイトから遠ざけた理由です。すべてのことを行うのはあなた自身でなければならないので、実際にはそれ以上の作業です。
確かに、ビルドをホスティングして生成するためのオプションはいくつかありますが、試してみたところ、それほど良くなかったか、いくつかの問題などがありました.。 一方、wordpress。com は失望することはなく、iOS と Android 用のアプリがあり、インターネットがあればいつでも更新できます。もちろん、インターネットがあれば可能です。
だからこそ、今ではObsidian Publishを使っています。もちろん、黒曜石の金庫室からサイトを構築するために Quartz やその他の代替手段を使用することもできますが、箱から出して電話で使えるものはありません
完璧なソフトウェアなどというものは存在しない。すべてにトレードオフが伴います。もちろん、mkdocs を除きます。
私はジキルやヒューゴなど他の人を知っていますが、mkdocs のシンプルさに匹敵するものを見たことがありません。サイト全体を探して構築されており、見栄えの良いナビがあり、すべてがマークダウンされています。
一番いいところは？これが私の「ビルドパイプライン」です。
$ mkdocs ビルド
$ scp -r./build <user>@dangerlibrary。com:/site
大好きだ。
これはエンジニアの単純さに対する見方です。
普通の人間は、コメントを有効にするチェックボックスのようなものを驚くほどシンプルなものとして見るでしょう。
> 奇妙かもしれませんが、その理由は大きな謎ではありません。Wordpress ブログをスピンアップする方が、すべての中間ステップを自分で理解するよりも簡単です
あるいは、選択したオフィス スイートである publii を使用したり、bad html と css を手入力して、非常に安価なホスティング プロバイダーに生のファイルを渡し、ぎこちない、時には醜い「Web サイト」を楽しむこともできます。
このユースケースの業界は、外観と発見可能性に取り組んでいます。WP の大きく肥大化したくだらない部分と静的なピエロ ジェネレーターの二分法は、Google でも機能する美しい Web サイトを持っていることに立っています。他の代替手段（ビルダーやディレクトリなど）も同様に機能しますが、サイトのプロパティもクライアントから剥奪されます。それは、これらのソリューションが安価で、ファストファッションであるという理由だけです。
良い出発点だ。strattic、キャッシュ プラグイン、および sqlite でのクエリのオフロードの後、ゲームのかなり遅い段階で、コンタクト フォームなどの避けられないインタラクション パーツがいつ、どのように実行されるのかを見てみましょう。
> 弁護士や会計士がそれぞれのドメインがどのように機能するかを明確にできず、理論的には自分で操作できるはずのシステムの避けられない仲介者になってしまうのは腹立たしいと思いませんか？ソフトウェア エンジニアリング、特に Webdev で単純なことを簡単にできないときはいつでも、まったく同じように社会を失敗させます。
私はこれのためのより良い言葉は「率直」だと思います; 神話の男月を参照してください:
> ただし、特定のレベルの機能については、最もシンプルかつわかりやすく指定できるシステムが最適です。シンプルさだけでは十分ではありません。Mooers の TRAC 言語と Algol 68 は、異なる基本概念の数によって測定されるシンプルさを実現します。ただし、それらは簡単ではありません。やりたいことを表現するには、多くの場合、基本的な設備を複雑かつ予期せぬ組み合わせで組み合わせる必要があります。組み合わせの要素とルールを学ぶだけでは十分ではありません。また、慣用的な使用法、つまり実際に要素がどのように組み合わされるかについての伝承全体も学ばなければなりません。
> シンプルさと単純さは概念的な完全性から生まれます。すべての部分は同じ哲学と願望の同じバランスを反映する必要があります。すべての部分は、構文では同じテクニックを使用し、セマンティクスでは同様の概念を使用する必要があります。したがって、使いやすさによって、デザインの統一性、概念的な完全性が決まります。
静的サイトは、お問い合わせフォームを用意するか、基本的なコメントを追加する必要があるまでは最適です。はい、外部サービスを使用して静的サイトにそのような機能を追加する javascript を展開できますが、基本的な WordPress サイトを使用すると、すべてがすぐに実行できます。
連絡先フォームは、電子メール アドレスのひどい代替手段です。多くのサイトがコメントを完全に削除しました。はい、これらのものはあれば良いかもしれませんが、静的サイトがあるかスクリプト化されたサイトがあるかを決定する要素であってはなりません。
丁重に反対しなきゃ。ビジネス/ポートフォリオなどの Web サイトを運営している場合、お問い合わせフォームを使用してあなたに連絡する可能性が高い人の数は、単に電子メールを送信するように指示するよりもはるかに多くなります。クエリを分類してさまざまなユーザーに伝える必要がある場合、またはより具体的な情報が必要な場合にも、連絡フォームは適切に拡張されます。
連絡先フォームをページに埋め込むことを妨げるものは何もありません。
Netlify イベントにはアクションを記録するワークフローが組み込まれているため、インフラストラクチャをセットアップする必要はありません。
十分に公平です。おそらくさまざまなユースケースについて話しているのではないかと思います。クエリを分類してさまざまなユーザーにチャネリングしている段階にある場合、あなたのサイトはすでにバックエンドを正当化するのに十分な「ヘビー級」になっている可能性があります。
> 多くのサイトがコメントを完全に削除しました
そして、多くの人がまだ持っています。ほとんどのwordpress。comとブロガーのブログにコメントがあると思います
まさにこのコメントを書くためにここに来ました。この記事は、WP が無駄であると仮定するのが間違っています。これにより、ユーザーには大きなオプションが与えられます。エンジニアはおそらく、静的なページを操作し、インタラクティブ性が必要になったら Web ページのアーキテクチャ全体を変更する余裕がありますが、エンジニア以外の人は、連絡先から始めるスケーラブルなソリューションを採用したいと考えています。各フェーズ移行時にセットアップを再発明することなく、情報を収集し、ゆっくりと個人ショップなどにたどり着きます。
オプション性と機会費用について言えば、多くのエンジニアはテクノロジーにおける目に見えない機会費用を理解するように訓練されていますが(「yagni」や「テクノロジー負債」という言葉がよく使われます）、経済的機会費用、つまり時間と時間を無駄にする経済的機会費用を理解できていないことがよくあります。機械ではなく人間の認知努力。例: 多くのエンジニアは「効率性のため」マイクロペイメント アーキテクチャについて空想することを好みますが、人々はそれを計算できません。彼らは、毎日経験しなければならない細かな決断の数を最小限に抑えるためだけに、毎月の定期購読を充実させたほうがよいでしょう。
WordPress が好きで、それを使用して静的サイトを作成したい場合は、それが可能です。
1 を取得します。PC上でWordPressのローカルインストールを実行します。1つのオプションについては、localwp。comを参照してください（所属なし）。
2 に準拠している。WordPress を使用して、必要なほぼすべての WordPress プラグインを使用して、必要な Web サイトを設計します。ただ、時間とともに変化する外部リソースを要求しないでください！
3 に準拠しています。WordPress サイトを静的サイトとしてエクスポートするための WordPress プラグインの 1 つ、つまり GitHub Pages、Netlify、Neocities などどこにでもアップロードできるファイルのフォルダーとして使用します。1 つのオプションについては、simplystatic。com（所属なし）を参照してください。
しばらくそうしていましたが、それらのプラグイン（または他の WGET ベースのソリューション）で迷惑なエッジ ケースに遭遇し続けました。
SSG が主にソフトウェア開発者にとって興味深い理由は、サイトのソフトウェア アーキテクチャが主にソフトウェア開発者にとって興味深いためです。他の人（著者と読者の両方）は、ページの作成方法を気にせず、ページがそこにあることだけを気にします。
> 他の人（著者と読者の両方）は、ページの作成方法を気にせず、ページがそこにあることだけを気にします。
読者の皆さん、確かに。著者？絶対に真実ではありません。著者の中には、よく知るほどテクノロジーに精通していない人もいるかもしれませんが、コンテンツをオンラインにするプロセスに大きな影響を受けています。それが、インターネット上でコンテンツを公開することに大きな業界がある理由のすべてです。
> SSG を見つけてください（またはすべてを自分で手作りしてください）
これは少し遅すぎたと思いますか？Astro はこれをうまく解決しますが、他の解決策もあります。Webflow のような SSG プラットフォームを構築するスタートアップから、基本的なマークダウンや html を必要とする astro のようなフレームワークまで。
そう、Astro が妥協のない完璧なソリューションであることがわかりました。JS を使用せずに 100% 静的サイトを作成でき、必要に応じてのみ JS を追加できます。
類似/古い SSG ドキュメントのように重く感じられず、再利用可能なコンポーネント用に TSX のような構文を書くことができます（これはとても気に入っています）。
さらに、技術者以外の人が参加するチーム ソリューションのアップグレードが必要な場合は、CMS を簡単に接続できます
誤解しているかもしれませんが、これは方向性が間違っているように感じます。「貪欲なピエロ」（ウェブ開発会社だと思いますか？)に雇われている私は、人々が時間を節約するためにお金を払っていることを常に観察しています。私たちの職業全体はこの前提に基づいて構築されています。面白いことをしている人がいる場合、その人が自分の HTML を書くか、他の人にお金を払って書くかは本当に重要ですか？
最新のソーシャル ネットワーク複合企業のおかげで、ウェブはますます一枚岩になってきています。それはテクノロジーの選択とは何の関係もありません。
> 「貪欲なピエロ」（ウェブ開発会社だと思いますか？)に雇われている人として
推測する必要がないようにリンクをクリックする（間違っている）かもしれません？
私は間違っている？リンクをクリックしました。この投稿の著者は、2 人の特定の貪欲なピエロについて明示的に言及しているのではなく、より一般的には WordPress エコシステムについて言及していると仮定しています。なぜなら、普通の人が特に Automattic や WP Engine に閉じ込められることを避けるのは実際には非常に簡単だからです。
編集: この投稿のドメインとユーザー名を接続したところです。それで、具体的に何を意味したのか本当に疑問に思っています。
bludit のような CMS は、よりシンプルな構造と小さな設置面積を求めるユーザーにとって良い選択肢です。ただし、テーマはまだ非常に限られています。
レンダリングされたコンテンツをキャッシュすると、特にプラットフォームであり、すべてのユーザーのインフラストラクチャ コストを償却できる場合、静的サイトの利点のほぼすべてが失われます。
あなたはすべての利点がなくなると言いますが、私は読みました、“追加の作業を行えば、静的サイトが無料で得られるものの一部を達成できます”。
静的サイトの主な利点は心配することが少ないことなので、これはちょっと面白いことです。
この記事は、静的サイトが一般の人にとってセットアップするには複雑すぎるため、実行するのが難しすぎるため、人々が無料でこれらの特典を利用できないことについて述べています。
編集: もう 1 つは、技術者以外のユーザーは WYSIWYG エディターを必要としているということです。彼らはマークダウンや html テキスト ファイルを編集したくありません。したがって、サポートするためのすべてのインフラストラクチャを整備すれば、顧客の Web ページを動的にすることもそれほど複雑ではなくなります。
> は、シングル ページ アプリケーションとしてロードされ、JSON 形式でコンテンツを要求することでナビゲーションを実行し、クライアント側で「再水和」される大きなフロントエンド コンポーネントです。
えッ？<confused-dog。jpg>ページがサーバー側で（おそらく）ハイドレーションされたクライアント側でレンダリングされるか、クライアント側（つまり、クラシック SPA）でレンダリングされますが、ハイドレーションはありません。
はい、静的なウェブサイトは素晴らしいです！GitHub で Jekyll を使用しています。100% 無料です。私も同意しますが、学習曲線があります。
私もこれを行ってきましたが、常に Ruby を学ぶつもりだったが、実際にそれに到達することはなかった Python の専門家として、Ruby 開発ツール スイート（Bundler や Gem システムなど）に頭を悩ませる必要があるのは嫌いです。ローカル ビルドを実行するためですが、現在、これを使用すると、一見不条理な量のディスク領域が占有されています のみ 理由はそれがインストールされているからです。慣れ親しんだ方法で Python を使用できるように、すぐに Nikola に切り替えることを検討しています。
> 奇妙かもしれませんが、なぜそれがそうなのかは大きな謎ではありません。すべての中間ステップを自分で理解するよりも、Wordpress ブログをスピンアップする方が簡単です:
これでは違いは説明できませんが、SSG だけで他の企業がこれらすべてのサービスを販売できる可能性があることを自分で理解する必要があるのはなぜでしょうか？
はい、間違いなく同意します。最近いくつかのサイトを立ち上げましたが、すぐにそれを見つけました I SSG でそれらを生成し、オンラインで平手打ちするだけで満足でした。他のユーザーと協力したいと思ったらすぐに、SSG はすぐに WordPress を支持する必要がありました。SSG が協力できないわけではありません、念のため言っておきますが、それは協力的であるということです 遠く プログラマーではない人に SSG に追加する方法を教えようとするよりも、WP サイトへのアクセス制限付きログインを与えて記事を投稿させる方が簡単です。
SSGを使用するために非プログラマ-y誰かに必要なものを考えてみましょう:
* リポジトリのコピーをダウンロードして SSG ツールをインストールし、リスニング モードで SSG を起動して変更を確認できるようにします。* 彼らのページの Markdown を書き出してください。ああ、段落の隣の画像、情報コールアウト、一般的なページ構造（カード、ヒーロー ブロック、ボタン）などのショート コードが用意されていることを願っています。そうでない場合は、実装するために一時停止して協力してもらうか、必要なテンプレートを作成する方法を見つける必要があります。いずれにせよ、ビットがサイトに実装されると、作成者はビットを含めるために必要な難解なショートコード形式のマークアップを実行する必要があります。* これで変更が完了しました。作業ディレクトリ全体をジッパーを閉じて整理するために送信する必要があるか、プルリクエストをコミットする方法を学ぶ必要があるかのいずれかで、変更をステージングする方法を見つける必要があります。Gitリポジトリへ。
I — をすべて実行しても構いません。理解するのは非常に楽しいです。そして、好きなように物事を組み立てる機会が得られます。しかし、Google ドキュメントに書くことに慣れている演劇監督に、そのすべての方法を教えようとしているのでしょうか？いいえ。すると、「ここで、これを G-Docs — に書きました。これをサイト ページに変える方法を見つけていただければ幸いです！」ということになります。
wordpress に比べて、ボンネットを持ち上げてより簡単にカスタマイズできる、より良い競合他社が存在することを本当に願っています。SSG には CMS フロントエンドがいくつかありますが、最後に確認したのは、「データベースに情報を入力するとレンダリングされる」という意味で「CMS」であるか、まだ特にユーザーフレンドリーではなかった（または放棄された）かのどちらかです。)。
最初のサイトに静的サイト ジェネレーターや PHP やそのような動的機能を使用させる人は決してお勧めしません。簡単な html ドキュメントを wysiwyg エディターで作成し、サーバーにアップロードするだけです。
> ...ウェブは、私たちとは異なる人々によって作られたものが多かったので、以前はより面白かったです
そして、それは美しく蒸留されて一文になります。
現象は認めましたが
「通常のユーザーは、お金を払わせる貪欲なピエロの集団に囚われています。」
ここでも、ビールのようにソフトウェアは無料である必要があり、ソフトウェアに料金を請求する人は悪魔です
「ソフトウェア エンジニアは、GitHub Pages / Cloudflare Pages で無料のホスティングとカスタム ドメインのサポートを享受できます。」
相棒に払った分はもらえるよ。
> の通常のユーザーは、あらゆる小さなことにお金を払わせる貪欲なピエロの集団に悩まされています
えッ？Automattic や WP-Engine に限定されるものではなく、Wordpress を備えた通常の Web ホスティング プロバイダーや、標準のホスティング パッケージに含まれるその他の多くのプロバイダーが多数あり、無料の Wordpress を使用でき、セルフホストすることもできます。それが Wordpress がオープンソースであることの要点であり、意図したとおりに機能しています。
ブログの現状にはまったく問題はありません。
静的サイト ジェネレーターは、Chrome の最新の devtool ベンチマーク ツールと呼ばれるものすべてのボックスをいじってチェックしたいテクノロジストによって使用されます。それも問題ありません。それがあなたの時間を好きなら、あなたにとっては良いことです！「普通の人」（または Web コンテンツを公開して先に進みたいだけの中小企業）にとっては、十分な選択肢があります。
> 静的サイト ジェネレーターは、Chrome の最新の devtool ベンチマーク ツールと呼ばれるものすべてのボックスをいじってチェックしたいテクノロジストによって使用されます
いいえ？Hugo をダウンロードし、ランダムなテーマを取得し、いくつかの記事を書くのは非常に簡単で、Wordpress で同じことをするのと同じくらいいじくり回す必要はありません（わかりました、一方のアクションは UI の大きなボタンであり、もう一方のアクションはコピー貼り付けコマンドですが、次の点で） 努力, 、ほとんど違いはありません。
私が Hugo を使用しているのは、それが軽く、ブログを無料で実行して無限大に拡張できるからです（HN のトップページの上位にあった記事が少なくとも 2 つあり、死の抱擁も請求書も関連していませんでした）)、メンテナンスはゼロですが、必要に応じて柔軟性も備えています。google のスコアもチェックしていませんし、気にしていません。
WordPress に関しては、あなたが説明したものはどれも無料で入手できず、継続的なメンテナンス（くだらないエコシステムに対応するためのアップデート）が必要です。
hugo の開始ワークフローを再検討する必要があると思います。テクノロジーに詳しくない人にとって、これはかなり恐ろしいことだと思います。プログラマーとしても、テーマを設定するための最初のブートストラップは不格好だと思っていました。誰かがすぐにコンテンツを爆発させる、すぐに使えるテンプレートが付属している必要があります。
ママに Wordpress ホストに接続する方法をガイドできます。ヒューゴにも同じことは言えませんでした。
> わかりました、一方のアクションは UI 内の大きなボタンであり、もう 1 つはコピー貼り付けコマンドです、
違いは、コンソールは平均的なユーザーにとって怖いですが、大きなボタンは怖くないということです。
> 静的サイト ジェネレーターは、Chrome の最新の devtool ベンチマーク ツールと呼ばれるものすべてのボックスをいじってチェックしたいテクノロジストによって使用されます
WordPress では、1 つまたは 2 つの機能を無効にし、キャッシュ拡張機能を設定することで、PageSpeed テストの結果が 100 に達するのは比較的簡単です。ログアウトしたユーザーにとって、HTML はキャッシュからほぼ直接提供されるため、SuperCache がセットアップされた WordPress はほぼ静的な Web サイトに似ています（時折のキャッシュ エビクションを除く）。
「セルフホスト」の方法を知っている人は、無料または非常に安価にそれを行うことができます。
それ以外の場合、WP Engine はサイトごとに $30 です。
OP氏は、このように知識の非対称性を悪用するのはダサいだけでなく、規範には効果的に貢献するためのツールがないため、Webが長期的にダサくなるとも述べている。
車について何も知らないのに、突然車が必要になった場合、どこかで聞いた最寄りの自動車ディーラーに行くか、すぐに特定のモデルを見つけて必要なものにできる特定のリソースに行きますか。より良い価格？
> そのため、私たちソフトウェア エンジニアは、GitHub Pages / Cloudflare Pages / などによる無料のホスティングとカスタム ドメインのサポートを楽しんでいます
ああ さあ！それが続くとはあまり期待していませんよね？
2004 年に、無料のサービスに依存するよりも料金を支払う方が良いことを学びました。私はソースコードリポジトリ、電子メール、webホスティングなどに支払います。
無料ホスティングを使用するときに起こり得る最悪の事態は何ですか？彼らがお金を請求し始めるとすぐに、あなたは別の場所に出発するだけです。そして、私はホスティング（およびその他のもの）の VPS の料金を支払っている人としてそう言います。
それはすべての無料のもののために本当です。サービスがまだ無料かどうかを常に監視するのは面倒であり、移行を続けるのも面倒です。
Web ホスティングは非常に安価です - 特に静的サイトの場合。支払うのははるかに簡単で、それを忘れます。私はプロバイダーを 20 年間使用してきました。
プロバイダーは、ユーザーがお金を請求し始めたら、結局のところ有料顧客に変換したいと伝えると確信しています。そして、静的サイトを数年ごとに移行しても、それほど気になりません。時間当たりの収入で時間を大切にするなら、おそらく価値はないでしょうが、楽しいなら大丈夫です。
> ソフトウェア エンジニアリングにおいて単純なことを簡単にできないときはいつでも
Mandatory Rich Hickey "Simple Made Easy" リンク => https://youtu。be/SxdOUGdseq4？si=IY8mWzR3C-ru5Das
「この基調講演は Strange Loop 2011 で行われ、おそらく Rich の多くの優れた講演の中で最もよく知られ、最も高く評価されており、ソフトウェア設計の問題点と複雑さとの絶え間ない闘いについての新しい考え方の先駆けとなっています。」
私も同意します。私は小さな Web コーナーのために純粋な html でオール・フロム・スクラッチの方法を誘惑しましたが、まあ、諦めます。基本的な html で最新の Web サイトを作成するには時間がかかりすぎます。RSS 専用コーナーを試してみましたが、明らかに表示されず、不必要に複雑であっても準備が整っているという理由だけで Hugo/org-mode になってしまいます。
ブログは一般的ではないでしょうか もっとシンプルに したがって、一般に、「ソーシャル ネットワーク アプリケーション」よりも「静的」サイトの候補として比較的優れているのでしょうか？
ハッカーニュースのページは「静的」です - 正しいですか？
私のスタートアップの Web サイトでは、「static」について聞く前に、ASP。NET でコードを書き、サイトを「static」にしました。つまり、「static」は私が書いたものに対して問題ありません。やっと（ふぅ！！) ライブにアクセスしてください。候補ユーザーがサイトが「静的」であり、そうではないことを気にしないか、気づかないことを願っています シングルページ. 。今日、ほぼすべてのユーザーは「静的」ではなく「単一ページ」サイトを期待していますか？
前回確認したとき、ページの送信量は 1 ページあたり ~44KB でしたが、それは比較的小さいと思いますか？
ユーザーとしてのみ、1 つのページ サイトが素晴らしく、微妙で、驚くべきものになる可能性があり、実際には直感的または明白ではありませんが、現在では、そのようなサイトが何百万もあり、その 2 つの間に大きな違いがあるため、ユーザーが必要になります 試してみて調べてください, 、 サイト 使い 方 学ぶ ため。対照的に、静的なサイトは の歴史に基づいているように見えます コンピュータインタラクション, 、例えば、標準的なコントロール - テキストボックス、チェックボックス、ラジオボタン、リンク - 航空業界と3270 端末のためのいくつかのIBMの仕事に戻って、今までに多分30 億人がすぐに理解すること、そしてそうであればそれは利点になることができます。
> ハッカー ニュースのページは「静的」です -- 正しいですか？
いいえ。それらは本質的に動的です。これらは、ユーザーが送信したコンテンツによってリアルタイムで生成されます。
記事の分類では、HN は複雑なサイトになります。ただし、ここでは分類は適用されません。
強く同意します。Wordpress は、インターネットのどの % にでも電力を供給していると自慢していますが、PHP ソース コードの一部を見たことがあるなら、そうです
こんなに複雑すぎるシステムがこれほど大きな市場シェアを持っているのは、私にとって気が遠くなるような気がします。
Gatsby TypeScript React コンポーネント / <<insert お気に入りの静的サイト ジェネレーターをいつでもここ>> に取り出します
技術的な純度はビジネスに勝ちません。ソリューション do。WP は、一般の人々が Web 上にコンテンツを掲載できる豊富なエコシステムを提供しました。たとえそれが技術的な負債でプログラマーを悩ませたとしても。
使用した CPU 時間の観点から % を計算していれば、その主張はさらに印象的なものになったかもしれません。
静的 Web サイトの定義に関する国勢調査はまだ行われていません。MYSQL データベースのない Web サイトは、JavaScript または php テンプレート インクルード ファイルがある場合、まだ静的ですか？各ページを手動で編集する必要がある純粋な静的な Web サイトは頭痛の種です。
静的 Web サイトが何を意味するかについては、間違いなくコンセンサスがあります。この用語の基本的な Web 検索を試してみましたか？
> 各ページを手動で編集する必要がある純粋な静的 Web サイトは頭痛の種です。
静的サイトジェネレータがあるのには理由があります。
> 静的 Web サイトの定義に関する国勢調査はまだありません。
サーバー側のスクリプト作成はありません。クライアントサイドスクリプティングを持つことはOKです（例:)。JS の。基本的に、ASP や有料 Web ホストを購入する余裕のないほとんどの人にとって、90 年代に物事がどのように戻ってきたのか。
ここでは、約4 つの段落のためにこの質問についてワッフルしている、あなたの読書の喜びのために以下にコピー: p :)（ソース:) https://www。evalapply。org/posts/shite-the-static-sites-from-... )
> 静的 Web サイトとは何ですか？
> Static は単に as-is を意味します。その逆は「動的」であり、移動中を意味します。「静的ウェブサイト」の「静的」部分は、保存された情報に対応します。「ウェブサイト」の部分は、情報がどこから、どのようにコンピューターに届くかに対応します。Web サイトは文字通り、World Wide Web 上の場所（サイト）であり、コンピュータは必要な情報を取得する必要があります。
> インターネット上で Web ページなどの情報を取得することは、定義上「動的」です。自分のコンピュータのディスクでファイルを開くだけでも「動的」です。デジタル ファイルを読み取る、および/または送信するという行為自体が、ある場所からそのビットをコピーし、別の場所に見せることを意味します 3。
> The Ultimate Static Site は、一度書かれたファイルは決して変更されません。したがって、一度受け取ったものは、（紛失しない限り）二度と取り出す必要はありません。もちろん現実はそれほど単純ではありません。しかし、私たちは「静的手段は決して変わらない」メンタルモデルを使って作業していきます。なぜなら、それだけでかなり遠くまで進むことができるからです。
「手編集された HTML ファイルの束」から「マークダウン導関数やプログラミング言語のオブジェクト リテラル構文などの非 HTML 構文から生成された HTML ファイルのセット」までの回答を含む、良い質問です。（静的サイト） 発電機)前者とはかなり異なること。
また、ブラウザに配信するためのラストマイル マークアップ言語として、作成者が利用できると想定されるすべての HTML を備えた SGML もあります。メニュー、ページ ナビゲーション用のドキュメント アウトラインの自動生成、HTML へのマークダウンの処理、RSS または SERP へのフィルタリングなど、さらには外部/シンジケート コンテンツの統合やスクリーニングなどの中程度に複雑な動的サイト機能も含まれます/スクリプト、壊れたコメント、外部/スパム リンクなどの悪意のある入力やその他の望ましくない入力についてユーザーのコメントを検証します。
IME、最も近い定義は、単にフラット ファイルのみを含むサイトです。サーバー側のスクリプトはありませんが、クライアント側の JavaScript は非常に許可されています。それは必ずしも各ページを「手動で編集」することを意味するわけではありませんが、LLM にアウトソーシングしない限り、おそらくある時点で一部の書き込みを行う必要があります...
ビジュアライゼーションにJSが必要な完全クライアントレンダリングのテンプレート/サイトについてはどうでしょうか？（つまり、優雅な劣化はまったくありません）。
技術的には静的ですが、私の意見では絶対に最悪の種類のものです。
静的 Web サイトは、必要なものをすべて 1 つの HTML ファイルとして提供します。ソースコードを保存してオフラインで開くことができ、違いはありません。
したがって、クライアントからのリクエストによってテンプレート化が行われる場合、テンプレート化は問題外です。
静的 Web サイトの管理方法は、ビルド スクリプトを使用します。カスタム ヘッダーのオプションを使用してコンテンツをマークダウンで書き込むと、純粋な HTML にすべてを埋め込んだ Python スクリプトが表示され、github ページでホストできるようになります。
IMO では、ページは静的な Web サイト上で静的にコンパイルできるため、ページごとに HTML を手動で編集する必要はありません。でも、そうですね、静的な度合いもあると思います。私の（ブランドの新しい）個人 Web サイトは、文字通り現在すべてゼロから作成されていますが、間もなく、おそらく Markdown ソースから事前に作成されるでしょう。私はそれを静的と呼びますが、程度は低いです。
確かに、静的 Web サイトとは、wget や curl などを使用してダウンロードでき、実際の Web サーバーを必要とせずにファイル システムから直接ファイルを閲覧することで機能するものですか？
静的 Web サイトは、コンテンツを生成するためにクライアントに対して余分な作業を行わない Web サイトであると言えます。SSR または単なるプレーン HTML ファイルのいずれかです
問題は、「コンテンツ」が何を意味するのかを定義することです。「JS なし」と言っているのですか — もしそうなら、そう言ってください！それ以外の場合、「コンテンツ」と「その他のもの」をどのように区別しますか？
これについて誰かが混乱しているという話を聞いたのはこれが初めてです。サーバーが動的に生成されたドキュメントを提供している場合、それは静的ではありません。静的 Web サイトは、サービス対象のファイルのディレクトリとして完全に表現できます python - m http。server。PHP テンプレートがないことは明らかです。
> 静的ウェブサイトは `cat index。html` で提供することができます
確かに、しかしそれは十分な定義ではありません。html の内容にいくつかの制約を追加する必要があります。それ以外の場合は、レンダリングするたびに新しいページの幻覚を見る巨大な JavaScript プログラムをそこに入れることができます。これは「静的」としてカウントされるべきではありません。
ただし、通常は静的としてカウントされます。この文脈では、static には技術的な意味があり、辞書の定義ではありません。サーバー側からは静的であるため、サービスを提供するために特別なロジックは必要ありません。
> これは「静的」としてカウントされるべきではありません。
なぜしない？そうでない場合、「javascript がまったくない」以外に、どこに線を引くのでしょうか？
そのために「スクリプトなし」という用語を予約したいと思います。) 「バックエンドなし」という用語を普及させれば、この 2 つは共存できると思います。私はサーバー側の処理がないフラットファイルの単なるコレクションであるサイトについて話したいです; 私のために、 "静的" は完全にその仕事をします。
素晴らしい記事。
> 弁護士や会計士がそれぞれのドメインがどのように機能するかを明確にできず、理論的には自分で操作できるはずのシステムの避けられない仲介者になってしまうのは腹立たしいと思いませんか？
> ソフトウェア エンジニアリング、特に Webdev で単純なことを簡単にできないときは、まったく同じように社会を失敗させています。
まさにその通りです。
この修正は、GitHub Actions と GitHub Pages です。そうすれば、自分でソフトウェアを実行する必要がまったくなくなります。ビルド プロセスは完全に GitHub 上で実行され、無料でもあります。
このような静的サイト ジェネレーターを使用して GitHub Actions を使用している例がこれ以上見つからないことに驚いています。理想的には、誰かが GitHub リポジトリ テンプレートを共有します。このテンプレートには、優れた静的サイト ジェネレーターが事前に設定されており、自分のサイトのワンクリック開始点として使用できます。
私は自分でそれらの1 つを構築することを検討しましたが、私は静的サイトジェネレータを使用しない傾向があります（代わりにBaked Dataが好きです:) https://simonwillison。net/2021/Jul/28/baked-data/)だから、私はそのプロジェクトを引き受けるには素晴らしい人間ではない。
The GitHub Pages スプラッシュページ（The GitHub Pages splash page）https://pages。github。com/) は、それだけの素敵な小さなインタラクティブなチュートリアルを持っています、そして私は様々なSSG/テーマのレポテンプレートをたくさん見てきましたが、私はまだ多くのユーザーが次のハードルにぶつかると思います:
ー GitHub が何であるか、またどのように機能するか（Git 自体はおろか）がわからない
- レポのクローンを作成する方法がわかりません
- レポ内のファイルを変更するために必要なプログラム、またはその使用方法がわかりません
ー コミットの作り方/プッシュ方法がわからない
- 変更が有効になる前に変更を確認するためにローカル プレビューを構築する方法がわかりません
私の個人 Web サイトの以前のバージョンは、完全に HTML と少数の CSS で足場が作られていました。私はブログ投稿の HTML へのマークダウン コンバーターとして pandoc を使用し、すべてを HTML ファイルのバンドルにパッケージ化するための短い bash スクリプトを作成しました。GitHub Actions と GH ページもあなたが説明したように使用され、最後に GitHub Actions のホストされているページにドメインを指定しました。完璧に機能しました
より翻訳
あなたの前には2 つの個人的なウェブサイトがあり、それぞれがブログとして使用され、所有者の基本的な連絡先情報を表示するために使用されます:1 つは PHP で書かれた複雑な CMS で、Web サーバー、複数のワーカー、Redis キャッシュ、SQL データベースが必要です。このサイトには、シングル ページ アプリケーションとしてロードされ、JSON フォームでコンテンツを要求することでナビゲーションを実行し、クライアント側で「再水和」される大きなフロントエンド コンポーネントもあります。
もう 1 つは、静的 HTML ファイルと 1 つまたは 2 つの CSS ファイルのコレクションです。どこにもjavascriptはありません。
これ以上よくわからない場合は、ほぼすべての通常のユーザーが [2] を持ち、プロのエンジニアが [1] のようなものを持っていると予想されますが、実際にはその逆です。個人の Web サイトとして 2 番目のオプションがあり、ほとんどすべての通常のユーザーは複雑すぎるソリューションに悩まされています。
奇妙なことかもしれませんが、それはなぜそれが大きな謎ではありません: それはあなた自身ですべての中間ステップを理解するよりもWordpressブログをスピンアップする方が簡単です:ドメインを購入する
ホスティングプラットフォームを見つける
Dns を設定
SSGを見つける（または自分ですべてをハンドクラフトする）
デプロイ パイプラインのセットアップ方法について説明します
そのため、私たちソフトウェア エンジニアは GitHub Pages / Cloudflare Pages / などによる無料のホスティングとカスタム ドメインのサポートを楽しんでいますが、通常のユーザーは多数のユーザーに悩まされています 貪欲なピエロ そのため、99% のケースで静的な Web サイトであるはずの Web サイトをレンダリングするために不敬虔な量の計算能力を無駄にしながら、あらゆる小さなことの費用を支払わなければなりません。
先週、私はボストンの SquiggleConf で、HTML 用の言語サーバーを作成した経験について話しました。トークのほとんどは、導入時に何をすべきか（または避けるべきか）に関する戦術的なアドバイスですが、よりハイレベルな論点でトークを締めくくりました。これについては、このブログ投稿の結論としてここで完全に報告します。
SuperHTMLを公開したとき、私はそれがそうであることを発見しました 史上初の HTML 用言語サーバー 診断をユーザーに報告しました。それについてブログ記事を書きました hacker Newsの一面にて そして誰も私を訂正しなかったので、それが真実であることがわかります。
もともと面白いと思いましたが、もっと考えてみると、こんなことになるのは少し悲しいです。リンターは存在しており、人々はエディターで診断を取得できますが、通常、それはバニラ HTML ではなく特定のフロントエンド フレームワークに結び付けられたツールであるため、人々は、実際にはすべての複雑さを本当に必要としていなくても、フレームワークを使用することを選択することになります。それらのフレームワークがもたらすもの。
そしてそれは私の意見では悪いことです。シンプルさに対する抽象的な認識のためではなく、そのためです web はソフトウェア エンジニアだけのものではありません. 。Web を複雑にすればするほど、通常のユーザーを呼び出したいエンクロージャに押し込みます ソーシャルネットワーク.
弁護士や会計士がそれぞれのドメインがどのように機能するかを明確にできず、理論的には自分で操作できるはずのシステムの避けられない仲介者になってしまうのは腹立たしいと思いませんか？
ソフトウェア エンジニアリング、特に Webdev で単純なことを簡単にできないときはいつでも、まったく同じように社会を失敗させます。
これはスタートアップや大手テクノロジーが私たちにとって解決できることではありません。彼らの経済的インセンティブがあまりにもずれているため、部分的には私たちの技術に誇りを持っているという問題として、また部分的には、ウェブをよりアクセスしやすくするために皆さんにご協力ください。かつては、私たちとは異なる人々によってウェブが作られていたため、ウェブはより面白くなっていました。
私たちは今、アッシュビルでこの大事な時期に対処しています。細胞サービスがまったく戻ってきたとき、誰もがクソ断続的な 3G を持っており、基本的な生存情報に必要な Web サイトはどれもロードされませんでした。多くの善良な人々がいくつかのテキストのみのニュース サイトを作成しました。今日、バンコム郡の Web サイトにはついに低帯域幅のサイトがあることに気づきましたが、それでも調べてみると、130 k のブートストラップ css と 50 k の jQuery ブロッキング レンダリングがありました。人々がこの仕事をしているのは素晴らしいことですが、市民は 1 週間半前にこれを必要としていました。今では、水、食べ物、非飲料水などをどこで入手できるかを考え出しました。これらすべてを通じてテクノロジーがひどく失敗するのを見ることは、私にとって憂鬱な意味で目を見張るものでした。
それほど壊滅的ではありませんが、近所の停電時には、通常、セル信号が貧弱になります（ケーブル インターネット ボックスにバックアップがありません）。電力会社の停電マップはログイン (！) の後ろに隠されています そして、ファンシーなクラスタリングや、まともな接続であってもすでに遅いその他の UI 機能を使用してレンダリングされます。そのため、ステータスを確認したり、障害を報告したりするにはかなりの時間がかかります。
I could call the utlity company, but for some reason, they chose voice navigation (instead of keypad tones) for their menu, and it is not good at recognizing distorted voice (over bad 4G or 2G connection).
うわー、他のすべての Web サイトよりも著しく速いのは驚くべきことです。私たちは本当にインターネットをめちゃくちゃにしました。
そんな状況だったので、アマチュア無線の免許をまた取得しようかと考えました。アシュビルだけでなく、はるかに広い地域を含むノースカロライナ州西部に起こったような災害では、私はインターネットに基づいたものには何も依存したくありません。波長が長く、出力が低いものが欲しいです。しかし、それは非常にアクセスしにくいので、それが正当な理由があるかどうかはわかりません。
Connectivity was knocked out from Black Mountain all the way to the Tennessee and Georgia borders. I'd be surprised if many people even have shitty 3G back yet. What I know is remaining in touch with people who live there has been hard.
無免許で聴くことができます。$15 ハンドヘルドですべてを聞くことができ、非常に役に立ちました。
In an emergency you are allowed to transmit without a license. There were plenty of unlicensed calls going to the Mt. Mitchell repeater.
All that being said, I am definitely getting my license once this is over.
私が望んでいるのは、すべてのスマートフォンに FM ラジオが組み込まれていることです。FMラジオのICチップはありますし、Android携帯にもあるようです。緊急時にスマートフォンにスマートフォンの搭載を義務付けるのは当然のことのようだ。一体何が起こっているのかラジオで聞くためだけに、最初は車を走らせて貴重なガスを燃やさなければなりませんでした。
選択バイアスかもしれませんが、私の印象では、この機能のない携帯電話を見つけるのは非常に難しいということでした（Windows Phone やセミスマート フィーチャー フォン時代にも遡ります）。通常の欠点は、ケーブルがアンテナとして使用されるため、有線ヘッドフォンが接続されていない限り、ヘッドフォンが生き返らないことです。
あっ うん。アンテナなしでどうやって動くのか不思議でした。FM アンテナは、携帯電話に組み込まれている 5G アンテナよりも大きくする必要があると思います。
CBはおよそ11mの波長で、トン単位の電力を必要とせず、ライセンスも必要ありません。
2016年、私は地元企業向けのパンフレットウェアを製造する代理店で働いていました。私たちのクライアントの 1 人が、自分たちが構築した Web サイトに予約システム用の小さな iframe を追加することを望んでいたのを覚えています。彼らは私たちに一言の文書を送ってくれました。彼らはそれをHTMLとしてエクスポートしていただけであることが判明しました（Wordは現在でもサポートしているようです！) そして、それを安価な共有 Web ホスティング プロバイダーに投げ込みます。彼らにとってそれはとてもうまくいきました。印刷メニューを作成する単語 doc からエクスポートされるため、オンライン メニューを常に更新しておくことができます。当時、私たちは社内で彼らをからかっていました...今考えると残念です。レストランで他にやるべきことが 100 万あるとき、それは実際には天才的なアイデアです。
静的なサイトを作るのはまだ簡単です。HTML を生成するためのオーサリング ツールは現在最悪だと思います。そうでない場合は、サイトにサービスを提供するためにサーバー上で実行する必要があるプロセスがあると思います。
私は企業がこのようなことをするのが大好きです。うまくいけば、うまくいく。
私の仕事は、彼らがもっと良くなるかもしれないから彼らを嘲笑することではなく、彼らの解決策をより良くし、彼らがすでに行っていたことですでに成功したことを妨げることなく、彼らに対する私の解決策が、より良いとは言わないまでも、彼らの解決策と同じように機能するようにすることです。
多くの開発者は、私の経験を認めたくありません。少なくとも、これらのアドホック Web ソリューションの多くは、経験豊富な Web 開発者が独自に実装する大量の戦略よりも実際にうまく機能します。
重要なのは、ビジネスが何を提供し、顧客とどのように関係し、対話するかということです。場合によっては、単語ドキュメントが HTML にエクスポートされるだけで済むこともあります。私たちはスキルを使ってそれを向上させることができますが、本当の魔法はビジネスを運営する人間にあります。大好きだ。
私が楽しいと思うのは、これらのソリューションを改善する方法を見つけるのは、実際には本当に難しいことです。確かに、より良い Web サイトを作成したり、洗練されたインフラストラクチャなどで展開したりすることはできますが、結局のところ、顧客はそれを好むのでしょうか？それは彼らのビジネスを改善しますか？時々、その部分はまったく些細なことではありません。
完全に！印刷メニューの単語ドキュメントを Web サイトとして使用する魔法は、サイトを更新し続けるためのほとんど機能しません。トロント郊外のファミリー レストランに視覚的に素晴らしいウェブサイトがあるとは誰も気にしません。メニュー、営業時間、住所、電話番号を確認したいだけです。それは常に更新され、実際に支払う印刷メニューとまったく同じ内容であり、物事を言葉で読みやすくする方法をすでに知っていました。
この特定のレストラン（悲しいことに今は閉店）は 60-70 歳の男性によって経営されていたため、実際には私たちが提供することになったどのソリューションよりもさらに魅力的です。その男性は、切り取ったポートレート写真がロゴであり、index。html のヘッダーにある `float:left` でした。Word からエクスポートされました。そんな真贋は買えないと思いますよ。
もちろん、私は 19 歳で愚かだったので、これは面白いと思いました。最初のテクノロジー関連の仕事では、私は CodeIgniter ベースのお問い合わせフォームと静的な About Us ページを作成する非常にプロフェッショナルだと考えていました。
振り返ってみると、私たちはそれらを汚してやったと確信しています。私たちがそれらを販売したソリューションが何であれ（IIRC では、カスタム テーマの wordpress サイトが提供されました）、おそらくあまり役に立たなかったでしょう。どれが最悪ですか。
私は地元の政党と協力して、主にウェブ上でテクノロジーに関する意思決定を支援してきました。そして、この経験とこれまでの経験に基づいて、代理店は顧客を頻繁に汚しているという結論に達しました。意図的に境界線に見える場合もあれば、クライアントのニーズ、代理店の機能、コミュニケーション、そして最終的に提供されるものとの間の断絶であると思われる場合もあります。
非常に多くの人がそれを頼りにしているので、それを言うのは奇妙に思えますが、wordpressは非常に多くの点でやりすぎです。非常に多くのクライアントを際限なくイライラさせ、継続的なメンテナンスを必要とし、場合によっては非常に費用がかかります。また、サーバーのレンダリングやフォームの送信などを処理するアクティブなサーバーも必要です。大多数のクライアントはそれを必要としません。テーマさえ必要ないのです。
私が支援しているこのパーティーには、7 つのワードプレス サイトが点在しており、それらはすべてコストがかかりすぎるホスト上にあり、中にはまったく更新も保守もされていないホストもあり、使用率が約 40% でピークに達するサーバー上にあり、それ以外の場合はほぼ 40% でハミングしています。wordpress が必要とする以上のゼロ使用率。
これはインターネットの多くです。これらの人々との経験は、彼らのニーズを満たす何かを構築するきっかけになりましたが、それはこれらのものの 1 つです... わからない、もし私がそれを建てたら、誰かが来るとは思えない。でも ええ。インターネットに対するほとんどの人のニーズは非常に単純です。Wix やそれに類するものでさえ、あまりにも多すぎます。しかし、これらの基本的なブログ エンジンもまったく的外れです。これらのビジネス ユーザーのほとんどはブログに興味がありません。彼らはただ、さまざまな種類の情報を捨てて、それを永遠にぶらぶらさせることができるシンプルな本拠地を望んでいます。
これを修正することを目的とした製品がいくつか考えられますが、それらは私たちが説明しているタイプの人々にとって十分に単純ではありません。オンラインで何かが必要であることはわかっていても、それについてあまり知りたくないし、あまり学びたくない人々。
私はいくつかのレストランでコンサルティングを行っており、フルスタックの Web アプリケーションを構築した経験があるにもかかわらず、ほとんどの成果物について Excel にリーチしていることに気づきました。これらは、「非技術的な」レストラン経営者が快適に過ごすために必要な「アプリケーション」です。データを貼り付けて必要な出力を取得するシートを作成するには、最小限の継続的なメンテナンスとトレーニングが必要でした。Dropbox / Google ドライブでファイルをドラッグすると、うまくいきます。
私は今でも、構成やデータの正規化などから派生データから生の入力を分離することをできる限り「エンジニアリング」しようとしています。Excel の Lambda 関数を使用すると、FRP エディター/ランタイム環境で Lisp を作成しているふりをするだけです。PowerQuery を備えた ETL ツールは、これらのレストランの営業規模に非常に適しています。
Excel が何年も前に実現した機能をうまく再現できないという任務を負っているとき、フルタイムの仕事で頭がおかしくなるのは難しいです。
人々は物事を行うのにどれくらいの時間がかかるかを追跡することを忘れています。
「時間推定に長けている人」と「時間推定が常に間違っていると思っている人」に分岐しているのを見ます。前者は軌道に乗り、継続的に改善され、良好になりました。後者には手がかりがありません。
Web サイトを最初からセットアップするのは難しくありませんが、特にメンテナンスを行う場合は時間がかかります。
ビンゴ。これが、google シートが最高の cm である理由です。データをリッピングして Web サーバーにアップロードするデータ パイプラインがあるだけです
この夏、CDMX で私が行ったレストランがあり、そのメニューは Figma のドキュメントへのパブリック プレビュー リンクでした。私はその事実を見て笑いが止まらなかったが、それがうまく機能したことに喜んだ。こんなの好き。
私は、この [Vueテンプレート]（から作る小さな単一のHTMLファイルサイトのトンを持っています）https://vue-template。spaghet。me/) を。また、パブリック Notion ドキュメントとして公開されたばかりのサイトや、iCloud からのインライン写真ライブラリなどもあります。物を接続するだけで簡単かつ利用可能であること、そして、物をリンクするだけで済むのに、物事を過度に複雑にして最初から何かを構築したいと思うことがどれほど多いかは驚くべきことです。
余談ですが、私は [mmm。page] (https://mmm。page/)他のことをする時間がない場合は、小さなマイクロサイトや使い捨てサイトをすばやくつなぎ合わせます。これらすべてのツールを探索する楽しみ
私はフロントページの死を長い間呪ってきました。そうですね、私たちがそれをからかったのは、それが作成した HTML がひどい/ひどいからです。しかし、それはまた、通常の企業/人々が、適切なパスワードを選択する以外にセキュリティを心配することなく、小規模で安価な Web サイトを更新するために使用できるプログラムでもありました。
私はここ数年、words HTML エクスポーターよりも多くのオプションを提供する、より正しい HTML を作成できる優れた代替手段を探してきました。
つまり、ウェブのアイデア全体ではありません ブラウザ ウェブという理想に反するものでしょうか？それは暗黙のうちに人々をスピーカーとリスナーに分けます。
並行世界では、web ブラウザはウェビターと呼ばれ、Web サイトを編集したり表示したりできます。人々は変化を提案することができます。人々は注釈を公開することができます。Web ホスティングは、電子メールで好きなサービスを選択（または構築）し、好きなクライアントを選択（または構築）するようなものです。プロトコルが解決します。
ボンネットの下には、そのシステムの骨がそこにあります！`PATCH` はHTTP動詞には理由があります。
ただし、Web をこれほど公に編集可能な大量のドキュメントにすると、多くのスパムが発生することになります。Web サイトにフォームがある場合は、すでに多くのフィルタリングを行う必要があります。構造化データをフィルタリングする代わりに、差分をフィルタリングする必要がある場合を想像してください。
おそらく良い半分の対策は、Web オーサリング ツールを Web ブラウザに戻すことだと思います！私の記憶が正しければ、Netscape Navigator にはそれがありました。ただし、これにより HTML ファイルをディスクに書き込むことができるだけです。
HTTP Basic Auth および POST/PUT/PATCH/DELETE HTML を使用してページに直接ログインする標準プロトコルのボーナス ポイント。それを理解できる特別なサーバーが必要ですが、理想的には誰でも実装できるサーバーです。あなたはブラウザを指示します https://yoursite。com/my/page。html マート、HTTP基本 Auth 出ナーク、マート、HTTPベーシック Auth 出ナーク、マート、HTTPベーシック Auth 出ナーク、マート、HTTPベーシック Auth 出ナート、マート、HTTPベーシック Auth 出ナート、マート、HTTPベーシック Auth 出ナート、マート、HTTPベーシック Auth 出ナート、マート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック Auth 出ナート、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベーシック、HTTPベー
編集: プロトコルは間違った言葉です。誰かがこれを実際に何と呼んでいるのか訂正してくれました。HTTPベース...編集？標準のAPI？それは今私が作りたいものなので、それを理解する必要があります。
編集 2: ウィキについて言及した兄弟コメントの CamperBob2。私がウィキについて説明していることに気づきました（笑）
あなたが探している用語は存在します: ユーザーエージェント。
https://en。wikipedia。org/wiki/User_agent
あなたが説明したものは、Facebook のようなサイロの均質化効果の下に組み込まれて行ったり来たりしました。マッシュアップは大きな新しいものでした。それを元に戻そうとするさまざまな試みが行われてきましたが、サイロの慣性により、興味のある人を見つけるのは困難です。
それは真実ではないと思います。Figma はブラウザで実行され、HN も実行されます。
ブラウザの仕事は _render_ です。コンテンツを作成しているのか、単に読んでいるだけなのかはわかりません。
昔、mozilla（mozilla org が firefox を作成する前のブラウザ）は wysiwyg 方式で html を編集していました。私の初期のウェブサイトはすべてこれで作られていました。<br> を削除する方法を考えたことはありません
それは Wiki の背後にあるアイデアのようなものですよね？
そこ た ユーザーが既存の Web ページをマークアップ、編集、注釈を付けることができるブラウザ拡張機能を、ユーザーのコミュニティに表示される方法で提供するという何年も前の取り組み。残念ながら、おそらく穴が開いていたため、どこにも行きませんでした ウェイ 神聖な牛が多すぎる。（そして/またはスパマーによって採用され、ソーシャル ネットワーキング/評判管理プロジェクトに変わったでしょう。)
そうですね、それは 30 年前には良いアイデアでした。今では、Web は約 14 分でスパムと AI 生成のドライブでいっぱいになるでしょう。
現在では、コンテンツを適切にキュレーションすることがこれまで以上に重要になっています。
Web 開発者の個人 Web サイトには、履歴書駆動開発（RDD）という複雑な要因があります。
RDD のために個人的なサイド プロジェクトを使用しようとする専門家向け。そうすることで、雇用主が行うプロジェクトほど多くのプロジェクトを妨害する必要がなくなります。
たとえば、今朝につながります... インディーズ Web サイトの場合、私はこれから立ち上げようとしています - そして、主に RDD の理由から、人気のある最新の Web フレームワークを使用しています - - Web サイトを更新できなくなりました。
NPM パッケージには重大なセキュリティ上の問題があり、アップデートを取得しようとして NPM が相互依存関係の競合に悩まされ、自動的に解決できなかったためです。（皮肉なことに、これにより、セキュリティ アップデートを本番サイトにプッシュすることができなくなりました。)
このサイトには、インラインで JS が散りばめられた 5 つの単純な手書き HTML ファイルと、2 つの小さな Perl CGI スクリプトが含まれる可能性があります。そしてそれは25年間、そして今後も完璧に機能するでしょう。
代わりに、サイトの NodeJS 部分だけを対象とした 129 NPM パッケージと、頻繁にセキュリティ更新プログラム、および暗号ソース ファイル（テンプレート フラグメント、TS 構成、ハンドラー）の大きなツリーが必要になります。
しかし、ばかばかしいほど複雑な方法でそれを行うことは、専門家には余裕がありません ない する こと。（たとえば、履歴書に Perl を付けることは、雇用適性のための死の接吻になります）。年齢差別を理由にあなたの履歴書を捨てなかった人たちは、それでもあなたが RDD をやらなかったのは馬鹿に違いないと思うでしょう。
> web はソフトウェア エンジニアだけのものではありません。Web を複雑にすればするほど、通常のユーザーをソーシャル ネットワークと呼びたいエンクロージャに押し込みます。
この著者を大きくしてください。これは最近の会議に関する最近のポッドキャストです この引用は（Squiggle Conf）から来ました、 https://changelog。com/jsparty/339
彼らの「単純な」流れの最後の数点でさえ、過度に複雑です。すべての CMS の前に、テキスト エディターや Front-page などの WYSIWYG エディターを使用して、デスクトップ上のファイルに HTML と CSS を作成しました。専用の Web サーバーと同じように、ローカル ファイルから簡単にレンダリングできます。満足したら、SFTP 経由でファイルをサーバーにコピーします。Frontpage がそれを処理してくれるでしょう。現在でも同じ流れでうまくいっています。
ドットコムブームの頃、ウェブサイトを作成するための高品質のデスクトップエディターが数十台ありました。これらすべてのホスト型 SaaS システムは、プログラマー以外の人が Web サイトを作成しやすくすることを目的として、普及し始めたばかりでした。でも本当にそうだったのか？そうは思えない。現在、これらのシステムは非常に複雑であるため、使用するには誰かを雇う必要があります。しかし、プログラミングの背景すらなかったコンピューター科学の 1 年生は、依然として HTML と CSS を手書きで書いています。WordPress 用のテンプレートはこれらの複雑なプログラムですが、HTML と CSS 用のテンプレートは Hello World の例と同じくらい簡単です。
WordPress のキラーアプリはコメントです。SSG は、ほぼ定義上、コメントを許可しません。WordPress ブログには、ほとんどの場合、コメントが組み込まれています。
Hugoのようなものが本当にブログの球で離陸したい場合は、あなたがする必要があるのは、いくつかの良い見栄えのテーマを作成することだけです コメントあり。おそらく、1 ドル 1 ペニーでサードパーティとしてホストできるブログごとのシャード SQLite を使用して、それを大規模に把握してください。手には小さな金色のガチョウがいます。
ブログの時代にはそうだったと思いますが、今ではそうではありません。
投稿に対するコメントやディスカッションは、reddit、hn、さらには Facebook などのサードパーティ コミュニティで見つけることができます。たとえば、サブスタックの投稿の下にあるコメントのリストをスキャンした人のうち何人が、同じ投稿の HN コメントの 1 ～ 2 ページをスクロールしますか？
IMO では、HN に関するディスカッションは、特定の投稿に対するコメント チェーンよりもテクノロジー関連の投稿の方が質が高いという当然の結論です。HN はすでに全ブログの 99。9% よりも幅広い読者を魅了しているからです。
ブログ投稿に直接コメントする主な利点は、投稿が HN の一面にある一時的な状態と比較して、作成者がブログ投稿を見る可能性がはるかに高いことです。
ソーシャルメディアサイトに参加する人が増えれば増えるほど、会話は悪化します。
テクノロジー関係者がレディットから逃亡する中、これはすでにHNにも起こっている。
特定の投稿に対する新しいコメントのほとんどは、リンクされたコンテンツを読まず、2 番目の段落で取り上げられた内容について苦情を言った人たちです。
これは進化のプロセスであり、最も多くのエンゲージメントを獲得するのは、最初に反応または反応するコメント投稿者です。先行者アドバンテージは、そのポストが受けるエンゲージメントによってさらに高くなるにつれて確立されます。
回答する前に深く考える人は、よく考えられたコメントが第一印象の海の下に埋もれてしまうと落胆します。
すべての人にとってトップコメントやトップページを共有するプラットフォームではエンゲージメントが非常に不平等であるため、この報酬サイクルはより多くの人によって増幅されます。最初のいくつかのコメントに進むか、何も得られません。
Discord や Facebook などのサイトは、ユーザーをより小さなグループに分割することで、衝動的な少数の人々によるエンゲージメントの独占に対抗しようとしています。社会的交流をめぐる競争が減少すると、勝利戦略の多様性が高まります。進化のプレッシャーは依然として存在しますが、プラットフォーム上の他の人々と対話するためだけに「勝利戦略」を完成させる必要はありません。
コントラスト Reddit または YouTube ビデオ。注意の集中は、SEO、製品レビュー、または広告により金銭的価値があることを意味します。大規模な視聴者の価値により、プラットフォームの競争力が高まります。競争力とは、多くの YouTuber や Redditor が注目を集める行動を専門化することを意味します。これには品質が犠牲になります。
おろしポスト！「WordPress ブログ」に関する私の Web サイトをチェックしてください https://www。sevarg。net/ 気に入ると思う！; の
Are you 確かに コメントはまだ望ましいですか？インターネットのステップ1 はもう「コメントを読まない」ではありませんか？
そうは言っても、私は実際に、ホスト型サービスを利用する意欲があれば、多くの人にとって簡単に実行できる、ブログ上の「動的なコメントを含む静的サイト」のソリューションを考案しました。Discourse（PHPBB の後に多くの場所が移行した最新のフォーラム ソフトウェア）には、コメント用のページと統合する方法があるため、私は少なくとも 3 年間、特に問題なくそれを使用してきました。私は自分の Discourse install をホストしていますが（変です。データセンターにサーバーがまだラックアップされています）、他の人に料金を払ってそれを行ってコメントを提供できない理由はありません。
興味深いことに、discourse のコメントで得たスパムの量は、Blogger でホストしていたときに得たスパムの量のほんの一部です。それは私にとってもう大きな問題ではなく、PHPBB フォーラムや Blogger では常に迷惑でした。
サイトの残りの部分は、私が購入したテンプレートをベースにした Jekyll だけです（まともな外観の Web サイトを作ることができないため）。その後、私が望むことを実行させるために、長年にわたって何度もハッキングしてきましたが（応答性の高い画像、主に - 私は依然として低帯域幅接続の人々に敏感です）、メンテナンスの点ではまったく悪くありません。レンダージョブを起動するだけで、いくつかのスクリプトが新しいファイルをアップロードします。
>コメントはまだ望ましいと思いますか？インターネットのステップ1 はもう「コメントを読まない」ではありませんか？
それは誰に尋ねるかによって大きく異なります。読者として、私は いつも 記事のコメントを確認してください。私にとって、これはインターネットの楽しみの 75% にすぎません。クソ番組ならなおさらです。誰もが同じように感じているわけではないことは理解できます。私は何年もの間、さまざまな人々から Twitter がゴミ捨て場であることを聞いてきましたが、私にとって Twitter は、人々がお互いに反応できる他の場所よりも劣ったり、優れているわけではありません。
もちろん、この質問をコメント スレッドの 3 レベルの深さで行うと、このような答えが得られます。生存者バイアス。
Wordpress のキラー アプリはコメントではなく、プラグインのエコシステムです。Hugo で週末に設定するのに費やすすべてのプラグインが Wordpress にあり、お母さんが 2 回クリックするだけで有効にできます。
私自身 Hugo を使用していますが、エンジニアリングの観点からフットプリントが不要であっても、Wordpress ではユーザー エクスペリエンスがはるかに優れています。
もう 1 つの「対話型」部分: お問い合わせフォーム。
すべてのビジネス サイトがコメントを求めているわけではありませんが、おそらくお問い合わせフォームが欲しいでしょう。電子メール アドレスを入力する方が代替手段ですが、入力パイプラインの処理の方が適しています。
静的サイトでは、送信を処理し、サイトに正しく接続するために信頼できるサービスを見つける必要があります。それは別の可動部分となり、場合によっては別々に支払う必要がある別の請求書、業界が統合されるときに対処する必要がある別のビットなどになります。
そうは思えない。コメントは以前は大変なことでしたが、最近ではスパムやモデレーションに関する多くの問題に対処するためにサインアップしています。
正直に言うと、私が最も望んでいないのは、私の個人サイトを汚すために土地に自由にアクセスできるようにすることです。もしかしたら、どこかの人に価値をもたらすのかもしれませんが、ついにその人の電源を切ったことで、私の精神的健康は良くなりました。
私は静的になることを検討していますが、これが文字通り私が抱えている問題です。静的サイトにコメントをボルトで固定する、すぐに使える方法（例: Javascript の何か）はありますか？
おそらくdisqusでしょうか？サイト所有者にとっては不透明だと思います。ユーザーは Disqus に認証するため、db は必要ありません。
私は私の手でコード化されたサイトで SuperHTML を試しましたが、報告された問題は 1 つだけであり、その問題は私の知る限り間違っています。`</html>` タグが HTML 5 ドキュメント上で `<！で開かれることはないことがわかります！DOCTYPE html>` opening tag。著者は、これは完璧ではないと言っており、念のため私の理解を再確認する必要があるでしょう。いずれにせよ、それは役に立つことのようで、それが欠けているとは思わなかったことにも驚いています。
私のような人で、この用語を知らない人のために説明すると、「HTML 用言語サーバー」とは、HTML 構文を評価するプラグインを指します。これはツールの狭い説明かもしれませんが、それが私が試してみた基本的なアイデアです。
Web サイト所有者の観点から UX を考えると、これは実際には矛盾ではありません。Wordpress を使用すると、たとえオーバーヘッドがはるかに大きかったとしても、物事を簡単に行うことができます。
トレードオフが物事の構成に時間を費やすことだと考えている場合、それは単なる矛盾です。いいえ、ほとんどの人にとっての選択肢は、誰かにお金を払ってウェブサイトを立ち上げてもらうことです。
誰かが Hugo 用に WYSIWYG エディターをセットアップし、数回のクリックでドメイン登録から公開サイトに移行すると、大儲けするでしょう。
>>> 誰かが Hugo 用に WYSIWYG エディタをセットアップし、数回のクリックでドメイン登録から公開サイトに移行すると、大儲けするでしょう。
これはNetlify、Squarespace、Github Pagesのような企業がやっていることではないでしょうか？netlify を使用すると、パークされたドメインを転送し、テンプレートを選択すると、構成の大部分が実行され、数分で起動して実行され、ドメインが通過するまでに約 24 時間かかることがわかります。
しかし、あなたの言っていることはわかります。たとえあなたが話していることに近い企業であっても、マイナーな仲介業者のステップに対処することは、それを理解できる人にとって恩恵となるでしょう。
「基本的な Web サイト」が何をすべきかについてのほとんどの人の期待は、時間の経過とともに大きく高まりました。
プログラマーである私も、静的サイト ジェネレーターのトラップに何度か陥ったことがあります。
静的サイト ジェネレーターを使用してサイド プロジェクトを開始すると、小さな機能を追加したいことに気づき、突然、単純な Rails または PHP アプリで開始したいと思うのは迷惑です。
最近では、静的サイトが必要な場合は、html ファイルのフォルダーから始めるだけです。バイクのシェディングやツールの先延ばしをせずに、アイデア -> の実行から実行するのがはるかに複雑ではなく、より迅速になります。
html と css を手動で書くのはとても嬉しいですが、—I は誰にでもお勧めしません。
もう 1 つの素晴らしい点は、レールに「中止」することにした場合です.。 html ファイルのフォルダーを rails パブリック/フォルダーにコピーできます。かなり簡単なアップグレード パスです。
> プログラマーとしても、私は静的サイト ジェネレーターのトラップに何度か陥りました。
> 静的サイト ジェネレーターを使用してサイド プロジェクトを開始すると、小さな機能を追加したいことに気づき、突然、単純な Rails または PHP アプリで始めたらよかったと思うのは迷惑です。
例がなければ議論するのは難しいです。私は 10 年以上前に Pelican を使い始めましたが、今でも満足しています。時々、動作をカスタマイズするためにコードを書きますが、それは数年に一度です。シンプルで、そして ただ働く.
ダイナミック サイトで見逃している点はありますが、HTML ファイルの単純なフォルダーが Pelican よりもいかに優れているかはわかりません...
私は 20+ 年間、自分の個人 Web サイトに投稿してきましたが、それは次のようなものでした。basic HTML -> Drupal（whew）-> Wordpress -> basic HTML（jekyll 経由）。
私の Web サイトの機能肥大化に対して私が設定した基本的なルールは、私がウェブサイトに何を求めるか、つまり私が行ったことのアーカイブを定義することです。アーカイブとして、時間内に非常に耐久性のあるものにしたいと考えています。したがって、コピーしたり、ミラーリングしたり、あらゆるホスティング プラットフォームで動作させたりするのが非常に簡単な静的ファイルです。
バイリンガルサイトを持つことを釘付けにするのに時間がかかりましたが、:)しかし、少なくともそれは私が一度支払った代償です。
ブログでは Hugo を使用します。スタイルではなくコンテンツに集中する方が簡単だからです。だからこそ、私は純粋な html ファイルを書くのが好きではありません。何かが html ファイルにハードコードされている場合、スタイルの変更も問題になる可能性があります。
より高度なタスクの場合は、機能を追加するのが非常に簡単なので、django で書きます。
もしかしたら、ニーズに合った静的サイト ジェネレーターが見つからないだけかもしれません？
Jekyll は Ruby 分野で最もよく知られていますが、特定のニッチ分野に合わせて調整されており、Markdown または別の軽量マークアップ言語でブログを作成しています。確かに他のことを行うようにマッサージすることはできますが、汎用の静的サイト ジェネレーターとしてはそれほど人間工学に基づいたものではありません。
レールにコピー/貼り付けが簡単なものが必要な場合は、erb/haml と ActiveSupport で最初から書き始めることができるため、middleman のようなラックベースの静的サイト ジェネレーターが最適です。
HTML と CSS の手書きのシンプルさを求めているが、インクルード、部分テンプレート、リンク ヘルパーなどの優れた機能が必要な場合、nanoc は進歩的な優れた静的サイト ジェネレーターです。プレーン HTML/CSS から始めて、必要に応じて追加機能のみを追加します。
プレーンな html ページを持つページ間の共通性をどのように扱っていますか？iframe を使用しない限り、すべてのページ（ヘッダー、フッター、ナビゲーション）で共有されているもの、またはほぼ同じものをすべて手動で同期する必要があります。かなり迷惑だ。
確かに、親は実際にはすべてに対してプレーンな html ファイルを意味していたわけではありませんが、もし意味を持っていたとしても、おそらくサーバー側のインクルードを使用しているでしょう。
私は組織のためにブログを運営しています。平均して 1 営業日あたり 1 件の投稿を行っており、通常は約 3 件の投稿があります。私は何年も前に Django/Wagtail/Puput と一緒にこの曲をセットアップしましたが、それ以来、それは幸せに動き続けています。人々が投稿ごとに独自の新しいファイルを作成し、独自の HTML を作成しているとしたら、管理するのがどれほど迷惑になるか想像できません...
ただし、その Python/Django スタックとサーバーを維持する必要がありました.。 だろ？！私は何百もの Django リリースのアップグレードを行ってきました。自動的でも時間フリーでもありません。
ほとんどの SSG、特にブログ向けの SSG は、Markdown などのより優れたマークアップ システムを受け入れます。マルチユーザー システムであっても、物事を追跡するのは難しくありません。
技術者以外の人々に git ワークフローに慣れてもらうのは最も難しい部分です。
> 最近では、静的サイトが必要な場合は、html ファイルのフォルダーから始めるだけです。
ここも同じ。コンテンツに。md —>。html ステップを追加することを検討しましたが、まだ必要な — が見つかりませんでした。
> もう一つ素晴らしいことは...
私は、ローカル サーバー経由で自分のサイトを —easily—view できるのが好きです。最良のケースは、file:// でも表示できるケースですが、組織を完全に把握することができず、ファイルベースの表示用に別のコピーを生成する「make local」ステップになってしまいました。
今、私はあなたがサーバー側のコードを必要とするあなたのウェブサイトにどのような機能を追加することになるのか疑問に思っています。コメントシステム？
理想的な世界ではそうです。しかし、過去の経験から、多くのユーザーは mailto リンクの関連付けが誤って設定されています。
ひどいユーザー体験です。
はい、対象者によります。この記事の内容が個人的な Web サイトの場合、ほとんどのハッカー ニュース ユーザーにとっては問題ないでしょう。誰かが私にメールを送ることができなければ、おそらく私のウェブサイトはまったく表示されないでしょう。ただし、祖父母の個人 Web サイトを作成する場合は、バックエンドを備えた適切なフォームの方が適しています。
このコメントの下には、「ああ、適切な SSG が見つかっていないだけだ。これは良いことだ」というコメントがいくつかあるのが面白いです。善意ではありますが、完全に的外れです。
私はそのパラドックスに当てはまりました - 私はフレームワークやデータベースなしで最新の PHP で自分の個人 Web サイトを書き直しました。ほとんどが静的サイトですが、PHP を使用してヘッダーを追加したり、リスト（ブログ投稿用）に対処したりします。そうでない方が少し便利だと感じました 完全に 静的。記事を書いて、コミットして、プッシュするだけで、オンラインになります。ほとんどの静的サイト ジェネレーターは複雑すぎることがわかりました。
単一のページのコードは次のようになります: <?php $this->title = "Blog Article Title"; $this->shortTitle = "Title"; $this->date = mktime(0,0,0,1,27,2024); if ($this->mode == PageMode::Meta) return; ?> <p>Raw HTML content here<p>
サイトヘッダーとフッターを自動的に追加するルーターがあり、フォルダーに「_layout。php」ファイルを追加して、子ページの別のレベルのレイアウトを追加できます。ブログ リスト ページでは、フォルダー内のすべての個々の記事ファイルをスキャンしてインデックスを作成するだけです。それ どこ その $this->mode == PageMode::Meta 入ってきます - 各ファイルのコードを実行し（メタ データを取得するため）、残りをレンダリングする前に終了します。多くのコンテンツに拡大するつもりはありませんが、問題になった場合は調整します。
私の「フレームワーク」の PHP コード全体は、わずか 4 つの PHP ファイル（init。php、functions。php、Layout。php、および Page。php）です。
開発者であることの利点は、構成やデータの代わりにコードを使用できることです。また、コードを使用してコンテンツをより効率的に書き込むことができます。
結果は（まだかなり不完全ですが）次のとおりです: https://www。codaris。com/
私はちょうど私のウェブサイトの1 つ、ヘッダーのための90% htmlしかしphpのために同じことをし、少数の奇数の全体的なビットのためのinclude()を始めた。
初期の Web ブラウザは、Web サイトを表示するだけでなく編集するように設計されていると思いました。
そのアイデアはもうなくなってしまったと思います...
> これ以上よく知らない場合は、ほぼすべての通常のユーザーが [2] を持ち、プロのエンジニアが [1] のようなものを持っていると予想されますが、実際にはその逆です。個人の Web サイトとして 2 番目のオプションを使用しており、ほとんどすべての通常のユーザーは複雑すぎるソリューションに悩まされています。
私は混乱しています。その逆は、プロのエンジニアが [2] を持ち、通常のユーザーが [1] を持っているということです。しかしその後、プロのエンジニアはほとんど誰も [2] を「余裕」がないと彼らは書いているので、誰もが [1] を持っているようです...？
読み続けると、次の文にその理由が示されます:
> 奇妙かもしれませんが、その理由は大きな謎ではありません。Wordpress ブログをスピンアップする方が、すべての中間ステップを自分で理解するよりも簡単です。
これは、プロのソフトウェア エンジニアである少数の人だけが 2 番目のオプションを利用できることを意味していたと思います。
将来的には、変更の公開の容易さが、比較において考慮されるべき差別化要因となります
It is indeed written as you say; I suspect - but cannot confirm - that author meaning: それは確かにあなたが言うように書かれている; 私は疑うが、確認できない - 作者が意味していた:
> ... プロのソフトウェア エンジニアである少数の人だけが「余裕」を持っています ...
それは逆になります。
ただし、読書の期待を覆すものであっても、書かれているとおりに読む場合は、多数（ほとんど？)の場合があります プロのソフトウェア エンジニアは COTS システムを使用して公開していますが、独自のサイトをゼロから生成している人はほんのわずかです。
私はそれを次のように読みました:「私の個人的なxのためにそのような複雑なスタックを実行することの複雑さのオーバーヘッドを買う余裕はありません」
> SuperHTML を公開したとき、それがユーザーに診断を報告する史上初の HTML 用言語サーバーであることを発見しました。私はそれについてブログ投稿を書き、ハッカーニュースの一面に掲載されましたが、誰も私を訂正しなかったので、それが真実であることはご存知でしょう。
おそらく、これは Microsoft が LSP を思いつく前に、ほとんどの IDE が何年も行ってきたことだからです。
最も人気のあるエディターの中で、バニラ HTML の診断を提供する方法を持っていたエディターは誰もいなかったと思います。私が知っている唯一の例外は Webstorm です。
Vim、Neovim、Helix、Zed、VSCode はすべて、診断サポートのない同じ基本実装を共有していました。
Helix では、次のリリースから、SuperHTML がデフォルトで有効になります: https://github。com/helix-editor/helix/pull/11609
私はエディタではなく IDE を書きました。ASP。NET と Java EE/Spring の開発を行った数年間は、2001 年以来修正するのに十分な HTML 診断があったと確信しています。
矛盾はまったくありません。シンプルさは美しいですが、複雑さは売れます。著者は、価値は実現された効用から得られると考えています。しかし、ほとんどの市場セグメントでは、価値は認識から来ていました。複雑さ（役に立たないものでも）を使用すると、知覚される価値を高めることができます。すべての偉大さがボンネットの下にあるとき、あなたはどのように人々を感動させますか？
私はいくつかの SSG を使用しており、自分で 1 つ書きました。支払い意思のある人にはまだ SSG を推奨できません。
> 著者は、価値は実現された効用から得られると考えています。
世界の大多数にとって、Wordpress は確かに SSG よりも多くのユーティリティを提供します。Wordpress は 5 分間のインストールで有名で、その後すべてがインストールされます ただ働く.
_realized_ ユーティリティ。
また、記事はフルマネージドWordpress vs セルフホスト（またはPaaSホスト）SSGについてです。セルフホストWordpress vs セルフホストSSGのどちらかを選択する場合、結果は大きく異なることに私は賭けます。
さて、あなたはなぜOPがアップル対アップルの比較をしなかったのか疑問に思うかもしれません、フルマネージドWordpress対フルマネージドSSGのように まあ、フルマネージドSSGは存在しません、それは売れないからです！
インターネット接続についても同様です（使用量が減り、消費者がより多くの料金を支払う）。技術者は、たとえば 200mbps を超える量は必要ないか、飽和することはないことを知っています。一方、消費者は「200/500/1G」オファーを見て、その中間のオファーを選択します。
これが私を静的サイトから遠ざけた理由です。すべてのことを行うのはあなた自身でなければならないので、実際にはそれ以上の作業です。
確かに、ビルドをホスティングして生成するためのオプションはいくつかありますが、試してみたところ、それほど良くなかったか、いくつかの問題などがありました.。 一方、wordpress。com は失望することはなく、iOS と Android 用のアプリがあり、インターネットがあればいつでも更新できます。もちろん、インターネットがあれば可能です。
だからこそ、今ではObsidian Publishを使っています。もちろん、黒曜石の金庫室からサイトを構築するために Quartz やその他の代替手段を使用することもできますが、箱から出して電話で使えるものはありません
完璧なソフトウェアなどというものは存在しない。すべてにトレードオフが伴います。もちろん、mkdocs を除きます。
私はジキルやヒューゴなど他の人を知っていますが、mkdocs のシンプルさに匹敵するものを見たことがありません。サイト全体を探して構築されており、見栄えの良いナビがあり、すべてがマークダウンされています。
一番いいところは？これが私の「ビルドパイプライン」です。
$ mkdocs ビルド
$ scp -r./build <user>@dangerlibrary。com:/site
大好きだ。
これはエンジニアの単純さに対する見方です。
普通の人間は、コメントを有効にするチェックボックスのようなものを驚くほどシンプルなものとして見るでしょう。
> 奇妙かもしれませんが、その理由は大きな謎ではありません。Wordpress ブログをスピンアップする方が、すべての中間ステップを自分で理解するよりも簡単です
あるいは、選択したオフィス スイートである publii を使用したり、bad html と css を手入力して、非常に安価なホスティング プロバイダーに生のファイルを渡し、ぎこちない、時には醜い「Web サイト」を楽しむこともできます。
このユースケースの業界は、外観と発見可能性に取り組んでいます。WP の大きく肥大化したくだらない部分と静的なピエロ ジェネレーターの二分法は、Google でも機能する美しい Web サイトを持っていることに立っています。他の代替手段（ビルダーやディレクトリなど）も同様に機能しますが、サイトのプロパティもクライアントから剥奪されます。それは、これらのソリューションが安価で、ファストファッションであるという理由だけです。
良い出発点だ。strattic、キャッシュ プラグイン、および sqlite でのクエリのオフロードの後、ゲームのかなり遅い段階で、コンタクト フォームなどの避けられないインタラクション パーツがいつ、どのように実行されるのかを見てみましょう。
> 弁護士や会計士がそれぞれのドメインがどのように機能するかを明確にできず、理論的には自分で操作できるはずのシステムの避けられない仲介者になってしまうのは腹立たしいと思いませんか？ソフトウェア エンジニアリング、特に Webdev で単純なことを簡単にできないときはいつでも、まったく同じように社会を失敗させます。
私はこれのためのより良い言葉は「率直」だと思います; 神話の男月を参照してください:
> ただし、特定のレベルの機能については、最もシンプルかつわかりやすく指定できるシステムが最適です。シンプルさだけでは十分ではありません。Mooers の TRAC 言語と Algol 68 は、異なる基本概念の数によって測定されるシンプルさを実現します。ただし、それらは簡単ではありません。やりたいことを表現するには、多くの場合、基本的な設備を複雑かつ予期せぬ組み合わせで組み合わせる必要があります。組み合わせの要素とルールを学ぶだけでは十分ではありません。また、慣用的な使用法、つまり実際に要素がどのように組み合わされるかについての伝承全体も学ばなければなりません。
> シンプルさと単純さは概念的な完全性から生まれます。すべての部分は同じ哲学と願望の同じバランスを反映する必要があります。すべての部分は、構文では同じテクニックを使用し、セマンティクスでは同様の概念を使用する必要があります。したがって、使いやすさによって、デザインの統一性、概念的な完全性が決まります。
静的サイトは、お問い合わせフォームを用意するか、基本的なコメントを追加する必要があるまでは最適です。はい、外部サービスを使用して静的サイトにそのような機能を追加する javascript を展開できますが、基本的な WordPress サイトを使用すると、すべてがすぐに実行できます。
連絡先フォームは、電子メール アドレスのひどい代替手段です。多くのサイトがコメントを完全に削除しました。はい、これらのものはあれば良いかもしれませんが、静的サイトがあるかスクリプト化されたサイトがあるかを決定する要素であってはなりません。
丁重に反対しなきゃ。ビジネス/ポートフォリオなどの Web サイトを運営している場合、お問い合わせフォームを使用してあなたに連絡する可能性が高い人の数は、単に電子メールを送信するように指示するよりもはるかに多くなります。クエリを分類してさまざまなユーザーに伝える必要がある場合、またはより具体的な情報が必要な場合にも、連絡フォームは適切に拡張されます。
連絡先フォームをページに埋め込むことを妨げるものは何もありません。
Netlify イベントにはアクションを記録するワークフローが組み込まれているため、インフラストラクチャをセットアップする必要はありません。
十分に公平です。おそらくさまざまなユースケースについて話しているのではないかと思います。クエリを分類してさまざまなユーザーにチャネリングしている段階にある場合、あなたのサイトはすでにバックエンドを正当化するのに十分な「ヘビー級」になっている可能性があります。
> 多くのサイトがコメントを完全に削除しました
そして、多くの人がまだ持っています。ほとんどのwordpress。comとブロガーのブログにコメントがあると思います
まさにこのコメントを書くためにここに来ました。この記事は、WP が無駄であると仮定するのが間違っています。これにより、ユーザーには大きなオプションが与えられます。エンジニアはおそらく、静的なページを操作し、インタラクティブ性が必要になったら Web ページのアーキテクチャ全体を変更する余裕がありますが、エンジニア以外の人は、連絡先から始めるスケーラブルなソリューションを採用したいと考えています。各フェーズ移行時にセットアップを再発明することなく、情報を収集し、ゆっくりと個人ショップなどにたどり着きます。
オプション性と機会費用について言えば、多くのエンジニアはテクノロジーにおける目に見えない機会費用を理解するように訓練されていますが(「yagni」や「テクノロジー負債」という言葉がよく使われます）、経済的機会費用、つまり時間と時間を無駄にする経済的機会費用を理解できていないことがよくあります。機械ではなく人間の認知努力。例: 多くのエンジニアは「効率性のため」マイクロペイメント アーキテクチャについて空想することを好みますが、人々はそれを計算できません。彼らは、毎日経験しなければならない細かな決断の数を最小限に抑えるためだけに、毎月の定期購読を充実させたほうがよいでしょう。
WordPress が好きで、それを使用して静的サイトを作成したい場合は、それが可能です。
1 を取得します。PC上でWordPressのローカルインストールを実行します。1つのオプションについては、localwp。comを参照してください（所属なし）。
2 に準拠している。WordPress を使用して、必要なほぼすべての WordPress プラグインを使用して、必要な Web サイトを設計します。ただ、時間とともに変化する外部リソースを要求しないでください！
3 に準拠しています。WordPress サイトを静的サイトとしてエクスポートするための WordPress プラグインの 1 つ、つまり GitHub Pages、Netlify、Neocities などどこにでもアップロードできるファイルのフォルダーとして使用します。1 つのオプションについては、simplystatic。com（所属なし）を参照してください。
しばらくそうしていましたが、それらのプラグイン（または他の WGET ベースのソリューション）で迷惑なエッジ ケースに遭遇し続けました。
SSG が主にソフトウェア開発者にとって興味深い理由は、サイトのソフトウェア アーキテクチャが主にソフトウェア開発者にとって興味深いためです。他の人（著者と読者の両方）は、ページの作成方法を気にせず、ページがそこにあることだけを気にします。
> 他の人（著者と読者の両方）は、ページの作成方法を気にせず、ページがそこにあることだけを気にします。
読者の皆さん、確かに。著者？絶対に真実ではありません。著者の中には、よく知るほどテクノロジーに精通していない人もいるかもしれませんが、コンテンツをオンラインにするプロセスに大きな影響を受けています。それが、インターネット上でコンテンツを公開することに大きな業界がある理由のすべてです。
> SSG を見つけてください（またはすべてを自分で手作りしてください）
これは少し遅すぎたと思いますか？Astro はこれをうまく解決しますが、他の解決策もあります。Webflow のような SSG プラットフォームを構築するスタートアップから、基本的なマークダウンや html を必要とする astro のようなフレームワークまで。
そう、Astro が妥協のない完璧なソリューションであることがわかりました。JS を使用せずに 100% 静的サイトを作成でき、必要に応じてのみ JS を追加できます。
類似/古い SSG ドキュメントのように重く感じられず、再利用可能なコンポーネント用に TSX のような構文を書くことができます（これはとても気に入っています）。
さらに、技術者以外の人が参加するチーム ソリューションのアップグレードが必要な場合は、CMS を簡単に接続できます
誤解しているかもしれませんが、これは方向性が間違っているように感じます。「貪欲なピエロ」（ウェブ開発会社だと思いますか？)に雇われている私は、人々が時間を節約するためにお金を払っていることを常に観察しています。私たちの職業全体はこの前提に基づいて構築されています。面白いことをしている人がいる場合、その人が自分の HTML を書くか、他の人にお金を払って書くかは本当に重要ですか？
最新のソーシャル ネットワーク複合企業のおかげで、ウェブはますます一枚岩になってきています。それはテクノロジーの選択とは何の関係もありません。
> 「貪欲なピエロ」（ウェブ開発会社だと思いますか？)に雇われている人として
推測する必要がないようにリンクをクリックする（間違っている）かもしれません？
私は間違っている？リンクをクリックしました。この投稿の著者は、2 人の特定の貪欲なピエロについて明示的に言及しているのではなく、より一般的には WordPress エコシステムについて言及していると仮定しています。なぜなら、普通の人が特に Automattic や WP Engine に閉じ込められることを避けるのは実際には非常に簡単だからです。
編集: この投稿のドメインとユーザー名を接続したところです。それで、具体的に何を意味したのか本当に疑問に思っています。
bludit のような CMS は、よりシンプルな構造と小さな設置面積を求めるユーザーにとって良い選択肢です。ただし、テーマはまだ非常に限られています。
レンダリングされたコンテンツをキャッシュすると、特にプラットフォームであり、すべてのユーザーのインフラストラクチャ コストを償却できる場合、静的サイトの利点のほぼすべてが失われます。
あなたはすべての利点がなくなると言いますが、私は読みました、“追加の作業を行えば、静的サイトが無料で得られるものの一部を達成できます”。
静的サイトの主な利点は心配することが少ないことなので、これはちょっと面白いことです。
この記事は、静的サイトが一般の人にとってセットアップするには複雑すぎるため、実行するのが難しすぎるため、人々が無料でこれらの特典を利用できないことについて述べています。
編集: もう 1 つは、技術者以外のユーザーは WYSIWYG エディターを必要としているということです。彼らはマークダウンや html テキスト ファイルを編集したくありません。したがって、サポートするためのすべてのインフラストラクチャを整備すれば、顧客の Web ページを動的にすることもそれほど複雑ではなくなります。
> は、シングル ページ アプリケーションとしてロードされ、JSON 形式でコンテンツを要求することでナビゲーションを実行し、クライアント側で「再水和」される大きなフロントエンド コンポーネントです。
えッ？<confused-dog。jpg>ページがサーバー側で（おそらく）ハイドレーションされたクライアント側でレンダリングされるか、クライアント側（つまり、クラシック SPA）でレンダリングされますが、ハイドレーションはありません。
はい、静的なウェブサイトは素晴らしいです！GitHub で Jekyll を使用しています。100% 無料です。私も同意しますが、学習曲線があります。
私もこれを行ってきましたが、常に Ruby を学ぶつもりだったが、実際にそれに到達することはなかった Python の専門家として、Ruby 開発ツール スイート（Bundler や Gem システムなど）に頭を悩ませる必要があるのは嫌いです。ローカル ビルドを実行するためですが、現在、これを使用すると、一見不条理な量のディスク領域が占有されています のみ 理由はそれがインストールされているからです。慣れ親しんだ方法で Python を使用できるように、すぐに Nikola に切り替えることを検討しています。
> 奇妙かもしれませんが、なぜそれがそうなのかは大きな謎ではありません。すべての中間ステップを自分で理解するよりも、Wordpress ブログをスピンアップする方が簡単です:
これでは違いは説明できませんが、SSG だけで他の企業がこれらすべてのサービスを販売できる可能性があることを自分で理解する必要があるのはなぜでしょうか？
はい、間違いなく同意します。最近いくつかのサイトを立ち上げましたが、すぐにそれを見つけました I SSG でそれらを生成し、オンラインで平手打ちするだけで満足でした。他のユーザーと協力したいと思ったらすぐに、SSG はすぐに WordPress を支持する必要がありました。SSG が協力できないわけではありません、念のため言っておきますが、それは協力的であるということです 遠く プログラマーではない人に SSG に追加する方法を教えようとするよりも、WP サイトへのアクセス制限付きログインを与えて記事を投稿させる方が簡単です。
SSGを使用するために非プログラマ-y誰かに必要なものを考えてみましょう:
* リポジトリのコピーをダウンロードして SSG ツールをインストールし、リスニング モードで SSG を起動して変更を確認できるようにします。* 彼らのページの Markdown を書き出してください。ああ、段落の隣の画像、情報コールアウト、一般的なページ構造（カード、ヒーロー ブロック、ボタン）などのショート コードが用意されていることを願っています。そうでない場合は、実装するために一時停止して協力してもらうか、必要なテンプレートを作成する方法を見つける必要があります。いずれにせよ、ビットがサイトに実装されると、作成者はビットを含めるために必要な難解なショートコード形式のマークアップを実行する必要があります。* これで変更が完了しました。作業ディレクトリ全体をジッパーを閉じて整理するために送信する必要があるか、プルリクエストをコミットする方法を学ぶ必要があるかのいずれかで、変更をステージングする方法を見つける必要があります。Gitリポジトリへ。
I — をすべて実行しても構いません。理解するのは非常に楽しいです。そして、好きなように物事を組み立てる機会が得られます。しかし、Google ドキュメントに書くことに慣れている演劇監督に、そのすべての方法を教えようとしているのでしょうか？いいえ。すると、「ここで、これを G-Docs — に書きました。これをサイト ページに変える方法を見つけていただければ幸いです！」ということになります。
wordpress に比べて、ボンネットを持ち上げてより簡単にカスタマイズできる、より良い競合他社が存在することを本当に願っています。SSG には CMS フロントエンドがいくつかありますが、最後に確認したのは、「データベースに情報を入力するとレンダリングされる」という意味で「CMS」であるか、まだ特にユーザーフレンドリーではなかった（または放棄された）かのどちらかです。)。
最初のサイトに静的サイト ジェネレーターや PHP やそのような動的機能を使用させる人は決してお勧めしません。簡単な html ドキュメントを wysiwyg エディターで作成し、サーバーにアップロードするだけです。
> ...ウェブは、私たちとは異なる人々によって作られたものが多かったので、以前はより面白かったです
そして、それは美しく蒸留されて一文になります。
現象は認めましたが
「通常のユーザーは、お金を払わせる貪欲なピエロの集団に囚われています。」
ここでも、ビールのようにソフトウェアは無料である必要があり、ソフトウェアに料金を請求する人は悪魔です
「ソフトウェア エンジニアは、GitHub Pages / Cloudflare Pages で無料のホスティングとカスタム ドメインのサポートを享受できます。」
相棒に払った分はもらえるよ。
> の通常のユーザーは、あらゆる小さなことにお金を払わせる貪欲なピエロの集団に悩まされています
えッ？Automattic や WP-Engine に限定されるものではなく、Wordpress を備えた通常の Web ホスティング プロバイダーや、標準のホスティング パッケージに含まれるその他の多くのプロバイダーが多数あり、無料の Wordpress を使用でき、セルフホストすることもできます。それが Wordpress がオープンソースであることの要点であり、意図したとおりに機能しています。
ブログの現状にはまったく問題はありません。
静的サイト ジェネレーターは、Chrome の最新の devtool ベンチマーク ツールと呼ばれるものすべてのボックスをいじってチェックしたいテクノロジストによって使用されます。それも問題ありません。それがあなたの時間を好きなら、あなたにとっては良いことです！「普通の人」（または Web コンテンツを公開して先に進みたいだけの中小企業）にとっては、十分な選択肢があります。
> 静的サイト ジェネレーターは、Chrome の最新の devtool ベンチマーク ツールと呼ばれるものすべてのボックスをいじってチェックしたいテクノロジストによって使用されます
いいえ？Hugo をダウンロードし、ランダムなテーマを取得し、いくつかの記事を書くのは非常に簡単で、Wordpress で同じことをするのと同じくらいいじくり回す必要はありません（わかりました、一方のアクションは UI の大きなボタンであり、もう一方のアクションはコピー貼り付けコマンドですが、次の点で） 努力, 、ほとんど違いはありません。
私が Hugo を使用しているのは、それが軽く、ブログを無料で実行して無限大に拡張できるからです（HN のトップページの上位にあった記事が少なくとも 2 つあり、死の抱擁も請求書も関連していませんでした）)、メンテナンスはゼロですが、必要に応じて柔軟性も備えています。google のスコアもチェックしていませんし、気にしていません。
WordPress に関しては、あなたが説明したものはどれも無料で入手できず、継続的なメンテナンス（くだらないエコシステムに対応するためのアップデート）が必要です。
hugo の開始ワークフローを再検討する必要があると思います。テクノロジーに詳しくない人にとって、これはかなり恐ろしいことだと思います。プログラマーとしても、テーマを設定するための最初のブートストラップは不格好だと思っていました。誰かがすぐにコンテンツを爆発させる、すぐに使えるテンプレートが付属している必要があります。
ママに Wordpress ホストに接続する方法をガイドできます。ヒューゴにも同じことは言えませんでした。
> わかりました、一方のアクションは UI 内の大きなボタンであり、もう 1 つはコピー貼り付けコマンドです、
違いは、コンソールは平均的なユーザーにとって怖いですが、大きなボタンは怖くないということです。
> 静的サイト ジェネレーターは、Chrome の最新の devtool ベンチマーク ツールと呼ばれるものすべてのボックスをいじってチェックしたいテクノロジストによって使用されます
WordPress では、1 つまたは 2 つの機能を無効にし、キャッシュ拡張機能を設定することで、PageSpeed テストの結果が 100 に達するのは比較的簡単です。ログアウトしたユーザーにとって、HTML はキャッシュからほぼ直接提供されるため、SuperCache がセットアップされた WordPress はほぼ静的な Web サイトに似ています（時折のキャッシュ エビクションを除く）。
「セルフホスト」の方法を知っている人は、無料または非常に安価にそれを行うことができます。
それ以外の場合、WP Engine はサイトごとに $30 です。
OP氏は、このように知識の非対称性を悪用するのはダサいだけでなく、規範には効果的に貢献するためのツールがないため、Webが長期的にダサくなるとも述べている。
車について何も知らないのに、突然車が必要になった場合、どこかで聞いた最寄りの自動車ディーラーに行くか、すぐに特定のモデルを見つけて必要なものにできる特定のリソースに行きますか。より良い価格？
> そのため、私たちソフトウェア エンジニアは、GitHub Pages / Cloudflare Pages / などによる無料のホスティングとカスタム ドメインのサポートを楽しんでいます
ああ さあ！それが続くとはあまり期待していませんよね？
2004 年に、無料のサービスに依存するよりも料金を支払う方が良いことを学びました。私はソースコードリポジトリ、電子メール、webホスティングなどに支払います。
無料ホスティングを使用するときに起こり得る最悪の事態は何ですか？彼らがお金を請求し始めるとすぐに、あなたは別の場所に出発するだけです。そして、私はホスティング（およびその他のもの）の VPS の料金を支払っている人としてそう言います。
それはすべての無料のもののために本当です。サービスがまだ無料かどうかを常に監視するのは面倒であり、移行を続けるのも面倒です。
Web ホスティングは非常に安価です - 特に静的サイトの場合。支払うのははるかに簡単で、それを忘れます。私はプロバイダーを 20 年間使用してきました。
プロバイダーは、ユーザーがお金を請求し始めたら、結局のところ有料顧客に変換したいと伝えると確信しています。そして、静的サイトを数年ごとに移行しても、それほど気になりません。時間当たりの収入で時間を大切にするなら、おそらく価値はないでしょうが、楽しいなら大丈夫です。
> ソフトウェア エンジニアリングにおいて単純なことを簡単にできないときはいつでも
Mandatory Rich Hickey "Simple Made Easy" リンク => https://youtu。be/SxdOUGdseq4？si=IY8mWzR3C-ru5Das
「この基調講演は Strange Loop 2011 で行われ、おそらく Rich の多くの優れた講演の中で最もよく知られ、最も高く評価されており、ソフトウェア設計の問題点と複雑さとの絶え間ない闘いについての新しい考え方の先駆けとなっています。」
私も同意します。私は小さな Web コーナーのために純粋な html でオール・フロム・スクラッチの方法を誘惑しましたが、まあ、諦めます。基本的な html で最新の Web サイトを作成するには時間がかかりすぎます。RSS 専用コーナーを試してみましたが、明らかに表示されず、不必要に複雑であっても準備が整っているという理由だけで Hugo/org-mode になってしまいます。
ブログは一般的ではないでしょうか もっとシンプルに したがって、一般に、「ソーシャル ネットワーク アプリケーション」よりも「静的」サイトの候補として比較的優れているのでしょうか？
ハッカーニュースのページは「静的」です - 正しいですか？
私のスタートアップの Web サイトでは、「static」について聞く前に、ASP。NET でコードを書き、サイトを「static」にしました。つまり、「static」は私が書いたものに対して問題ありません。やっと（ふぅ！！) ライブにアクセスしてください。候補ユーザーがサイトが「静的」であり、そうではないことを気にしないか、気づかないことを願っています シングルページ. 。今日、ほぼすべてのユーザーは「静的」ではなく「単一ページ」サイトを期待していますか？
前回確認したとき、ページの送信量は 1 ページあたり ~44KB でしたが、それは比較的小さいと思いますか？
ユーザーとしてのみ、1 つのページ サイトが素晴らしく、微妙で、驚くべきものになる可能性があり、実際には直感的または明白ではありませんが、現在では、そのようなサイトが何百万もあり、その 2 つの間に大きな違いがあるため、ユーザーが必要になります 試してみて調べてください, 、 サイト 使い 方 学ぶ ため。対照的に、静的なサイトは の歴史に基づいているように見えます コンピュータインタラクション, 、例えば、標準的なコントロール - テキストボックス、チェックボックス、ラジオボタン、リンク - 航空業界と3270 端末のためのいくつかのIBMの仕事に戻って、今までに多分30 億人がすぐに理解すること、そしてそうであればそれは利点になることができます。
> ハッカー ニュースのページは「静的」です -- 正しいですか？
いいえ。それらは本質的に動的です。これらは、ユーザーが送信したコンテンツによってリアルタイムで生成されます。
記事の分類では、HN は複雑なサイトになります。ただし、ここでは分類は適用されません。
強く同意します。Wordpress は、インターネットのどの % にでも電力を供給していると自慢していますが、PHP ソース コードの一部を見たことがあるなら、そうです
こんなに複雑すぎるシステムがこれほど大きな市場シェアを持っているのは、私にとって気が遠くなるような気がします。
Gatsby TypeScript React コンポーネント / <<insert お気に入りの静的サイト ジェネレーターをいつでもここ>> に取り出します
技術的な純度はビジネスに勝ちません。ソリューション do。WP は、一般の人々が Web 上にコンテンツを掲載できる豊富なエコシステムを提供しました。たとえそれが技術的な負債でプログラマーを悩ませたとしても。
使用した CPU 時間の観点から % を計算していれば、その主張はさらに印象的なものになったかもしれません。
静的 Web サイトの定義に関する国勢調査はまだ行われていません。MYSQL データベースのない Web サイトは、JavaScript または php テンプレート インクルード ファイルがある場合、まだ静的ですか？各ページを手動で編集する必要がある純粋な静的な Web サイトは頭痛の種です。
静的 Web サイトが何を意味するかについては、間違いなくコンセンサスがあります。この用語の基本的な Web 検索を試してみましたか？
> 各ページを手動で編集する必要がある純粋な静的 Web サイトは頭痛の種です。
静的サイトジェネレータがあるのには理由があります。
> 静的 Web サイトの定義に関する国勢調査はまだありません。
サーバー側のスクリプト作成はありません。クライアントサイドスクリプティングを持つことはOKです（例:)。JS の。基本的に、ASP や有料 Web ホストを購入する余裕のないほとんどの人にとって、90 年代に物事がどのように戻ってきたのか。
ここでは、約4 つの段落のためにこの質問についてワッフルしている、あなたの読書の喜びのために以下にコピー: p :)（ソース:) https://www。evalapply。org/posts/shite-the-static-sites-from-... )
> 静的 Web サイトとは何ですか？
> Static は単に as-is を意味します。その逆は「動的」であり、移動中を意味します。「静的ウェブサイト」の「静的」部分は、保存された情報に対応します。「ウェブサイト」の部分は、情報がどこから、どのようにコンピューターに届くかに対応します。Web サイトは文字通り、World Wide Web 上の場所（サイト）であり、コンピュータは必要な情報を取得する必要があります。
> インターネット上で Web ページなどの情報を取得することは、定義上「動的」です。自分のコンピュータのディスクでファイルを開くだけでも「動的」です。デジタル ファイルを読み取る、および/または送信するという行為自体が、ある場所からそのビットをコピーし、別の場所に見せることを意味します 3。
> The Ultimate Static Site は、一度書かれたファイルは決して変更されません。したがって、一度受け取ったものは、（紛失しない限り）二度と取り出す必要はありません。もちろん現実はそれほど単純ではありません。しかし、私たちは「静的手段は決して変わらない」メンタルモデルを使って作業していきます。なぜなら、それだけでかなり遠くまで進むことができるからです。
「手編集された HTML ファイルの束」から「マークダウン導関数やプログラミング言語のオブジェクト リテラル構文などの非 HTML 構文から生成された HTML ファイルのセット」までの回答を含む、良い質問です。（静的サイト） 発電機)前者とはかなり異なること。
また、ブラウザに配信するためのラストマイル マークアップ言語として、作成者が利用できると想定されるすべての HTML を備えた SGML もあります。メニュー、ページ ナビゲーション用のドキュメント アウトラインの自動生成、HTML へのマークダウンの処理、RSS または SERP へのフィルタリングなど、さらには外部/シンジケート コンテンツの統合やスクリーニングなどの中程度に複雑な動的サイト機能も含まれます/スクリプト、壊れたコメント、外部/スパム リンクなどの悪意のある入力やその他の望ましくない入力についてユーザーのコメントを検証します。
IME、最も近い定義は、単にフラット ファイルのみを含むサイトです。サーバー側のスクリプトはありませんが、クライアント側の JavaScript は非常に許可されています。それは必ずしも各ページを「手動で編集」することを意味するわけではありませんが、LLM にアウトソーシングしない限り、おそらくある時点で一部の書き込みを行う必要があります...
ビジュアライゼーションにJSが必要な完全クライアントレンダリングのテンプレート/サイトについてはどうでしょうか？（つまり、優雅な劣化はまったくありません）。
技術的には静的ですが、私の意見では絶対に最悪の種類のものです。
静的 Web サイトは、必要なものをすべて 1 つの HTML ファイルとして提供します。ソースコードを保存してオフラインで開くことができ、違いはありません。
したがって、クライアントからのリクエストによってテンプレート化が行われる場合、テンプレート化は問題外です。
静的 Web サイトの管理方法は、ビルド スクリプトを使用します。カスタム ヘッダーのオプションを使用してコンテンツをマークダウンで書き込むと、純粋な HTML にすべてを埋め込んだ Python スクリプトが表示され、github ページでホストできるようになります。
IMO では、ページは静的な Web サイト上で静的にコンパイルできるため、ページごとに HTML を手動で編集する必要はありません。でも、そうですね、静的な度合いもあると思います。私の（ブランドの新しい）個人 Web サイトは、文字通り現在すべてゼロから作成されていますが、間もなく、おそらく Markdown ソースから事前に作成されるでしょう。私はそれを静的と呼びますが、程度は低いです。
確かに、静的 Web サイトとは、wget や curl などを使用してダウンロードでき、実際の Web サーバーを必要とせずにファイル システムから直接ファイルを閲覧することで機能するものですか？
静的 Web サイトは、コンテンツを生成するためにクライアントに対して余分な作業を行わない Web サイトであると言えます。SSR または単なるプレーン HTML ファイルのいずれかです
問題は、「コンテンツ」が何を意味するのかを定義することです。「JS なし」と言っているのですか — もしそうなら、そう言ってください！それ以外の場合、「コンテンツ」と「その他のもの」をどのように区別しますか？
これについて誰かが混乱しているという話を聞いたのはこれが初めてです。サーバーが動的に生成されたドキュメントを提供している場合、それは静的ではありません。静的 Web サイトは、サービス対象のファイルのディレクトリとして完全に表現できます python - m http。server。PHP テンプレートがないことは明らかです。
> 静的ウェブサイトは `cat index。html` で提供することができます
確かに、しかしそれは十分な定義ではありません。html の内容にいくつかの制約を追加する必要があります。それ以外の場合は、レンダリングするたびに新しいページの幻覚を見る巨大な JavaScript プログラムをそこに入れることができます。これは「静的」としてカウントされるべきではありません。
ただし、通常は静的としてカウントされます。この文脈では、static には技術的な意味があり、辞書の定義ではありません。サーバー側からは静的であるため、サービスを提供するために特別なロジックは必要ありません。
> これは「静的」としてカウントされるべきではありません。
なぜしない？そうでない場合、「javascript がまったくない」以外に、どこに線を引くのでしょうか？
そのために「スクリプトなし」という用語を予約したいと思います。) 「バックエンドなし」という用語を普及させれば、この 2 つは共存できると思います。私はサーバー側の処理がないフラットファイルの単なるコレクションであるサイトについて話したいです; 私のために、 "静的" は完全にその仕事をします。
素晴らしい記事。
> 弁護士や会計士がそれぞれのドメインがどのように機能するかを明確にできず、理論的には自分で操作できるはずのシステムの避けられない仲介者になってしまうのは腹立たしいと思いませんか？
> ソフトウェア エンジニアリング、特に Webdev で単純なことを簡単にできないときは、まったく同じように社会を失敗させています。
まさにその通りです。
この修正は、GitHub Actions と GitHub Pages です。そうすれば、自分でソフトウェアを実行する必要がまったくなくなります。ビルド プロセスは完全に GitHub 上で実行され、無料でもあります。
このような静的サイト ジェネレーターを使用して GitHub Actions を使用している例がこれ以上見つからないことに驚いています。理想的には、誰かが GitHub リポジトリ テンプレートを共有します。このテンプレートには、優れた静的サイト ジェネレーターが事前に設定されており、自分のサイトのワンクリック開始点として使用できます。
私は自分でそれらの1 つを構築することを検討しましたが、私は静的サイトジェネレータを使用しない傾向があります（代わりにBaked Dataが好きです:) https://simonwillison。net/2021/Jul/28/baked-data/)だから、私はそのプロジェクトを引き受けるには素晴らしい人間ではない。
The GitHub Pages スプラッシュページ（The GitHub Pages splash page）https://pages。github。com/) は、それだけの素敵な小さなインタラクティブなチュートリアルを持っています、そして私は様々なSSG/テーマのレポテンプレートをたくさん見てきましたが、私はまだ多くのユーザーが次のハードルにぶつかると思います:
ー GitHub が何であるか、またどのように機能するか（Git 自体はおろか）がわからない
- レポのクローンを作成する方法がわかりません
- レポ内のファイルを変更するために必要なプログラム、またはその使用方法がわかりません
ー コミットの作り方/プッシュ方法がわからない
- 変更が有効になる前に変更を確認するためにローカル プレビューを構築する方法がわかりません
私の個人 Web サイトの以前のバージョンは、完全に HTML と少数の CSS で足場が作られていました。私はブログ投稿の HTML へのマークダウン コンバーターとして pandoc を使用し、すべてを HTML ファイルのバンドルにパッケージ化するための短い bash スクリプトを作成しました。GitHub Actions と GH ページもあなたが説明したように使用され、最後に GitHub Actions のホストされているページにドメインを指定しました。完璧に機能しました
コメント
コメントを投稿