私たちはそのウェブを失いました。

簡単に言うと 、ブラウザ戦争の後、W3Cの組織とWeb Standards Projectなどの開発チームは、断片化されていない単一のWebを復元するために長く懸命に働きました。 しかし、ここ数年で、開発者はすべてを取り戻し、断片化を繰り返しました...おそらく、このWebを永久に失う前に、何が失われているのかを理解する必要があります。



ちょうど1年前、Web業界の総支配人であるAnil Dashは次のように書いています。「 私たちはWebを失いました 」。 これは当時を捕まえた多くの人々に共鳴しました。 皮肉なことに、これらのカタコンベで働きに行った多くの人々。



特に、2000年代中頃までの期間がWeb上での完全な存在よりも早い場合は、ゆっくりと彼の記事を十分に読む必要があります。 ウェブは過去10年で実際に変化しましたが、必ずしも良い方向に進んでいるわけではありません。 アニルは書いている：

「私たちは、ウェブの根底にある基本的な価値観を捨て、さらに悪いことに根底にある基本的なアイデアを失いました。」

...そして、彼がメモを書いた目的の1つは、新しいソーシャルアプリケーションを作成する人々が履歴に触れてその起源を見つけることであると述べています。



おそらく、これらのアイデアのいくつかは実際に空中にあります。これは、過去数週間でFarukAteşとJeremy Keithもこのトピックについて考えていたからです。



そして、私はこの一年の大部分で、インターネットのはるかに限られたコンポーネントについて考えていたにもかかわらず、初期のウェブから何かを失ったと感じて、これについて考えました。 通常、ほとんどのWebユーザーの視野に入らないものについて-そのコードについて。 それは彼にも当てはまると思います。 「 ... Webの世界の起源にあった基本的な価値を捨てた」。

ブラウザ戦争

Anilは2000年頃からWebについて話していましたが、1990年代中頃からこの用語について言いたいと思います。 現在、私たちのほとんど全員がブラウザ戦争について聞いています。 何が起こったのかと聞けば、NetscapeとMicrosoftがインターネットの支配をめぐって戦い、ブラウザを支配させようとしていた時期だと言う人がほとんどでしょう。



しかし、彼らはどのように支配を達成しようとしましたか？ ある意味で、ブラウザ戦争（Netscapeとその前身のMosaicは最初に戦っていました）は、「HTML戦争」と呼ぶことができます。



「HTMLの標準バージョン」はありませんでした。 代わりに、ブラウザの新しいバージョンでは、img、リスト、テーブル、フレーム、フォント、埋め込みタグなどの新しい言語機能が登場しています。 言語全体（Javascript）とDOMなどの複雑なアーキテクチャが登場しました。 それはほとんど良かった。 ウェブは複雑になり、すぐに重要な機能を獲得しました。



ただし、元々標準化された機能はなく、標準を開発したものはありませんでした。それぞれが最初にブラウザーの1つに登場し、他の機能は成功したソリューションを急いで再設計し、原則としてある程度互換性のないバージョンの形で独立して実装されました。



この期間から、「最初に歩く」人が勝つことを学びました（たとえば、より柔軟なメカニズムを提唱したティムバーナーズリーの反対にもかかわらず、マークアンドレスンによって提案された「img」タグが勝ち、今日まで私たちに現れ続けています） ） アーキテクチャレベルで行われた決定は、半減期が非常に長くなる可能性があるため、慎重に行う必要があります。



これは、今日のWeb開発者の苦情の一般的な流行です。 簡単に言えば、ブラウザーの不一致がWeb開発の頭痛の原因です。 ブラウザのリリースごとに変化する、最新でほとんど作成されておらず、文書化されていない機能でサイトを開発するのに何が必要か想像してみてください。



W3Cグループが見たのはこの混乱であり、その役割はまだよく理解されていません。 この委員会の目的は、革新を標準化するために利害関係者との対話を確立することです。 少し後に、Web開発者は新しい標準の採用を支持する必要性を感じたため、Web標準プロジェクトが誕生しました（今年の初めに、おもしろそうに思えるかもしれませんが、「ここでの作業は終了しました」と述べました。



