ちょっとした共有です。知識には限りがありますが、これをきっかけに皆さんのご意見をいただければと思います。

Ajax

2003年のとき、私は小学6年生でした。当時、ネットカフェは小さな町の片隅にようやく現れ始めたばかりでした。「伝奇」「大話西遊」といった第一世代のオンラインゲームが一世を風靡していました。試しにやってみようと思い、ネットカフェの店長に2元を渡して、アカウントを登録して遊ぼうとしました。そしてその後の1時間、ずっとアカウント登録をしていました。

当時のネットカフェは512kの帯域幅を使っていました。登録のとき、大量の情報を入力し、送信すると、ページが遷移し、「入力した情報に誤りがあります。再入力してください」と表示されました。そして登録ページに戻され、その繰り返しでした。今でもよく思うのですが、もし当時Ajaxが普及していたら、2元を節約できたのに。

では、Ajaxとは何でしょうか？

まず、Ajaxは一種の技術です。従来のウェブページの対話方法では、ユーザーがボタン（例えば送信ボタン）をクリックした後、データとサーバーの長いやり取りを待たなければならず、その間ユーザーは何も操作できず、ただタバコに火を点けるしかありませんでした。一方、Ajaxが行うことは、サーバーにリクエストを送信するとき、結果を待つ必要がなく、同時に他のことを行うことができ、結果が得られたらそのときに対処すればよいということです。

実はAjax技術は、1998年の時点でマイクロソフトによってすでに実現されていました。しかし、2005年2月にAdaptive Path社のJesse James Garrettが記事「Ajax: A New Approach to Web Applications」を発表し、人々がそれを読んで「おっ、なかなかいいじゃないか、これはすごい」と思ってから、Ajaxは大規模に普及しました。

Ajaxの出現は、webのユーザー体験を大幅に向上させました。今日に至るまで、中国国内のIT発展がどんなに遅れていても、すべてのウェブサイトのログイン・登録はAjax対話を実装しています。ユーザーが情報を入力し終えた後、ページをリフレッシュしなくても情報の送信が成功したかどうかが分かり、どこが間違っているかを修正すればよいのです。

また、Ajaxはフロントエンドとバックエンドを分離するソリューションとして、中国国内のあまり低レベルではないほとんどの企業に採用されており、間接的にPHPなどのウェブページスクリプト言語の衰退も招きました。

jQuery

初期のjsプログラミングは、コードの効率が極めて低かったです。これは特にDOM操作に顕著で、開発者がボタンにイベントを追加したい場合、そのボタンを取得するために長くて繰り返しのコードを書き、さらにイベントを追加するために長くて繰り返しのコードを書かなければなりませんでした。ベテランの開発者ならよく使う操作をカプセル化するでしょうが、カプセル化ができない初心者にとって、これは間違いなく非常に苦痛なことであり、特にさまざまなブラウザ互換性の問題が加わります。

2006年、初心者を救い、彼らにdo moreを実現させるという趣旨のもと、jQueryが誕生しました。jQuery誕生の意義は、第一にIE6、7、8およびさまざまに割拠するブラウザへの互換性を確保したこと、第二にDOM操作を大幅に簡素化し、開発効率を大きく向上させたことです。jQueryは非常に人気で、中にはネイティブjsを書けずjQueryしか書けないフロントエンドエンジニアが出るほどでした。今日に至っては、jQueryは「write once, see everywhere」と言っても過言ではありません。

jQueryのもう一つの意義（私の考えでは）は、人々のフロントエンドへの関心と探求心を触発したことです。Linuxに比べて、非常に低いコストで、プログラミングを知らない女の子に「オッパ、すごい！」と言わせるような効果を生み出すことができ、人々に「おっ、（また）いいじゃないか、これはすごい」と思わせることができました。その後、多くのライブラリやjQueryベースのプラグインが雨後の筍のように次々と誕生し、フロントエンド業界は活気に満ち、ウェブ開発は新たな時代に入りました。

Chrome

天下の武術はすべてGoogleから出ずる。IE6、7、8の時代には、FirefoxもゆっくりとIEの地位に挑戦していましたが、2009年からGoogleが普及させ始めたChromeブラウザがもたらした破壊的な影響に比べると、はるかに見劣りします。ChromeはAppleのオープンソースカーネルWebKitを採用し、優れた設計標準と市場での高い評価を得て、ブラウザの急速な進化を促し、IEをWindows 10から完全に消し去りました。

Chromeブラウザの登場は、フロントエンド入門のハードルをさらに一段下げました。その内蔵デバッグツールは便利で簡単に使え、ネットワークの状態や読み込み順序を簡単に確認したり、ブレークポイントデバッグなどを行うことができます。同時に、Googleの拡張機能は開発者に大きな利便性をもたらしました。

