Clever Geek Handbook

Javascript：吸引フラクタル

むかしむかし、PHPの欠陥に関する記事に出会いました 。 そして、JavascriptはPHPにいくらか似ており、デザインのフラクタルと呼ぶに値するものであるように思えました。 結局のところ、PHPのすべての問題は当初、その狭い主観性から生まれました。 Javascriptは、このような広範な標準ライブラリを所有していませんが、ブラウザーでのみ動作するように長い間添付されていましたが、それでも汎用言語に似ていました。 PHPのようにテキストを操作するような一般的な方向性がなかっただけです。 そして、これは言語の設計にミニマリズムをもたらしました。 そして、このミニマリズムは問題を引き起こしました。



ライブラリを使用してミニマリズムの問​​題を解決しようとすると、新しい問題が発生しました。ライブラリの問題です。 ライブラリの問題を解決しようとすると、プログラマに問題が発生しました。 プログラマから私の愚かさについて十分に聞いたとき、私は言語をより深く研究し始めました。 そして、私の前に新しい問題が開かれていました。 その結果、経験が増えるにつれて、Javascriptエコシステムが提供するツールを使用する必要に迫られました。 また、古い問題を解決し、新しい問題を作成しました。 そして、これらすべてはフラクタルにさえ似ていませんが、そこから抜け出せない貧弱なデザインのofい迷路です。



プログラミングの長年にわたって、私は多くの言語に出くわしましたが、それらにはすべて問題があります。 しかし、これらの言語はすべて、主な問題をランダムにリストできるという事実によって統一されています。 Javascriptの場合、すべてが異なります。この言語の問題をすべてリストすることはできません。 どこから始めればいいのかわからない、何かを見逃しているようだ、説明できない、広大さを把握できない。 しかし、少なくとも同じように感じる人々の平和のためだけなら、私はしようとします。





まだ問題があるのはなぜですか？



Javascriptは、Perlの歴史を完全に再現しています。Perlは、一時的に同様の離陸とほぼ同じ問題を経験しましたが、15〜20年後にはJavascriptは悪のPerlパロディであるとさえ言えます。



Perlは元々、特に複雑なWebアプリケーション向けのWebプログラミング言語ではありませんでした。 Javascriptもそうでした-それはページの単純な対話性を作成するように設計されていたので、クライアント側の負担はすべて肩にかかっていました。 PerlにはJavascriptと同じレベルのOOP実装の欠点がありました-OOPはそうでしたが、非常に独特であり、多くの人がそれを好まなかった。 そして、サードパーティのライブラリを介してOOPを実装しようとする多くの試みがあります（実際に！）。 Javascriptのように。 Perlには自慢のクロージャーもありましたが、それについては気にしませんでした。



90年代および2000年代に、皆がPerlサイトへの書き込みを急いだとき、多くのWebプログラマーの資格は最高ではありませんでした。 学生、求職者、または雇用主の手に落ちた人々でさえ、ウェブに行きました。 現在、Javascriptデザイナー、レイアウトデザイナー、そしてもちろん、学生たちは破裂しています。 どちらの言語も、コードの設計と疑わしい構成の使用に関して、非常に自由です。 真珠の野bar人（そして今では隠すことのできない罪-そして今）は、言語の複雑さと自由を誇りに思っており、脳の構造を書き出し、呪われた初心者とアンダープログラマーを手に入れた他の言語のすべてのプログラマーを非難しました。 Javascriptプログラマーは今、誇りに思っています...しかし、私は前の文を現在形で書き直すのが面倒です。



どちらの言語にも最初は明確に定義されたアプリケーションの分野があり、最終的にそこから抜け出し、定規を手に入れてクロールしました。 両方とも独自のパッケージマネージャーを取得し、PerlがCPANモジュールの品質を信頼することが危険である段階をすでに通過している場合、npmはその一部にすぎません。



PerlはPHPの基礎を築き、その最初のバージョンはPerl自体で作成されました。 したがって、WebプログラミングのためのPerlの過度の複雑さを克服する試みがなされました。 また、同様の方法で、今日、ますます多くの言語がJavascriptに取って代わり、その範囲を主張し、その欠点を排除しているように見えることを観察できます。 これらは、Dart、CoffeeScript、およびおそらく他のものです。





終わりの始まり



すべてを最後まで読むのが面倒な場合、Javascriptの主な問題は、「言語の範囲は、それを満たせないという要件を提示します」というフレーズで定式化されます。 そして、この問題は言語の作成時にも発生しました。



JSは「Javaのように見える」ことを義務付けられていましたが、Javaのある種の愚かな弟になるために、より小さくなっています。 さらに、それは10日以内に書かれているはずでした。そうでなければ、JSよりも悪いことがありました。


それは1995年5月であり、何も悪いことではありませんでした。 残念ながら、Javascriptの作成から15年後にWebインフラストラクチャがどうなるかを知っていた最後の人は、約2000年前に天国に昇りました。 悪の言語は、今日のWebアプリケーションがどのようなものになるかを知っていれば、彼は昇格しなかったと言います。



その間、私たちが今とても苦しんでいる不健康な誇大広告は、その作成時に言語で定められました。 名前にはJavaという言葉が存在しますが、その理由は同じ名前の言語が急速に普及していたためです。 新たに作られたろくでなしを宣伝するのはとても良かったので、これまでのところ（10年前よりもはるかに少ないですが）、これら2つの言語を混同している初心者プログラマーに会えます。 プログラミングとはかけ離れて、顧客は両者の違いを見ることはありません。 計画どおり。



名前の大騒ぎを捨てて、Javascriptが初めて良かったので、jQueryが登場したときにJavascriptに最も共感した時期が来ましたが、nodejsは登場せず、AngularやKnockoutのようなフレームワークも人気がありませんでした。 この期間はかなり曖昧ですが、ブラウザ間の互換性に関連する主なJavascriptの問題が解決された時期を明確に追跡しており、言語の生産性と表現力の問題がまだ十分に発揮されていません。 jQeuryを使用すると、Javascriptの本来の目的である、対話型ページを作成し、美しくするために、頭痛なしで行うことができました。



そして、成功に触発されて、開発者は、Javascriptで重いクライアント側アプリケーションを作成できると判断しました。 その後、ほとんどの言語の問題が明らかになりました。この分野から遠く離れた人でも見つけるのはそれほど難しくありません。 バウアーのようなリポジトリにあるJavascriptの豊富なモジュールは、言語の問題を生き生きとガイドしています。 実際には、ほとんどの言語はライブラリによって拡張されており、Javascriptではライブラリのクラス、さらにはテクノロジ全体でさえ、言語自体の問題を解決するために広く表現されています。