しかし、ブラウザ戦争とその後のW3CおよびWeb Standardsプロジェクトの基盤の結果がインターネット上の「バルカン化」を回避したという事実を見失ったようです。 汎用性と互換性がインターネットにとって重要であることはわかっていました。 また、ブラウザの断片化によりGalaxyが危険にさらされていることもわかっていました。



特に1990年代後半のインターネットイベントに精通していて、NetscapeのJSSS（JavaScript StyleSheets）の対立とCSS、互換性のない文書化されていないDOM、JavaScriptとJScript、Netscape CommunicationsとMicrosoftの激しい戦い-この背景に対して、 HTML、CSS、JavaScript、およびDOMを標準化することで断片化されなかったWeb。このようなWebの利点を使い果たした開発者に提供します。 それは素晴らしい成果でした。 Microsoft、Apple、Mozilla、およびGoogleの多くの人々は、標準ベースのテクノロジーに関する開発者の教育を提唱した人々とテクノロジーを標準化するという恩知らずな仕事をたくさん行ってきました。 一部は有名になり、ほとんどはささやかな報酬のために一生懸命働いたが、誰もがウェブはそれだけであるべきだと感じた。



そして、ゆっくりと沸騰する水で死に気づかないカエルのように、私たちはこのウェブを捨てました。

• DOMライブラリとフレームワークの断片化を許可、推奨、および承認しました。それぞれに属性へのアクセス、要素の変更、およびDOMの管理の独自の方法があります。
• JavaScriptを断片化して、言語をコンパイルしました。
• 大量のテンプレートエンジンでHTMLを断片化しました。
• SassやLessなどのプリプロセッサでCSSを断片化しました。

私たちは何をしましたか？

これは、周りのすべてが完全に悪いという意味ではありません。 これは事実とはほど遠い。 これらのテクノロジーとイノベーションはそれぞれ、開発者に新たな課題をもたらします。 多くは将来の標準のための方法を図解しています。 しかし、全体として、HTML、CSS、JavaScript、DOMという比較的単純な独立したテクノロジーセットを採用しました。 それぞれが明確に定義された役割を持ち、それぞれが習得して作業を開始し、競合するテクノロジーの混oticとした動物園を作成しました。



この方法では、他の言語や環境への依存性が追加されました。これは、インターネットにはなかったアセンブリ段階がワークフローに登場したためです。

何を得たの？

おそらく開発者の生産性は向上しているでしょう。 おそらく、プロジェクト開発の初期段階で作業が楽になりました。 しかし、信仰を維持するという名のもとに個々の成功以上のものがあることを疑う理由があります。 私を信じて-これはあらゆる新しい技術の共通の議論です-それは開発をより生産的にするでしょう。 文学から何かを読みましたか？ （私たちの遺産をもう少し高く記憶するように説得したことを思い出してください。）そしてソフトウェア開発者は、システムのコストのほんの一部がその開発の初期段階に関連していることを長い間認識していました。 長年にわたるメンテナンスは、システムのコストの非常に重要な部分です（はい、このテーマに関する文献はたくさんあります）。

しかし、何を失ったのでしょうか？

Web開発は、多くの言語、基盤、開発環境が基盤となっている長年の最大のプラットフォームであるWindowsの開発のように、同じ言語であるCoyne 、 lingua francaを話すという点で、他のほとんどのテクノロジーとは異なり始めましたWindows API この共通言語は、Webテクノロジーの習得を容易にし、プロジェクトサポートを簡素化するなど、多くの利点をもたらしました。 これにより、Web開発者の知識と経験の活力が高まりました。

学習性