現在、Chromeの最新版はBlinkカーネルを採用し始めており、テスト版では、CSS3アニメーションの追跡とデバッグがすでに可能になっています。私がまだ想像もしていなかったときに、Chromeはすでにそれを実現していました。

一言で言えば、Chromeがなければ新中国もなく、Firefoxを使うしかなかったでしょう。

GitHub

ソフトウェアプロジェクトのイテレーションが速くなるにつれて、プロジェクトのバージョン管理ツールも絶えず進化し、CVS、SVN、Gitを経てきました。現在までに、CVSはインターネット業界からほぼ姿を消し、SVNはファイルやドキュメントの保存用として存在しています。Linuxカーネルの発明者Linusによって作られたバージョン管理ツールGitは、現在コードバージョン管理の標準となっています。GitHubはGitに依存し、開発者のチームコラボレーションのコミュニティとなっています！2015年1月までに、GitHubに登録された開発者は1000万人を超え、オープンソースプロジェクトは数千万に達しました。その中で、2014年は中国の開発者がGitHubで最も急速に増加しました。あなたはほとんどすべての欲しいコードをそこで見つけることができます…例えばusername..password..

OAUTH

OAuth1またはOAuth2が従来の認可方式と異なる点は、OAuthの認可では第三者がユーザーのアカウント情報（ユーザー名やパスワードなど）に触れることがないことです。
発生背景：最も一般的なサービスシナリオでは、ユーザーは2つの異なる企業のサービスを利用する必要があり、A企業にログインして認証を受け、コンテンツをダウンロードし、次にB企業にログインして認証を受け、コンテンツをB企業のサービスにアップロードする必要があり、複雑で時間がかかります。ユーザーもA社もB社も、サービスの相互連携を望んでいます。これにより、身元を確認する必要性が生じました。従来のユーザー名・パスワード方式では、A社/B社が相手のユーザーリソースを閲覧したり、さらには修正したりする権限を持ってしまうことになります。身元確認とサービス連携を実現するため、Google、Yahoo、Microsoftが先頭に立ってOAuth1.0の誕生を促しました。その後のOAuth2.0は、各大手インターネット企業がhttpsの安全性に基づいて行った新たな計画です。

現在、最も一般的な応用シナリオは主に認可ログインにあり、例えばWeChat、QQ、Weiboなどです。

JSON

JSONは2001年に生まれた標準ですが、広く応用されるようになったのは2008年以降、さまざまなAjaxアプリケーション、iPhone、Androidデバイスが普及した後です。従来のサービス体系は企業級が多かったため、XMLはJava型の企業級サービスにとって有益でした。しかし、トラフィックに制限があり、セマンティクスが単純なAPIサービスにとって、XMLは膨大で冗長であり、学びにくく、帯域幅も消費します。

昨年、私が働き始めたばかりのとき、バックエンドが私に配列を返してきました。発言権のない私は、この配列を走査するべきか、それともJSON形式に変換するべきかで、長い間悩みました。

JSONの普及は、別の角度からweb開発の利点を示しています。バックエンドがJavaであれRubyであれPHPであれPythonであれ、JSON形式のインターフェースを提供してくれれば、私は全世界を支えることができます。

DJANGO&RAILS

アジャイル開発はプロジェクトの開発モデルを打ち破りました。2010年以降のWEB2.0時代には、HTML5が盛んになり、フロントエンドの作業が分離され、PHPのようなウェブページスクリプトの優位性はそれほど顕著ではなくなりました。CMSやフォーラムテンプレートでは依然として優位性がありますが。DjangoとRailsの最大の利点は、個人または2、3人の小規模チームが製品全体を実現することを可能にしたことです。Instagramを例にとると、最初は2人のPythonエンジニアがDjangoを使ってサーバーサイドのすべての機能を迅速に実装し、ユーザーが増えると、大アクセス数・大データ量のサービスを分離しました。

現実は残酷で、Railsは衰退の一途をたどっており、IE8とRailsのどちらが先に消えるかは時間の問題ですが、その提供したソリューションは多くの後進によって模倣されています。人々はこの一瞬咲いた花を覚えているでしょう。

Bootstrap

2011年にTwitterがオープンソース化したウェブ向けGUIフレームワークです。jQueryが異なるブラウザのjs部分を互換したように、Bootstrapは異なるブラウザのCSS部分を互換しました。さらに言えば、バックエンド開発者であれば、CSSを理解する必要も、フロントエンド担当者も、デザイナーも必要なく、Bootstrapのドキュメントを見るだけで、美しく見栄えのする管理システムを構築できます。同様のGUIフレームワークとしては、ZurbのFoundation、GoogleのMaterializeなどがあり、百度（Baidu）もGMUというモバイル向けフレームワークを出したことがあります。