しかし、Javascriptはここでは先駆者ではありません。同じPerlには言語標準でのOOPの高度な実装がないため、このOOP自体を実装するモジュールの数は年々増えています。 しかし、少なくともあなたはperloviksを理解することができます-可能な限り多くのモジュールを通訳者の標準供給に入れないことは公式の政党方針です。 そして、Perlがその使用の性質を考えると、そのようなOOPサポートを特に必要としていたわけではありません。 もう1つ重要なのは、主にこのポリシーのためであり、開発者のために構文を拡張することを拒否したため、Perlは除外されました。 すべての利点にもかかわらず。



問題をさらに深く理解するために、PHPの方向を見てみましょう。OOPがまったくないインタープリターとして始まった膨大な数の欠陥があるため、この言語は過去10年間で大きく進歩しました。 名前空間が登場し、Javaに匹敵するレベルでOOPが実装され、クラスが自動ロードされました。 言語に導入された構文糖の量は、平均的なWebスタジオを糖尿病にさらすのに十分です。 同時に、Javascriptはその場で踏みつけました。変更は、言語の前にすでにあった問題には触れませんでした。 OOPの代わりに、プロトタイプOOPは消えず、モジュールのサポートはどこにも現れませんでした。 これらはすべてライブラリに任されていました。



現在、ECMA-6が地平線上に登場し、最終的に言語標準にモジュールが追加されます。 ただし、構文単位としてのモジュールのみです！ 命名法による自動読み込みの問題、および依存関係の管理の問題は、この方法では解決されません。 また、多くの人にとって馴染みのあるOOPサポートが追加されますが、プライベートクラスメンバーはありません。 ただし、標準がリリースされた場合でも、日常業務への導入は1日の業務ではありません。 これらの変更がすでに遅れている可能性は非常に高いので、コミュニティはrequire.jsとその類似物を習慣ではなくむしろ使用するように思われます。 同じことは、1.5エステを使用する自慢のイテレーターとジェネレーターでも起こりました。 ecma-6のサポートは、最新ではないが非常に一般的なブラウザーの多くでは存在しないため、慣れているからです。 しかし、標準には関数を記述するための新しい構文があります！ これは私たちが夢見ていたことではありませんか？



主観的には、Javascript開発の全歴史は、さまざまなブラウザー開発者が標準の毛布をドラッグするようなものです。 IEと以前のバージョンのFirefoxでのgetElementBy *の非互換性は、多くの場合、Mozilla製品の一部として長年にわたって使用されてきたE4Xテクノロジーによって記憶されています。 おそらくもっと多くのそのような例がありましたが、それらは素人として私には知られていません。 しかし、HTML5がすべてのブラウザーで同様に十分にサポートされているわけではないという考えは空中にあります。





さらに読む前に



だから、あなたはJavascriptプログラマです。 そして、おそらく、次のテキストを読んでいる間、あなたは絶えず叫ぶことを望むでしょう。「聖人、しかし最後にあなたが書いている言語を学んでください！ そして、これらはプログラマーですか？！」純粋に正式な、プログラマーは彼が書く言語を知っていなければなりません、これは論理的です。 しかし、事実に取って代わる論理はありません。事実は、プログラマーの大部分が非常にまれにJavascriptを使用するほどです。 頻繁ではありますが、それほど頻繁ではありませんが、舌のすべての熊手にぶつかって、それらを回避する方法を学びます。



優れたプログラマーが常に開発すべきだと、優れたプログラマーのために新しい言語を習得するのは些細なことだと、絶え間なく唾を吐き、叫ぶことができます。 しかし、私に聞かせて！ Web開発業界で代表される言語の中で、Javascriptを学んだプログラマーが自分にとって新しいものを見つけるような言語はほとんどありません。 Javascriptはすべての普及率で表現力が乏しく、その機能は新しくないか、他の言語で広く使用されていません。 プロトタイプ上に構築された同じOOPは、他の言語のMonkey Patchingに疑わしく似ており、何らかの理由でそこで使用されていません。



Javascriptを学ぶ金銭的な動機も非常に疑わしいです。 Mojlociousの大麦、Djangoのこのパイオニア、RoRのルービストのチーム、フレームワークのバンドルを持つPHP開発者の会社、そしてJavaとC＃のプログラマーの小隊-私たち全員が遅れるという事実から私たちにすべてを支払うことはありませんJavascriptの癖。 プロジェクトがJavascriptのクライアント側で私たちの能力に非常に苦しんでいる場合、フロントエンドベンダーは単に雇われます。 またはフロントエンドのチーム。 そして、これは野心ではなく、分業です。 ところで、一般的な慣行です。



この説明が、なぜ多くのプログラマーがJavascriptを使用することを誓うのかを理解するのに十分であることを本当に願っています。 そして、なぜ彼らはそれを徹底的に勉強したくないのか、同時に「彼らが書いた言語を学ぶことができない」価値のないプログラマーではない。 要するに、時として膨大な数の人々が使用する言語は、より少ない問題を引き起こす可能性があります。



さらに、私は健康から健康へとジャンプし、言語としてのJavascriptだけでなく、それに関連するすべての問題に気付くことを誓います。 つまり ブラウザーでのDOM実装の問題、ブラウザー自体の標準化の問題、ライブラリー品質の問題、プログラマーの問題、これらの書き込みライブラリーは、私の意見では、言語自体の問題です。 この言語はクライアント側の開発の事実上の標準であり、私たちは皆、構文仕様の背後にあるものだけでなく、この標準にバンドルされているものから踊らなければなりません。





主なjavascriptの問題はあなたです


この文章を読んだ結果、あなたの背中よりも低いところに意見の相違がある場合、これはあなた自身のことではなく、あなたのオフィスのことでもないことを知っておく必要があります。 あなたは優秀なプログラマであり、才能のある若いチームで働いています。 そして最終的に、私はJavascriptプログラマーと何度も幸運になれなかったかもしれません。 これは、ボディショップやフリーランスでぶらぶらしている場合に起こります。 そして、ここに深刻な企業で働く適度に重要な孤独な割合があります、そしてこれは強くて、大胆で、そして一般的に典型的なJavascriptプログラマーの外観です...



最後のストローとして機能したのは、Javascriptプログラミングコミュニティの優秀な代表者でした。彼らがいなければ、この記事はおそらく生まれなかったでしょう。 しかし、言語自体とそのインフラストラクチャの問題に、統合失調症のわずかな後味を追加するのは彼らです。 もちろん自分自身ではなく、Javascriptに直面している人たちのために。一方では言語の問題に直面し、もう一方ではこの言語に直面した別の銀の弾丸の甘い賞賛に直面しています。 同時に、最後の側には、ロジックに弱点があります。これは、「何かが人気がある場合、それが利点を持っていることを意味します」という形式に従って構築されています。 これは根本的に間違っていますが、自尊心は常により高価なので、ロジックは省略できます。 自尊心を侵害する勇気があるすべての人のように。



