今年11月22日、Webインターフェイスを作成するための最小限のライブラリであるRiot.jsがリリースされました 。 作成者がWebサイトのメインページに書いているように、Riot.jsは「シンプルでエレガントなコンポーネントベースのUIライブラリ」です。 そして彼女は本当にシンプルでエレガントです。
私はこの発明の大ファンです。 不必要な論理、規則、原則で私の脳を詰まらせません。 互いに埋め込まれたコンポーネントを作成するための非常にシンプルなAPIを提供し、必要なものを非常に短時間で実装できるようにします。
私にとって、さまざまな人気のあるライブラリのプログラミングとAPIは、常に数学のようなものでした。 すべての数学は何に基づいていますか？ クリーンでシンプルな式に基づいて完成されました。 この科学の存在の間に、人類は短くて明確な表現にさまざまな複雑なアイデアをもたらすことができました。 プログラミングの世界で優れたライブラリとフレームワークが行うこととほぼ同じことです。 これらは、ソフトウェアエンジニアに問題を解決するためのシンプルで簡単なAPIを提供します。 私たちは皆、ブラウザで作業するための短く簡潔な方法でjQueryを知っています 。 または、多くの人々が、砂糖の妥当な部分をグローバルJavaScriptオブジェクトに追加するためのSugar.jsのようなすばらしいライブラリについて知っているとしましょう。 Riot.js-Webテクノロジーの進化における最新のトレンドをすべて考慮に入れた、Webコンポーネントのトピックについてのみまったく同じです。
Pugテンプレートエンジンと合わせて、Riot.jsベースのWebコンポーネントは次のようになります。
login-form .login-title p : .login-form form(method='POST', action='/auth/login') .login-field .login-label label(for='email') E-mail input(type='email' name='email') .login-field .login-label label(for='password') input(type='password' name='password' id='password') .login-button button.senddata(type='primary') .login-links span.link.clickable(onclick="{ openPasswordForm }") ? span.link.clickable(onclick='{ openRegisterForm }') script. /* JS */ var tag = this tag.openRegisterForm = function() { RegisterForm.open() } tag.openPasswordForm = function() { PasswordForm.open() } style. /* */
これは、標準のJSとともにほぼ標準のHTMLですが、コードを独立したコンポーネントに分割し、たとえばReact.jsのように、ロジックとプレゼンテーションを別個の明確なエンティティにカプセル化できます。 Riot.jsの作成を開始するために、Riot.jsの作業について知っておく必要のあるポイントはわずかです。 これは、Angular 2.0のドックではありません（この山のようなドキュメント全体を座って読むことも考えたくありません。どれくらい時間がかかりますか？）。
バージョン3.0には根本的な変更はありませんでした。 ほとんどすべてが以前と同じように機能します。 ライブラリはさらになめらかになり、洗練されました。 多くの小さくて微妙な問題が修正されました。
Riot.jsの問題に関するいくつかの言葉
これらすべては確かに問題ありませんが、このライブラリを使用する際に発生する可能性のある問題について話さないと、あなたと十分に真実ではありません。 好きなことを言ってください。ただし、Riot.jsは競合他社よりも低速です （唯一のことは、バージョン3.0の方が生産性が高く、ライブラリの2番目のブランチがこれらのテストでチェックされるということです。コンポーネント、および近い将来の目標と考えています）。
これはどこで問題を引き起こしますか？ さて、ここで開発しているプロジェクトでは、1つのモジュールのサーバーレンダリングに問題があり、5〜6レベルのコンポーネントネストがあります。 したがって、このモジュールを別の方法で記述することは不可能です。 Digital Oceanのサーバーは、リクエストごとに約20〜30秒間このモジュールをレンダリングしました。 これは多すぎる。 しかし、どういうわけか、この問題を解決するためだけにヘッツナーで専用サーバーを購入したくありませんでした。 その結果、特定のコンポーネントを具体的にReact.jsに書き換えました。その後、このコンポーネントのサーバーレンダリングが5〜10秒で機能し始めました。これは、現時点では既に受け入れ可能なオプションです（サーバーレンダリングは検索ボットのみに使用するため、ユーザーはページを開くまで5〜10秒待機しません。コンテンツはブラウザで表示されるだけです。
同時に、パフォーマンスについてさらに説明する場合、私は長い間Infernoに注目していました。 ライブラリのパフォーマンステーブルをもう一度見てください 。 このライブラリは、実際にバニラJSに基づいたテストと1対1で行きます。 正直に言うと、これは本当に印象的です。 おそらく、それに複雑なインターフェイスを書き込もうとしていますか？ とりわけ、その明らかな利点は、React.jsとAPIのほぼ完全な互換性です。 つまり、Infernoでの作業を開始するために、Reactを既に知っている場合は何も学ぶ必要はありません。
また、サーバー側からクライアントにコンテンツをレンダリングする同形アプリケーションを作成する場合は、Reactコンポーネントを使用することでrenderToStringメソッドを使用してサーバー上でコンテンツをレンダリングできるため、Reactを選択する方が望ましい場合があることにも注意してくださいブラウザは、DOMサーバーによって作成されたDOMサーバーにイベントリスナーのみをアタッチし、ユーザーのブラウザーを追加の負荷から節約します。Riot.jsは現在サポートしていません。サーバー側からコンテンツをレンダリングできますが、 CE同じことは、ブラウザ側でも再レンダリングライブラリになります。
わかったように、Riot.jsは、多数のネストレベルを持つ複雑なコンポーネントでは低速です。 しかし、あなたは認める必要があります、私たちはそれほど頻繁にそのような複雑さのウェブインターフェースを書きませんか？
React.jsでプロジェクトのモジュールを1つ書き直しましたが、Riot.jsはフロントエンドコンポーネントを開発するための優先度の高いライブラリであると考えています。 その理由は、より単純で簡潔な構文を提供するからです。 非常に小さな関数のセットが含まれていますが、同時に必要なだけの数です。 Riot.jsは、複雑な抽象化、規則、制限、その他の鳥の言語で頭を詰まらせません。 私の問題を解決するためのきれいなAPIを提供してくれます。 そして、仕事でもっと必要なものは何ですか？