フロントエンドに共通のテクノロジーセットがあると、トレーニングが簡素化されました。 これらの技術に関する教科書、専門家、ワークショップを見つけるのは比較的簡単でした。 スキルと知識を習得するのは比較的簡単でした。 いくつかのHTMLおよびCSSコードを記述して、有用なものを作成できます。 時間が経つにつれて、それらの知識を増やし、JavaScriptとDOMの理解を追加して機能を拡張できます。 共通の言語と概念を持つ開発者の大規模なグループの存在により、ネットワーク効果がありました。



インターネット上の技術を断片化し、専門用語の研究所のカタコンベを掘り下げて、共通言語の一部でこのネットワーク効果を本当に削減したいのでしょうか？ 少なくとも、私たちの選択の潜在的な結果に注意する必要があります。 選択の個々の利点だけでなく、一緒に私たちが失うことができるという事実を実現しています。

保守性

共通のテクノロジーセットがあると、既存のコードベースの保守が容易になります。 基礎となるHTML、CSS、JavaScript、およびDOMテクノロジーは、ほとんどのフレームワーク、ライブラリ、言語、およびプリプロセッサーとは異なり、長期間安定しています（部分的に依存しているツールや言語は言うまでもありません）。 サービスのベースは5年間サポートされますか？ また、あまり一般的でない技術に基づいて、コードベースをサポートできる開発者の数は大幅に削減されます。



従来、複雑なシステムのコストの半分以上が運用フェーズにかかっていたため、大きな変更を加えると、ソフトウェアプロジェクトの進化的開発をリードするよりも、すべてを捨てて新たに構築しやすくなります。 私たちがインターネットのために構築しているものはますます複雑になっており、ミッションクリティカルなプロジェクトの場合、メンテナンスフェーズはより長く、より高価になります。 繰り返しになりますが、単純にコピーアンドペーストを使用して編集するのではなく、コードベースを長期間維持する理由（動機）を理解し、それを維持するために、保守性が異種の開発者の能力に大きく依存していることはよく理解されています。 ]。

相互作用

Webの基本原則の 1つは「互換性」です。 これは、「コンピューターの言語とプロトコルが、過去の市場の断片化を回避するように設計されている」という懸念に直接関係していますが、断片化は、作業コードを備えたシステムの場合にだけ気にするべきではないと主張します。 また、Web開発者コミュニティの断片化についても心配する必要があります。 テクノロジーに関する実用的な知識を持つ開発者が少ないほど、テクノロジーの問題について対話する可能性は低くなります。



同じサークルから-テクノロジーが互いにどのように相互作用するかという問題。 Sassが変数を実装する方法は好きですが、LESSでも@ debugを使用したいとします。 あなたはLESSとSassの両方を必要とし、おそらく混乱の地獄が噴火します。 多くの「革新」のモノリシックなアプローチは、相互作用の方法に大きな影響を与えます。

長寿

FlashまたはSilverlight / WPFの知識と経験の開発に何年も費やした場合、この知識はますます役に立たなくなります。 jQueryでも、Prototypeなどの一見支配的なJavaScriptライブラリやフレームワークの場合と同じことが起こります。 これは、私たちが今日一生懸命勉強しているすべてのライブラリとフレームワークで起こります。AngularJS、Bootstrap、<...あなたの名前を置き換えてください...>。 数十年は言うまでもなく、近年ではほとんど技術が生きていません。 技術の勉強にかなりの時間を費やす人として、私はその努力が正当化されることを心配します。

どうする？

jQuery、Backbone、AngularJS、CoffeeScript、Bootstrap、Sass、LESS（問題を解決するために過去数年にわたって開発した最も人気のあるフレームワーク、ライブラリ、言語、およびプリプロセッサの一部を挙げます。 ）洗練された強力なテクノロジーであり、数千、数万人以上の開発者が使用する非常に多くの作業プロセスで十分に実証されています。 彼らは去りません。 そして、それらの後に他の人が来るでしょう。 高度な技術からHTML、CSS、DOM、JavaScriptへの没入を遅らせる必要があるかもしれません。 結局のところ、プログラマーは、マシンコードは言うまでもなく、アセンブリ言語を作成します。 しかし、Anil Dashが別のWebについて書いたように、「Web の世界の起源にある基本的な価値を放棄しました 」と、作成されているコードについても同様だと思います。