何よりも、Javascriptチャームは通常、専門的な開発期間を経てフロントエンド開発者から聞いています。 フロントエンドでの言語の問題の非難については、特に負荷の高いアプリケーションを作成する分野で、バックエンドでの言語の利点に訴えることが非常に好きです。 興味深い事実は、このカテゴリのプログラマーがそのようなアプリケーションを書くのは1つの場合だけであるということです。この地域で平均以上の給与で購入した薬物の使用によって引き起こされる幻覚性せん妄では、省略されます。 そして、おそらく、ポイントは若いプログラマーでさえありませんが、自尊心を傷つけ、想像を絶する割合に膨らませる給与（多くの場合、プログラマの両親の合計給与を超える）にあります。



プログラマーは人間ではないという信念に反して、プログラマーの中の多くの人々が社会を支配するアイデアを結びつけることも一般的です。 第一に、彼らは理解して踏みつけることができず、第二に、あなたは他の人を理解して踏みつけることができないからです。 3番目と4番目の数字に続いて、大きな感覚と肘の感覚が関与します。 しかし、議論の間、原則として、2番目のポイントのみがポップアップします。 そして、Javascriptプログラマーの大群（もちろん、親愛なる読者を除く）は、30年前に名前が変更されたテクノロジーに対する熱意を共有していないので、退化したオイルのランクに昇格する準備ができています。 彼らは、舌の利点であなたを顔に突っ込み、言及された欠点のために同じ人に吐き出し、この機能が必要ではないことを賢明な顔で同じ顔で言います（はい、これは古き良きLORは「不要」です）、そしてこれ別の方法で行うことができます。 もちろんできます！ 古代から、人類はその創意工夫と適応性で有名であり、人類の誇り高い代表者は、やがて石を未配達のハンマーで置き換えるでしょう。 そして、最も創意に富んだ人は、石がなければ、頭で釘を打つことができます。 Javascriptには、他の言語では利用できないかけがえのない機能があると、これらの人々が心から信じていることに驚いています。 Python、Perl、RubyにはないJavascriptで良いものを見つけようとする私の試みは何度も失敗します。



もちろん、Javascriptプログラマーの中には、他の言語でコードを書いた長年の経験の後にJavascriptに切り替えた人がいます。 そして基本的に、彼らはこの言語を前進させます。 しかし、さまざまなブラウザをハッキングすることでそれほど洗練されていなかった昨日のコーダーの大群と比較した割合のわずかな割合（コーダーを心から愛していますが、結果は常に見えており、結果の要件はしばしば技術的に不可能です） ） Javascriptは、最初のJSスクリプトの後にアヒルの子の症候群を抑制するために、無駄にしようとしている（そして、彼らがしようとしているのですか？）面白い群衆でいっぱいです。 また、何百人もの落ち込んでいる学生が住んでいます（残りの数千人はJavaのbeatられた道を外れました）。彼らは必死に理解しようとしています。 また、お気に入りのスニペットを5年以上慎重に保管し、10年間専門家としての自尊心を蓄積したフリーランサーは、単に自分のヒントやベストプラクティスを共有できないようにしていますか？ そして、排他的にコンパイルされたプログラミング言語の支持者の尽きることのない流れをどうするか。人々ではなく、インタプリタ言語で書くすべての人々をひそかに数えます。 しかし、ニュースの圧力に屈して、彼らはJSに一目を投じることに決めました（多くの場合、長期にわたる失業のため）、そして彼らはそれに固執します。



JavaScriptの多さの最も顕著な代表者の中で、同じ言語の人気リポジトリのgithubが豊富なキャリアリストに注目することができます。 タイプミスの修正とドキュメントの作成に限定されるコミット。 このカテゴリのプログラマーが、閉鎖とラムダの違いを投機的に議論し、編みフェンスに影を落とす能力は、最初の独立プロジェクトで液体を得る能力としか比較できません。 Javascriptの功績として、Python、Rubyの離陸中にこのような脱走者が多かったと言わざるを得ませんが、Webアプリケーションの需要は長い間成長し続けており、同じレベルの他の誇大広告はまだ予想されていないため、ここでは長い間座ります。



Javascriptプログラマーのプロ意識レベルの分布の全体像は、苦しんでいる土地の6分の1の人口の所得レベルの分布の像と痛烈に似ています。 私たちは、誰もが口の中を見るが、結果を繰り返すことのできない堅実で取るに足らない割合のスーパースターを持っています。 また、結果を繰り返すことができないすべての人々がいます。 プログラマーとレイアウトデザイナーの職業を隔てるエネルギー障壁をあちこちに浮かんでいる人の数は、単に計算できません。



そして、低い資格と巨大な要求が掛け合わされた膨大な数の人々は、フロントエンドのバックエンドに沿って高い偏見の自尊心、過激な無知、またはイティリズムを引き起こします。 さらに、これらすべてがJavascript自体のミニマリズムに重なっており、その結果、多くの基本的なことを新しい方法で実装する必要があります。 ここでは、このためにライブラリを選択するか、他の何かを作成するかは関係ありません。 たとえば、クラスの宣言には表記法の方が適切な競合がチーム内で発生します。 もちろん、OOPを実装するためのライブラリの選択をめぐる競合に進むことで、この競合を回避できます。 ほぼ同じことを実行し、味覚エラーの数分の1だけ異なる多くのライブラリを選択することも簡単ではありません。誰もが自分の何かを押し出したいと思っています。 自分自身や他のすべての人に、彼の意見がチームで考慮されていることを証明するためだけに時々。 いや、いや、これはどの言語のプログラマーのチームでも構いません。Javascriptが今日の現実にこのような衝突のもう少しの機会を与えてくれます。 さて、若者や熱狂的な人々の階級における健全な懐疑主義はまだ形成されていないことが多いため、図書館はプロジェクトに大胆に導入され、その未来は疑わしく、質は疑いの余地がありません（しかし、悲しい笑顔を引き起こす可能性があります） そして、プログラマー自身は依然として懐疑論と同じくらい弱く形成されていることが多いので、同じことをする異なるライブラリーがプロジェクトに追加される場合があります。 死んでいるライブラリは1つだけで、ライブラリ上のページのようにライブラリに触れないことを好み、2つ目のライブラリは新しく作成したページに接続できます。



低い資格は基準の無知につながり、高い自尊心は彼らの無知につながります。 これらの要因の両方が一緒になって、主観的に最高の新しい標準の出現につながります。 社内で動作する標準コードは優れており、過度に熱狂的でなければ、一般的に素晴らしいです。 しかし、これはすべて、標準コードが統一の手段のみを参照しており、世界をより良い場所にする方法ではない限り、良いことです。 しかし、コード標準でそのような方法を見るのは簡単な作業ではありません。ここでは、25歳以上の18歳の洞察が必要です。 そして彼らは見るでしょう。 単一の正しい意見が存在しない問題ほど競争力のある論争の根拠はありません。つまり、CWSの戦いがすべてを決定するということです。 Javascriptプログラマーの環境には、このFAQが十分にありますか。今日、ほとんどの場合、若者と非妥協性によって区別されていますか？