個人のには、これらのGUIフレームワークは好きではありません。CSSを簡素化し、とてもクールな効果を実現しているにもかかわらず、プロジェクトでもこれらを使ったことがあるにもかかわらず、自分が偽善者だと認めたくはありませんが。これらのフレームワークの最大の欠点は、画一のであることです。すべてのページが同じような外見で、同じnav、同じsidebar、同じフォーム、マウスを乗せたときの光り方までまったく同じです。たとえば、もし私に3本の足があったら（実際に3本ありますが）、人々は「珍しい、目を引く」と言うでしょう。しかし、すべての人が3本足だったら、webはその魅力を失います。もう一つの欠点は、肥大化していることです。CSSだけで100KB以上のトラフィックを消費し、そのjsプラグインの多くはjQueryに依存しています。それに耐えられますか？

もちろん、レスポンシブ対応のために提唱されたグリッド化HTMLの考え方は、大いに参考にする価値があります。

IOS & ANDROIDシステムの普及

2009年以降のIOSとAndroidの急速な発展により、WEB開発には以下の変化が起こりました：
1. HTML5がモバイルブラウザで優先的に実装され、AndroidおよびIOSデバイスがHTML5、CSS3を全面的にサポートし、IEの消滅を加速させた。
2. インターネットへのアクセスはいつでもどこでも発生するようになった。マウスクリック前提で内容が複雑だったウェブページはますます簡潔になり、レスポンシブデザインが急速に普及した。
3. APPとサーバーのやり取りの大部分はウェブページと同様にHTTPプロトコルに基づいており、webapp、hybrid appの概念が提唱された。

webappについて、ここではwebがネイティブと比べて持つ利点を簡単に説明します。

• クロスプラットフォーム：よく言われる「一度コンパイルすれば、どこでも実行できる」
• インストール不要：ブラウザを開くだけで使用できる
• 迅速なデプロイ：アップグレードはサーバー側でコードを更新するだけでよく、クライアントのようにバージョンの更新は不要
• ハイパーリンク：他のウェブサイトと相互にリンクでき、検索エンジンにインデックスされる

聞こえはなかなかすごいが、これらの利点はつっこみに耐えない。まず、異なるシステムのユーザー操作習慣は異なる。iOSユーザーは戻るボタンが左上にあることに慣れているが、Androidユーザーは画面最下部にあることに慣れている。プロダクトマネージャーが尋ねる、じゃあどこに置くの？と。あはは、知らない。次に、かつてユーザーがクライアントとWebどちらを好むかを尋ねた調査レポートを見たことがある。

クライアントを好むユーザーはWebをはるかに上回った。私が何が好きかと聞かれれば、私もクライアントが好きだ。なぜかと聞かれれば、安心感があるからだろう。それに、バージョン更新があるととても気持ちよく、存在感を感じられる。自分が世界に忘れられていないと分かるし、製品が更新され、自分のために気を遣ってくれていると分かる。さらに、ハイパーリンク…クライアントにSEOが何の役に立つというのか。これだけではない。Webアプリの欠点はまだたくさんある。最大の欠点はGPUアクセラレーションがないことで、少し複雑なアニメーションを実現しようとすると、ブラウザにとっては本当に堪えたものではない。次に、Webページはシングルスレッドで、DOMの読み込み中にJSがブロックされ、結果としてカクつく。カクつくとイライラし、イライラすると閉じてしまう。ユーザーが一人減る。

一方、hybridはこれとは異なる。hybrid appとは、ネイティブアプリとWebを組み合わせたもので、頻繁に更新が必要なページをWebとしてリモートで更新するものだ。これは信頼できる解決策であり、BATには多くの事例がある。例えば、微信が公開したJS SDK、掌上百度、淘宝クライアントのAndroid版などだ。

もちろん、ここには落とし穴がたくさんある。機会があれば、私が踏んだ落とし穴を皆さんに話したい。

NodeJS

Nodeがフロントエンドの範疇に属するかどうか、しばらく悩んだ。私は属すると思う。