これらのコアバリューは何でしょうか？ それらがW3Cコンソーシアムによって明確に記述されていることは簡単にわかります（もう一度、Anilは「 その歴史を知るために、少し歴史を学んでください」と言いました）。

「W3Cは技術的な卓越性に取り組んでいますが、今日知られていることだけでは明日問題を解決するのに十分ではないかもしれないことを十分に認識しています。 そのため、すでに機能しているものを壊すことなく、さらに優れたWebに簡単に変換できるWebの構築に努めています。 シンプルさ、モジュール性、互換性、拡張性の原則は、すべての設計の根底にあります。

W3Cの目標、運用の原則、およびその焦点



開発者は、新しい言語を開発するときに、シンプルさ、モジュール性、互換性、および拡張性というこれらの原則に導かれていますか？ フレームワーク？ プリプロセッサ？ もちろん、多くの場合、はい。 これは、特にポリフィルとプロリーフィルに当てはまります。 膨大な機能を整理することで「海を沸かす」という目標はありませんが、1つのことを行う「小片の自由な取り付け」のモデルに従いますが、それはうまくいきます。



しかし、多くの場合、当社のソリューションはモジュール式ではなく、単純または互換性がありません（特に任意の組み合わせ）。 実際、これが問題の本質だと思います。 シンプルさ、モジュール性、互換性を通じて特定の問題を解決する代わりに、当社のソリューションは、あらゆる種類の問題に対するソリューションのより複雑な山になります。 CSSプリプロセッサアーキテクトがSassの設計原則について報告している例を次に示します。

»新しい機能をSassに追加する正式なプロセスはありません。 適切なアイデアは誰からでもどこからでも生まれる可能性があり、メーリングリスト、IRC、Twitter、ブログ投稿、その他のCSSコンパイラ、またはその他のソースからそれらを見ることができます。

... ホーマーに似ている可能性が高い：

小片の無料添付

2002年、ウェブの先駆者の1人であるDavid Weinberger（偶然、Cluetrain Manifestoの共著者）は、「 小さなゆるく接続されたピース 」-インターネットを特別なものにする考え方を説明しました。 私はこれがインターネット技術にも当てはまると長い間考えていました。これらの原則は、私たち自身のサイト、顧客、雇用主、またはインターネット上で開発する技術自体のために、インターネットのプロジェクトをどのように作成するかを決定する必要があります。



問題を解決しようとするたびに、「この小さな問題をどのように解決できますか？」または「ここに本当に問題があるのか？」と考え、モジュール性、互換性、および拡張性の原則に基づいて解決します。可能な限り、過去5年ほどで見た複雑さの爆発を抑えるための長い道のりを選択し、少なくとも部分的には失われたWebに戻ります。



おそらく、このウェブは、私たちが構築しているますます複雑化するモデルの課題に対応するために成長しなければならないでしょう。 Webがドキュメントとサイトで構成されていたとき、私たちは単純さを保っていたかもしれませんが、アプリケーションの時代では、単純さは余裕がない贅沢です。 おそらく、時間の経過とともに、プラットフォームの必要なすべてのフラグメントに対する根本的な改善が必要になるでしょう。



しかし、このウェブを永遠に失う前に、そのウェブとその正確な動作を保証するものを本当に理解する必要があると思います。 そして、ウェブがどのようなものになるかについて技術的、アーキテクチャ上の決定を下すとき、私たちは自分自身の利益だけでなく、現在のインターネットがそれらによって失うものについても考えるべきです。



UPD 12.12.2013 16.00 ：ブログで著者が1週間で書いたものとここで-1日で比較するのは興味深い。 英語コメンテーターの翻訳の開始をすべて続けて説明します。



一般的にはもう少しありますが、それでも1週間は状況の分析の完全性に遅れることはありません。コメントのすべての特別なポイントに注意しました。