次の役に立たないサイトの完璧なコードを求めて相容れない戦闘機は、原則として言語と仕事を気にせず、自分たちの生活に興味があり、完璧なコードと最高の技術の名の別の十字軍ではない多くのプログラマーによって相殺されます。 多くの場合、これらは（特別な）教育を受けていない人ですが、すぐに学んでお金を稼ぐためにオフィスで働く機会を失っています。 彼らはできる限り自分の仕事をしますが、完璧なコードを書きたいからではなく、うまく仕事をしたいからです。 これらのチームで作業するのは楽しいことです。ベクトルを設定するチームリーダーがいる場合、作業はスキャンダルなしで時間通りに実行されます。 皆さんありがとうございます



しかし、Javascriptが私たちの子供たちが話す言語であると心から信じているプログラマーの一人が現れると、すべてが崩壊し、そのコードは心の底から来るはずです。 そして、魂が子供の涙のように純粋なコードを生むことができない人、最初の言葉が「var」という言葉だった人、完全に浄化されるまで魂を吐き出す必要がある人のために 自家製のJavascriptの達人がやっていること、そのような凡midさの真っfrom中にいることから自己犠牲を心から楽しみ、この環境を完全に心から広めます。もちろん、そのような支持者によるJavascriptの使用開始時の世界平和の始まりは宣言されていませんが、暗示されています。彼らはまた、この言語で見つかったすべての欠陥はその利点の継続にすぎないことを暗示しており、誰かがこれに同意しない場合、これは強制ではありません。ネオシレーターのせいにできる唯一のことは、信仰の欠如です。神はあなたのチームをそのようなものから救います。さて、または彼を一人にしてみましょう、しかし彼はチームリーダーになります。



残念ながら、これらの同じ人々はあなたがJavascriptを好きではない方法を心から理解していませんが、彼らに利用可能な引数のうち2つしかリストできません-彼らの言語に対する主観的な愛とその高い人気は間違いなく言語の利点を決定しますが、それは否定できません（最初の引数を参照してください）。優秀さを追求することとNWFの間の境界線は非常に狭く、職場での対立は避けられないため、彼らと協力することは困難です。タスクにJavascriptを使用するというアドバイスは、セールスマンとの会話の永続的な幻想を作り出すことができます。 Javascriptの欠陥についての議論はあまり楽しいものではありません。



通常、言語の人気のピークが過ぎた後、本当に調和の取れた仕事をする人と、そのすべての欠陥は無視できます。まあ、または再訓練するのが面倒な人。これらの人々との会話では、言語の欠陥に安全に言及することができます-反応は適切であるか、完全に欠如しています。 JS-fanboysの場合、不快な些細なことを訴えることさえ、彼らの方向への攻撃に満ちています。



コミュニケーションの問題を捨てたとしても、完璧主義と設計上多くの欠陥がある言語で何かを本当にうまくやろうとする欲求は、何も良いことにつながりません。そして、言語とその言語のプログラマーの大半と戦うための時間の損失は非生産的です。



このすべてのために、Javascriptがもたらすこれらの良いアイデアでさえ、キャリアの私たちの認識によってばらばらになります。これは、プロレタリアートの性的マイノリティの手による善に対する認識に似ています。このような下品な方法で伝えられたこれらのアイデアを受け入れ、受け入れないでください。そして、私は彼らの同僚がPHPで書いているJavascriptプログラマーの例を設定したいと思います。最初の仕事とは異なり、自分の仕事をする人、自分の言語の短所を知っている人、および自分の長所についてJavascriptで書く人。いつかJavascriptをめぐる誇大広告は沈静化し、今日の過激派プログラマーは次の流行の新しい最高の言語を成熟または非難するでしょう。





純粋に形式的な欠陥



おそらくすべての言語には奇妙な型キャストがあります。むしろ、言語ごとに合成表現の例を選択し、「著者は何を吸ったのか」という質問の結果を見て、最初に出てきて、その後、思慮深い分析の後、どれくらい吸ったのか疑問に思う。まあ、これはほとんどすべての言語で避けられない悪であるため、主なことは、この悪が多すぎないこと、または悪の構築物が言語の後ろに隠れて、日常のコードにめったに捕まらないことです。しかし、Javascriptでは、こうした汚いトリックがすべて出てきます。毎日。



空の配列やオブジェクトを持つ配列の合計を真剣に扱う人はいないため、すべてをリストするべきではありませんが、多くの、うらやましい規則性を妨げるものについて言及する必要があります。一般に、このセクションはショー用に追加されました（また、最も永続的なJavascriptアドヒアランス（これは最も永続的なものではありません））。スニペットを作成し、チートシートを作成し、最終的にレーキに飛び込んでサブコーテックスに進むことができますこれらの問題を回避する方法。





ヌル、比較演算子、すべて、すべて、すべて


Javascriptが誇張するすべての控えめな厳密さとミニマリズムに対して、Pythonの厳密さとロジックのレベルに達することはなく、ほぼ同じレベルのミニマリズムがあります。なぜ、例えば、教科書のそのような多数の異なるアナログ値が偽であるのか？計算式での偽の解釈は本当に頭痛の種です-今回は言語自体に「空の」値をキャストする問題があります。第二に、言語またはブラウザに組み込まれたオブジェクトとの対話に費やされる時間の大部分は、それぞれが返すものを覚えているだけです。第三に、未知の人々によって書かれたライブラリもあります。



空の値とは何ですか？これは、関数が何も見つからなかった場合、計算が不可能である場合、エラーが発生した場合など、戻り値のすべてのバリアントの集合名です。そのような用語がないという事実にもかかわらず、このイディオムはすべての言語のすべてのプログラマーによって普遍的に使用されます。そして、これはJavascriptのcさです。なぜなら、それはそのような値に対していくつかのオプションを提供するからです。いつfalse、null、未定義を返すかを常に知っていれば、本当に幸せになれます。知らないが、失望しない人々のために一緒に喜び、あなたと私が使用しなければならないかもしれないライブラリを書きましょう。



多くは、ライブラリの作成者が行ったことに依存します。多くのライブラリがあり、品質は異なりますが、常に論理的に動作するとは限らない標準オブジェクトもあります。サードパーティのライブラリはJavascript自体と何の関係がありますか？コードをブラウザから独立して動作させるために、jQueryのような松葉杖を使用する方が簡単な場合があることを忘れても、何もありません。