高同時接続の解決は、バックエンド担当者たちが喜んで議論する問題だ。例えば我々の「好近」リアルタイム監視システムでは、理論上、各接続が新しいスレッドを生成し、各新スレッドには約2MBの付随メモリが必要かもしれない。8GB RAMのシステムでは、理論上の最大同時接続数は4,000ユーザーだ。ユーザーが増えるにつれ、監視プログラムがより多くのユーザーをサポートしたいなら、より多くのサーバーを追加しなければならない。もちろん、これにより運用コスト、特にサーバーコストが増加する。コスト上昇に加え、技術の問題もある。ユーザーはリクエストごとに異なるサーバーを使用する可能性があるため、共有リソースはすべてのサーバー間で共有されなければならない。ここまで来ると、技術は限界に達する。Nodeが生まれた本来の目的は、まさにこの問題を解決することだ。Nodeがこの問題を解決する方法は、サーバーへの接続方法を変えることだ。各接続に対して新しいOSスレッドを生成し付随メモリを割り当てるのではなく、各接続はNodeエンジンのプロセス内で実行されるイベントを発生させる。

nodejsはサーバーサイド言語に属し、フロントエンドとバックエンドの分離という囲い込み運動において、フロントエンドにとって有利な武器である。同時に、フロントエンド自動化の面でも、多数のプログラマブルツール（grunt、bower、gulpなど）を提供している。淘宝や百度はnodejsへの関心が常に高い。自然に、私はこれはトレンドだと思う。昨年、美団は美団酒店チームを立ち上げ、バックエンド言語としてnodeを選び、バックエンドの仕事の大部分を奪っていった。私は考えている。フロントエンドのJSにnode、さらにUIのスキル要件が加われば、今後フロントエンドエンジニアは「全端エンジニア」と呼ばれるべきなのではないだろうか。

BIG DATA

ビッグデータはここ数年で最もホットな言葉だろう。私の多くの同級生は、データマイニングの年収が30万元だと聞いて、わーわー言いながらデータベースの仕事に走った。
ほとんどの場合、私たちがビッグデータについて話すとき、実際には大量データにおけるデータマイニング、データ分析、知的推薦、リアルタイム分析などを話している。会社によって技術ソリューションは異なるが、ここでは中国国内の成功事例を2つだけ挙げる。
• 京東（JD.com）のパーソナライズEコマース。シーンには、行動、嗜好、地域、時間、友達関係などの次元に基づいて、異なるユーザーに異なる商品を推薦する。ユーザーによって検索結果の商品の並び順も異なる…
• 百度地图（Baidu Map）の東莞8時間の移動マップ、百度検索のスマートリマインダー
• 360手机卫士の電話番号迷惑防止機能は、ユーザーの地域、身分、迷惑傾向を通じて、マークされた2.56億件の電話番号から、ユーザーとの関連度が最も高い1000件を選び出し、ユーザーの携帯電話内の10kのテキストに書き込む。これにより、ネットワークに接続せず、いかなるネットワーク通信も行わずに、ユーザーの迷惑電話を防止できる。

HTML5+CSS3

これはこの数年言い尽くされた言葉だ。誰もがHTML5と言っているが、HTML5とは何かと聞かれても、彼らもはっきりとは説明できない。とにかくかっこいい、とにかく派手、とにかくクールで派手、というだけだ。

私の見解では、HTML5はただの三人成虎（根拠のないうわさが人を信じ込ませる）のようなものだ。それが集める注目は、提供する機能をはるかに超えている。HTML5はいくつかの新しいAPIを提供しただけで、それはアプリが1.0から2.0にアップグレードして「近くの人」機能が追加された程度のことだ。しかも、そのAPIはモバイル側で試しに使われているにすぎず、PC側では互換性の問題から、常に正式に迎え入れられることはなかった。PC側の開発は依然としてHTML4.0+CSS2を基準にプログレッシブエンハンスメントを行っている。css3に関して言えば、最も注目されているアニメーションも、Flashが使い古したものだ。

モバイル端末の急速な発展がHTML5の発展を促進し、HTML5の発展もまた各ブラウザを標準化へと向かわせた。

この標準化の道のりでは、微信（WeChat）の貢献は大きい。1024、围住神经猫、淘宝十年、LEXUS NXなど、大量のHTML5+CSS3要素を融合させたページは人々に強い印象を残した。

さらに、マイクロソフトはIEの名称を捨ててEdgeを開発し、各ブラウザベンダーは標準化を進め続け、HTML5草案が定稿し、ES6草案の実装と改善が進んでいる。フロントエンドの道は、平坦で広々とした大道のように見え、私は期待に満ちている。

未来

3Dブラウザゲーム？ WebOS？ 仮想現実？

最後に、ユーザーのハードウェア性能の向上、ネットワーク帯域幅のますます広帯域化、センサーシステム、Retina、WebGL技術の日々の成熟に加え、O2Oの活発な発展によって、上記のこれらは現実になるのだろうか？

出典：http://www.cnblogs.com/sussski/p/4634595.html