典型的なサードパーティ関数は、そのロジックに応じて、次の「空の」値のいずれかを返します。 



  false      // -  false
  undefined  //  ,    
  null       //        null
  NaN        //       1 / 0
  {}         //   NULL,   ,      " "  
  []         //  ,      
  Object     //    ,




     図書館の問題については上で述べたが、遠くに行く必要はない。入力に間違った日付を渡すと、標準のDateオブジェクトは何を生成すると思いますか？間違い？ヌル？いいえ-オブジェクト。 



    var d = new Date("2012--12-01"); //     

    d.toJSON();       // null
    d.getTime();      // NaN
    d.toString();     //'Invalid Date'
    d.toISOString()   // -  !




     上記では多くの人がJavascriptを書いていると言われているので、Cライターが次のような同じ関数を書くことは珍しくありません。 



  function isEven(arg) {
    if (arg % 2 == 0)
      return 1;
    else
      return 0;
  }




     Perlの恋人は配る 



  function isEven(arg) {
    if (arg % 2 == 0)
      return 1;
    else
      return undefined;
  }




     PHPプログラマーは以下を生成できます。 



  function isEven(arg) {
    if (arg % 2 == 0)
      return 1;
    else
      return null;
  }




     ただし、そのような呼び出しが発生した場合、最初のオプションのみが正しく機能します。 



if (isEven(3) == false) {
    alert(",  !");
}




     そして、問題は、Javascriptの真理値表の平凡な記憶にとどまりません。現時点では、やや深刻なサイトには、ExtJSのような巨大なものから、そのプロジェクトの残りとスクリプトが最後に更新された日付で判断した人のgithubで見つけた小さなスクリプトに至るまで、さまざまなライブラリがありますJavascriptは、長い間、めったに書かれておらず、最初と最後の場合がほとんどです。



     しかし、空の値の処理に戻ります。ファッションに敬意を表して、nodejsにサイトを書いているとしましょう。そして、私たちはそれに登録を行うことにしました。セキュリティを重視しているため、パスワードは少なくとも8文字の長さにし、さまざまなケースの文字や数字を使用できるようにします。 C Javascriptは単純です。正規表現が言語に組み込まれているためです。 



  /^[a-zA-Z0-9]{8,}$/.test('passworD1'); //




     ここで、リクエストのどこかから、またはクライアントサイトについて話している場合は、何らかの入力からパスワードが送られてくると想像してみましょう。そして、タイプミスや混乱の結果として、パスワード変数に何か間違ったことを入れていることがわかりました。 



  var request = {
    "user"     : "alex",
    "password" : "sdjk23h78dg2"
  };

  // , 
  if ( /^[a-zA-Z0-9]{8,}$/.test(request["pasword"]) ) {
    save_user_to_database(request);
  }




     そしてそれは特徴的であり、ユーザーは保存されます。空のパスワード、またはもしあれば塩のみ。これはすべて、Javascript機能のおかげです。 



  /^[a-z]{1,10}$/.test(null);      // true 
  /^[a-z]{1,10}$/.test(undefined); // true






行と数字


     多くのコピーがこのトピックで壊れています。通訳者が行と数字を追加しようとすると誰かが手を打つこと（そしておそらくこれがおそらく最も正しい振る舞い）で、誰かが通訳者に行を数字として解釈することを望みます。あなたが認めなければならないのは、より高いレベルで変数がバリデーターをすでに通過しており、文字列表現ではあるがまだ数値が残っていることを知っている場合に便利です。



     さまざまな言語の文字列でこのような数値の解釈がどのように発生するかを見てみましょう。





Php 34 32
Python 間違い 間違い
Perl 34 32
ルビー 間違い 間違い
Javascript 「331」 32

parseIntとparseFloatはあなたの親友です。数よりも優れていますが... 



  //  , ,   ,   , ?
  parseInt(null, 24) === 23 // true






複数の引数


     ポップ、シフト、またはそこで使用するものを介して引数リストのリストを調べることで、真珠とpythonの習慣を忘れてください。 



  function lastNegative() {
    var negative = null;

    while ( arguments.length ) {
      negative = arguments.pop(); // 
      if (negative < 0)
        break;
    }

    return negative;
  }




     ローカル変数引数は、名前のない関数引数の配列ですが、完全なJavascript配列ではありません。通常の方法で作業するには、何らかの方法でそれをArrayクラスの通常の配列に変換する必要があります。これに使用される最も一般的なスニペットには、この形式があります。 



  var args = Array.prototype.slice.call(arguments);






配列


     返された配列の型と構造を常に慎重に確認する必要があります。そうしないと、数時間のデバッグの後、次のことに気付くことがあります。 



[]     == true // false -  ,    
[1]    == true // true  - ,   -   ,     true
[2]    == true // false -  ,    ,    true... 
[true] == true // false -      ,  true != true

//       ?
[1 , 1]  == true // false ...

//    ?
[ [1], [1] ]    == true // false
[ [ [ [1] ] ] ] == true // true

//  !
new Array()    == true // false 
new Array(1)   == true // false 
new Array(1,2) == true // false




     確かにJavascriptの専門家はこのすべてについて説明していますが、問題は解決しません。唯一の慰めは、Googleを持たないすべての言語の第一人者がその理由を説明できないということです。 



  new Array([],null,undefined,null) == ",,,"; // true




     これらの誤解はすべていくつかの法律に従い、仕様書に記載されていますが、それらは直感に反するものであり、文書化のためにそれらに入ろうとは思わないような基本的なことに関するものです。





書式設定


     Javascriptを使用すると設定できません。各行の最後に、フォーマットに応じて異なる値を返す関数を作成できます。 



  function foo() {
    return "  ,       ,    ";
  }
 
function bar() {
  return 
    "  ,       ,    ";
}

foo(); //  
bar(); //  undefined






Foreachステートメント


     解釈されたプログラミング言語は悪いです。これは数学へのサービスが最も少ないですが、同時に配列があり、foreach演算子を使用しません。つまり 演算子はそのままのように見えますが、他のすべての言語とは異なり、この演算子は反復をサポートし、配列の値に従ってではなく、キーに従って発生します。これは、Web開発の平日に対処する必要がほとんどない特定のクラスのアルゴリズムでは実際に非常に便利です。 



for (index in ARRR) {
    var value = obj[index];
    console.log(value); 
}




     そして、誰かが祖父の方法を使うのが好きです： 



for (var index = 0; index < a.length; ++index) {     
    console.log(a[index]); 
}




     リング神をなだめたい人のために、バリアントがあります： 



a.forEach(function(entry) {
    console.log(entry);
});




     私はそのようなサイクルのために自分のスニペットを持っています、そしてあなたは？言語に3つの方法がある場合（自尊心のあるライブラリごとに独自のforeachをカウントしない場合）、同じことを行うことが基本的なことであり、各メソッドに何か不足していることはありますか？見つけられませんか？そして、それはあなたがJavascriptで書くからです。しかし、CoffeeScriptとDartがリストの値に対する繰り返しをまだサポートしている理由を考えてください。 



# dart
for (var x in collection) {   
    print(x); 
}

# coffeescript
for x in collection
    print(x)






そして、それだけではありません


     さらに多くのJavascript機能をご覧になりたい場合は、wtfjs.comへようこそ。戻ってきてください。





全体の一部としてのJavascript



誇大広告


     そして、誰もがWebアプリケーションを必要とし、本当の代替手段がないため、この誇大広告は長くなります。DartやCoffeeScriptのような利点のある代替品には、クライアント側のプログラミングの分野での業界のニーズを満たすプログラマーのプールがないためです。それに加えて、どこにも行かないレガシーコードがたくさんあります。



     Javascriptが構文解析の結果である各穴に詰め込もうとしているという事実によって、同様の害が引き起こされており、この詰め込みは言語をさらに促進しています。すべてのプログラマーが、仮想マシンまたはJavascriptコーデックが楽しいプロトタイプであると信じているわけではなく、言語の適用性を実際に示すものではありません。そして、このデモンストレーションはまったく止まりません、そして、新しい同様のプロジェクトは、牛の墓地からの奇跡のように登ります。





ツールキット


     低レベルのプログラマーは、ほとんどの作業ツールがブラウザーとファイアバグであるという事実につながります。また、これはJavascriptの問題でもあります。すべてのツールにはnodeJSが必要です。これは基本的に論理的です。ただし、unixシステム上でもnodeJSのインストールは頭痛の種になる場合があります（どうしても必要な場合を除き、VPSテンプレートを更新しないことを好むホスティング業者のおかげで大きな役割を果たしています）。 Windowsでは、ここ数年で状況が劇的に改善され、Cygwinをインストールしなくてもノードとnpmをインストールできます。ただし、Windowsで残りの拡張機能をインストールすることは地雷原であり、Cygwinが正しく構成されていても爆発する可能性があります。したがって、フロントエンドベンダーの大部分は、Javascriptの現在の進歩を無視し、不必要な頭痛から身を守ります。



     一般に、インターネット上の声明のトーンからわかるように、多くのjavascriptはノードを構成し、プロジェクトに必要なすべてのモジュールをインストールできません。各従業員がすべてを新しい方法で構成せず、不必要なルーチンに時間を無駄にしないように、作業環境で仮想マシンのイメージを発行することは、多くの企業で通常行われています。しかし問題は、PHPプログラマーはもちろん、同じ栄養士と野and人の間で、重い作業環境を展開できる人の相対的な割合が、Javascriptプログラマーの同じ割合よりもかなり高いことです。そして、ツールの方が優れている可能性があるという意見がある割合の中でも。



     ツールの品質の劇的な改善が近い将来に期待されることはほとんどありません。Googleは、V8エンジンの開発のために行われたようなJavascriptインフラストラクチャへのリソースの注入を行うことに興味がありません。コミュニティは、既存の車輪に車輪を取り付けるよりも自分の自転車を見ることを好むので、nodejs + npmのバンドルをCPANレベルにすることができれば、すぐにはありません。





非同期性


     非同期性がコードを高速化するとプログラマが信じる場合、彼は非常に特定のアルゴリズムを扱う専門家であるか、それが何であるかをよく理解していません。または彼は常識を犠牲にして正式な正当性の支持者です。Web、特に中規模および中規模のプロジェクトでは、並列化するものはほとんどありません。また、大規模なプロジェクトは、大量のリクエストやコンテンツのcなキャッシングにすでに根付いています。まあ、すべての種類のスレッドがあります...



     これは、データ処理への非同期アプローチが原則的に無意味であると言うことではありません。ある種の重い分析、相互に関係のない多くのパラメーターで動作するレポートの生成の場合、コールバックを使用するとパフォーマンスが大幅に向上します。ストリームおよびストリーム間でデータを共有する複雑さなし。これは本当に素晴らしいです。それで問題は何ですか？はい、そのような勝利の状況の数が非常に少ないという事実。



     ある種のビジネスロジックをプログラミングするとき、アルゴリズムを作成します。「アルゴリズム」という言葉の定義は、「有限数のアクションで問題を解決した結果を達成するための実行者のアクションの順序を記述する命令のセット」です。ご注文ください！データは特定の順序で処理する必要があります！たとえば、アルゴリズムの入力パラメーターが統計の計算が必要な商品のカテゴリの名前である場合、特定の商品のすべての買い手をオンラインストアのデータベースから取得することはできません。最初に名前でカテゴリを取得し、次にこのカテゴリの製品を取得してから、バイヤーのリストを取得する必要があります。この例では、これを3つのコールバックで連続してラップすることで、パフォーマンスがゼロになり、コードが読みにくくなることを大幅に改善できます。別の記事では、このような非同期アセンブリアルゴリズムでのエラー処理、特に、ページの表示がどのコールバックに該当するかによって異なります。



     オンラインストアの例は単純ですが、Webの95％はこの単純さで構成されています。とにかく、複雑なビジネスロジックでリングチェーンがほどけるのをどのように想像しますか？すでに、多くの場合、競合する要件を満たすために長年にわたってシステムに投入された抽象化のヒープを理解するのに問題があります。 IDEがこのロジックでコールグラフを構築できるかどうかもわかりません。実行順序は実行時にのみ表示されます。もちろん、非同期に起動されたハンドラーに沿って分散することにより、データ処理を並列化することが可能であり、必要な場合があります。そして、これらの場所はほとんどありません。ノード愛好家よりもずっと少ないようです。ただし、このような非同期コードのサポートに関連するオーバーヘッドは非常に大きくなります。



     ちなみに、このアプローチは懐疑的に懐古的なスレッドを連想させます。これは、PHPでない場合、web 1.0の時代にPerlとPythonですでに利用可能でした。そして、今、それらが積極的に使用されているとは言えません。はい、PythonのスレッドはGILによる低速化で有名ですが、nodejs自体は現在のプロセス内の1つのプロセッサコアに制限されていませんか？はい、スレッドを作成するための構文はコールバックほど簡潔ではない場合がありますが、後者はまた、特にネストの第2レベルから始まる読みやすさを改善しません。また、すべてのI / Oは非同期であるため、第2レベルのネストがあります。



     何らかの理由で、1つのプロセス内の同時実行性がWeb開発で広く定着していません。スレッド作成のオーバーヘッド？ただし、Webページを生成するために作成されるスレッドの数は（コールバックとの類推により）少数です。そして、コールバックがスレッドよりも桁違いに速いと仮定した場合でも、最初のアルゴリズムを考慮してアルゴリズムを書き直すことは、多くの場合、一致の節約であり、同時にコードによって結果のアルゴリズムを不快に「塗りつぶし」ます。それは特徴的で、多くの人には向いていませんが、松葉杖を 書く からです 非同期プログラミングの機能と戦うため。ノードが発行できる非同期性は、非常に非常に特殊なものです。それは、公平な処置の間に患者をトリックで楽しませ、魔術師のスキルが医学教育の彼のギャップを埋めることができると考える肛門科医イリュージョニストのようなものです。



     スレッドとコールバックの比較は形式上正しくありませんが、実用的な観点からは、両方のテクノロジーを積極的に使用して、I / O操作の終了を待つ時間を何らかの方法で削減しています。私はこれを言うのを恥ずかしく思いますが、サーバー側でプログラミングするときの問題を解決するという点で、2つのテクノロジーの違いは実際にはわかりません。



     最初は、Javascriptの非同期はそのスコープの結果でした-ユーザーインターフェイスの非ブロッキングハンドラー。重い計算アルゴリズムはありません。この非同期モデルの意味は、速度を上げることではなく、イベントまたはサーバーからの読み込みの完了を待っている間にスクリプトがブラウザーをブロックするのを防ぐことでした。主にI / Oを保存する必要があると述べているnodejsの哲学は、Javascript自体の出現から約10年後に現れましたが、並列処理のスレッドモデルがJavascriptインタープリターアーキテクチャのフレームワーク内で実装されたため、コールバックに重点が置かれた疑いがあります不可能でしょう。しかし、コールバックは言語で行われました。したがって、ノードの非同期は上からの贈り物ではなく、1つの大きな妥協です。すべてが本当に悪くないように。



     このように、ブラウザー内のすべてのjavascriptが自慢している非同期性は、通常のイベントループであり、多数のグラフィックツールキットに実装されていることがわかります。また、サーバー上では、このイベントループをサーバーに移植することによって引き起こされる問題の結果です。そして、この非同期プログラミングがいかにクールで有用であるかについてのすべての美しいスピーチを詳しく調べてみると、腐ったコルベチーの腸が常に現れます。





松葉杖で一生


     Javascriptを中心に展開するテクノロジースタック全体は、UNIXイデオロギーのパロディに疑わしく似ています。可能な限りひどく仕事をし、時には相互に重複している小さなプログラムの束です。いくつかの素晴らしいブラウザがありますが、それぞれが独自の方法で優れています-いくつかは遅くなり、いくつかはリダイレクトのサポートを拒否します： 



location.href = 'http://habrahabr.ru/';




     そして、それらのいくつかには、いくつかの異なる非常に広く使用されているバージョンがあり、残りの凡例とは互換性がありません。もちろん、これらのブラウザはすべて異なりますHTML5のサポートの度合い、Flashの欠陥を修正し、それらを欠陥で置き換えるように設計されたこのコンポーネントのコレクション。このすべての動物園の速度は、すべてのブラウザーでサポートされている機能のサブセットのみを使用する場合でも、FirefoxまたはIEユーザーがスライドショーを楽しんでいる間、Chromeユーザーはコンピューターからすべてのジュースを絞り込み、単純なピクセルアーケードを通過するようなばらつきをもたらします、80年代および90年代のゲーム機で非常に一般的なもののように。かつてIE専用にカスタマイズされたサイトがあったため、Chrome専用サイトの世代はさらに成長しているように思えます。または、シャープ化されていませんが、1つのブラウザーでのみ正常に機能する程度に見落とされています。



     Javascriptにはノードの自慢の速度があるという私の意見で唯一の良いことです-そしてこれは、Vasinサイトがすべての湾曲したスクリプトでチャレンジしたときにブラウザーが遅くならないようにするための数千人の死にかかった時間の結果です。さて、あるいは少なくとも、Twitterが次のタブで機能したときにそれほど遅くはなりませんでした。これは、Webアプリケーションをより良くするための必死の試みです。そして、この試みは1つではありませんでした。asm.jsは、Javascriptのパフォーマンスを向上させるための戦略の1つでもありました。



     HTML5の問題の説明は、この記事の範囲をはるかに超えており、別の記事に値するものです。 HTML5で何か重いものを作成しようとした人、またはこの技術を使用してモバイルプラットフォーム用のゲームを使用して作成した人によって書かれることを願っています。多数の疎結合コンポーネントの存在、異なるゲーム作成テクニック、異なるJavascriptプログラミングへのアプローチ、一連のコンポーネントではなくグラフィックスに焦点を合わせたHTML5テクノロジーの欠如、すべてのHTML5バナー、ゲーム、アプリケーション、程度の異なるイベントループブラウザーのサポート、さまざまなブラウザー速度-これらはすべて、Flashに対するHTML5 + Javascriptテクノロジーの利点に疑問を投げかけています。そして、ゲームの品質の観点から、そしてそれらの開発の利便性の観点から。プロのIDEでさえ、HTML5ゲーム開発者に向けて大きな一歩を踏み出す必要があります。





すべてがそこにあるかのように


     Javascriptで最も迷惑なのは、JavaやPythonのような本格的な言語があるという錯覚です。紙にはすべてがあります-言語に組み込まれている正規表現、OOP実装、代替手段ではありますが、言語の支持者は繰り返すのが好きです。そして、非同期性があります-すべての耳が鳴り響きますが、実際には、これはすべて松葉杖での苦痛と威勢のいいダンスでの無限の歩行に変換されます。



     言語自体の言葉に到達する場所はほとんどありません。テクノロジースタック全体に占める割合は非常に小さいです。同じDOMがブラウザに残され、すべての入力/出力がライブラリに与えられ、モジュールとOOPの人間によるサポートが実装されます。そして、どこを見ても、どのアプリケーションの領域を見ていなくても、熱心なJSバトルのささやきがすぐに聞こえます。ライブラリを使用して非標準または特殊な機能を使用する場合-これは正常であり、ライブラリを使用して汎用言語を拡張する場合もこれは正常です-Boost for C ++は素晴らしい例です（その怪物を考慮しない場合）ライブラリを機能を拡張せずに高度に専門化された言語に使用し、その欠点を単純に隠すと、私たちは考えます。



     同じjQueryを使用すると、そのアプリケーションは非常に幅広いため、Google CDNの他のライブラリの中で、ダウンロードの割合は89％です。私と私の馴染みのあるすべてのプログラマーは、以前のバージョンのブラウザーでDOMを操作する機能に既に遭遇しているという理由でjQueryを使用しています。今ではすべてが確かに良くなっていますが、害の方法から私たちはまだそれを使用しています。 Javascriptには、ノードの最大の機能であると思われる非同期性を克服するためのライブラリがたくさんありますが、コミュニティでは、最終的には自分の目的に合った独自のライブラリを作成するという意見があります。でも、 中に 私たち が存在する 無数 の数 の異なる ローダーは、。 Javascriptにはモジュールがないことを強調するAMD表記法とともに、それらのすべてが、モジュールが必要であることを明確に示唆していますが、そうではありません。したがって、全員が独自の実装を作成します。必要なことのように思えますが、少なくともこれを待つことはありません。 



  window.addLibraryPath("/js/vendor");
  var $ = window.loadLibrary("JQuery");
  window.loadLibrary("DataTables");




     通常の順序でモジュールをロードできない非同期性（require（["/ a / ab / ac"、 "b / ad / vr"]）;が好きな人にはうれしいです。） requirejsとAMDがモジュールを実装するための事実上の標準になったとしても、膨大な数のライブラリがそれで動作することはできず、ラッパーを作成する必要があるため、すべてのブラウザーにゆっくりと異なる方法で到達する言語自体。そして、モジュールが言語を学習する瞬間に学習しなくても、プログラマーが大規模なアプリケーションに成長する数か月後、あるいは数年後にさえ、これは自然な問題です。そして、それはある程度成長し、すでにモジュールがどのように見えるかについての独自の確立された要件を持っています。npm



     リポジトリを確認する、Javascript用の非常に多くのライブラリがあると思うかもしれません。はい、いいえ-それらはたくさんありますが、品質、バグの存在、異なるプラットフォームのアセンブリの問題により、あなたは再び考えさせられます。開発されたプロジェクトでは、必然的にこれらの問題が発生します。人気の上昇中の言語のリポジトリ（Haskellでさえこれを避けることができないように思えます）は、いくつかの大きなゴミです。人気に群がっている膨大な数のプログラマーが、他の1.5人のプログラマーに必要なライブラリーをそこに入れようとしています。誰もが必要とするものは通常、ゆっくりと、いやいやながら書かれ、バグはコミュニティによって何年もの間閉じられます。あなたはそれを感じなければなりません-2005年にCPANから、または2008年にPyPIから次のモジュールのインストール中にあなたの手を振った方法、そして、今日でもWindowsでさえ手間のかからないルーチンになっています。いずれにせよ、ほとんどのモジュール。そして、nodejsがすでにそのような機能を実装しているという発言に対して、話者にひどい平手打ちを与えるのをやめる前に、Javascriptは他の言語と同じように長く進みます。





間違った投影


     最高のものは常に聞かれます。これは人と技術、そしてもちろんそれらをつなぐプロジェクトに当てはまります。インターネットは、nodejsがJavaで書かれた同様のプロジェクトを必要とするよりもはるかに少ない数のサーバーを使用してプロジェクトを実装することを可能にした成功事例でいっぱいです。また、フロントエンドとバックエンドの単一言語としてJavascriptを使用することで、開発者の数が減り、コードの重複も減ったことを読むことができます。



     そのようなスーパースターがあなたに伝えないことは、彼らのプロジェクトが非常に特定のアルゴリズムを必要としたということです。ウェブサイトの90％はJavascriptハンドブックの犬のサイドポケットとして必要ですいいえ、彼らはそれを言うだけですが、物語の残りの背景に対して、この厄介な小さなことは喜びにあふれた「熱望する」プログラマーの脳を過ぎて飛びます。また、この「魅力的な」Web開発者は、コードの量を削減するために支払う必要のある価格と、そのショットのプロジェクトのアーキテクチャが何であるかを知ることはできません。そして奇跡は起こりません。コードを機能させるために必要な環境が増えるほど、コードに費やす労力も増えます。未熟な技術のトラブルシューティングのために密猟された無数の工数について、スーパースターからは決して言われません。問題は非常にばかげているので、それらについて書くのは恥ずべきことです。



     これは記事から見ることができますが、すべての読者が、私たちがある種のほぼユニークな作品プロジェクトについて話していることに気付くわけではありません。能力ではなく、プロジェクトの性質に関する平均。 Backbone、Angular、Knockout、これらすべてはすでに平凡であり、今日利用可能です。しかし、その範囲は何ですか？それで、あなたはそれらを使うことに関してあなたは何個のサイトを見ますか？また、単一ページのWebアプリケーションにすべきサイトはいくつあると思いますか？そして、サーバーアプリケーションをデータベースのAPIに変えて、すべてのロジックをクライアント側に転送する必要があるサイトはいくつありますか？



     そのようなアプリケーションはもちろん存在しますが、通常、広告記事で見られるように動作させるためには、長い時間と大きなチームをなめなければなりません。同時に、コードはそのような松葉杖で大きくなりすぎて、大規模なチームでさえ十分ではなく、大規模なシニアチームが必要になります。同じAngularで何か大きなものを書いた人は誰もが知っていることですが、唯一の質問はそれをどのように認識したかです-マイナーな欠陥として、またはもはや彼に連絡しないことを誓いました。



     そして、小さなウェブはどこにも行っていません。彼はまだ「サイトへのかわいさ」レベルのJavascriptを必要としており、安価で広範囲のホスティングが必要です。また、簡単に見つけられ、nodejsの同様のサイトのPHPで3サイトのコストを強要しない専門家がたくさん必要です。





作業速度


     私はnodejs開発者、またはむしろ、V8エンジン自体を書いた人、そして最も重要なことには、Javascriptが他のスクリプト言語をスピードで有名にすることができたおかげで、V8エンジン自体を舐めた人に帽子を脱ぎます。Javaの速度にも匹敵します。それがデマンドの意味、ブラウザ間の競争の意味です。



     しかし同時に、クライアント側で可能な限り多くの機能を実行しようとするサイトの主観的な速度は落ち込んでいます。これには3つの理由があります。





     そして今、これまでに最速の解釈されたプログラミング言語を持っているので、プログラマはそれが生み出すことができる速度を最大限に活用することができません。また、部分的にこの問題により、FlashをHTML5 + Javascriptで完全に置き換えることができません。 Adobe Flashのすべての穴、Windows以外のシステムでのFlash Playerのすべてのスローダウン、Adobeの頭脳の最近の怠慢、これらすべてにより、JavascriptとHTML5には重要な利点がありません。開発用の統合インフラストラクチャ、およびここで特に重要な単一実行環境-Flash Playerなど。これは、同等の複雑さのゲームでは、JS + HTML5よりもはるかに高い主観的な結果を今日示しています。そして、ベンチマークの背景に対するHTML5ゲームのくだらない速度、フラッシュを鍛冶屋に引き裂く、私にとって最大のパラドックスの一つです。



     一般に、Javascript Webアプリケーションの速度は個別の広範なトピックであり、個別のトピックは個別の記事に値します。それはだ、それ。近い将来、スマートフォンがパフォーマンスの飛躍的な進歩を遂げることは非常に疑わしいです。フル機能のWebアプリケーションがデスクトッププラットフォームとモバイルプラットフォーム用の2つの形式で作成されることは間違いありません。つまり スマートフォンでは、機能からビットを受け取るか、スライドショー機能が組み込まれた携帯用加熱パッドを受け取ります。しかし、ここにもプラスがあります-大胆なクライアント部分の要件の1つとして、RESTを念頭に置いて設計されたサイトはますます増えており、AndroidおよびiOS用のネイティブアプリケーションで大きくなりすぎています。





おわりに



     Javascriptが好きな人は、Javascriptを何でも書き続けます。そして、同様の感情を持っている人は、彼らがこの言語に問題がある唯一の人ではないことを知って喜んでいるでしょう。Webアプリケーションは巨大な業界であり、アプリケーションのサイズが拡大しているという事実により、統一されたバイトコードを備えた仮想マシンがブラウザーに組み込まれ、あらゆる言語のコンパイラーを簡単に作成できるようになることを願っています。そしてその後、歴史的要因を捨てて、業界は最新のWebプログラミングのニーズに最も適した言語を批判的に選択できます。



More articles:


All Articles