API構築の基礎を学んだ。QConは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発に力を与える。実務者主導のカンファレンスであるQConは、チーム内のイノベーションに影響を与える技術チームのリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャー向けにデザインされている。Sheehy氏は、人工知能ハイプ時代における責任ある開発者としてのあり方について、洞察に富んだ開会基調講演をした。Grizzanti氏が、「スタッフ・プラス」への道と、それを「科学」というより「芸術」としてとらえ、芸術を創作することとソフトウェアを創作すること、そして組織のダイナミクスに対処することの類似性について語っている。Codeを採用する:確認するべき6つの適性LCNC(ローコード/ノーコード)プラットフォームは、プログラマーだけでなくプログラマーでなくても、最小限のコーディングとワンクリックのデプロイメントで、アプリケーションソフトウェアを開発できるよう設計されている。ドラッグ&ドロップ方式のインターフェースなどを利用することで、開発・デプロイメントプロセスを簡素化し、効率的なアプリケーション開発とデプロイメントを実現する。Kim氏が先頃、Webアプリケーション開発用の新たなJavaScriptライブラリのCrankをリリースしました。generators)を使ってJavaScriptで実装されたコルーチンによって、アプリケーションの動作を宣言的に記述できることです。現在はまだベータ段階であるため、さらなる研究開発が必要ですが、非同期レンダリングが可能になることで、Reactの提供するSuspense機能と同様なユースケースに対処できる可能性があります。props)から返されるイテレータによって、ジェネレータクロージャ内に保持されているプライベートな状態へのアクセスが可能になります。イテレータは、それがイテレートする対象(Crankライブラリ関数)からの指示があれば、いつでもビューの計算と生成を行います。その際に後者は、イテレーション要求の中に更新されたpropを渡します。Crankの非同期イテレータはpromiseを返します。このpromiseに計算結果のビューが格納されており、これによって非同期レンダリング機能が実現するのです。このようにCrankコンポーネントは、特別な構文を必要とせず、自然な形でローカルステートをサポートしています。ジェネレータはマッチするDOM要素がマウントされると起動され、アンマウントされると停止します。catchで行うことができます。Webアプリケーションの構築にJavaScriptジェネレータを活用しているフレームワークは他にもあります。UI、PureScript、Pythonなどは、コンポーネント構築に非同期ジェネレータを使用しています。妥協のない純粋関数型Webフレームワークと称するTurbineは、FRPパラダイムの実装にジェネレータを活用しています。Kim氏から、新たなJavaScriptフレームワークを開発した背景について、特にJavaScriptジェネレータを使用することで得られたメリットを中心に話を聞くことができました。読者に自己紹介をお願いします。私はフリーランスのフロントエンドエンジニアです。2013年のReactのブログ記事に、私のことが紹介されています。オープンソースの非同期イテレータライブラリであるRepeater.jsの作者でもあります。このライブラリは、JavaScriptに欠落している、安全な非同期イテレータを生成するためのコンストラクタを補完するものです。そのために、ユーティリティクラスの"リピータ(repeater)"を開発しました。これはPromiseコンストラクタによく似ていて、コールバックベースのAPIを非同期イテレータに、これまでよりも簡単に変換できるようにします。Query)の使用、バックプレッシャの処理、予測可能性を持ったエラー伝搬など、私がこれまで習得した非同期イテレータの優れた設計プラクティスをたくさん詰め込んでいます。基本的には、非同期イテレータを使用する開発者が成功パターンに入ることのできるように注意深く設計されたAPIです。イベントハンドラを常にクリーンアップし、ボトルネックやデッドロックを短時間に発見できるようにします。確かに、新しいJavaScriptフレームワークは毎週のようにリリースされています。Crankを紹介するブログ記事の冒頭でも、さらに新しいものを作ることについてお詫びを書いたくらいです。APIには不満でしたが、それでもReactによって普及したJSXや要素駄文アルゴリズムを使いたかったからです。5年程の間Reactを満足して使っていたので、我慢できなくなって自分自身でフレームワークを書くまでには、本当に長い時間が掛かりました。そもそもの始まりはフックだったと思います。コンポーネントに状態を持たせることによってコンポーネントの関数構文をより使いやすいものにする、という作業にReactチームが投資してくれたことは、私にとってとてもうれしいことでしたが、その"フックのルール"については懸念がありました。名称がuseで始まる関数をそれ専用にするというのは他のフレームワークに対して不公平ですし、簡単に回避できたはずだ、と思ったからです。その後、実際の開発でフックを習得し始めるようになって、letやconstの発明以来、JavaScriptではお目に掛からなかったような古いクロージャのバグが見えるようになると、はたしてフックが最良のアプローチなのか、という疑問を持つようになりました。私にとって本当の転換点はSuspenseプロジェクトでした。Suspenseを試し始めたのはこの頃でした。私が書いた非同期イテレータフックを同期のように使えるようになる、と思ったからです。実際にSuspenseを使用することはできないのではないか、とすぐに気付きました。Suspenseにはキャッシュに対して厳しい要件があり、私がフックで使用している非同期イテレータのキャッシュや再利用を行う方法が明確ではなかったからです。Reactの世界にありながら、Suspenseと非同期データ取得にキャッシュが必要だという事実は、それまでReactコンポーネントのasync/awaitのようなものが手に入ったのだと思っていた私にとって、かなりの驚きでした。promiseを使うためだけにキーを設定して、非同期コールを行うたびに無効化しなければならないというのは、とても気が重かったのですが、Reactがコンポーネント内で、componentDidWhatメソッドやフックを使って行っていることは、すべてひとつの非同期ジェネレータ関数内にカプセル化できるのではないか、ということに気が付きました。JSXを返す代わりに生成することで、componentWillUpdateやcomponentDidUpdateと同じようなコードをレンダリングの前後に書くことができるようになります。状態はローカル変数になって、フレームワークの提供する非同期イテレータを使って新しいpropを渡すことが可能になります。try/catch/finallyなど、JavaScriptのコントロールフロー演算子を使って子コンポーネントからのエラーをキャッチしたり、クリーンアップロジックを記述したりすることも可能です。これらがすべて、同じスコープ内にあるのです。Reactチームは"UIランタイム"の構築に相当な能力を費やしたようですが、私は、スタックの一時停止やスケジューリングといった難しい部分については、JavaScriptランタイムに任せられることに気が付いたのです。ランタイムが提供するジェネレータや非同期関数、マイクロタスクキューなどが、それを確実に実行してくれます。Reactチームが行ったことで、1プログラマとしての私では到底できそうもないような素晴らしいことは、すべてバニラJavaScriptですでに用意されていると思えたので、あとはパズルのピースを組み合わせる方法を理解するだけでした。Crankは、コンポーネントが同期関数だけでなく、非同期関数や、同期および非同期のジェネレータ関数でも記述可能であるというこのアイデアを、1か月にわたって追及した成果です。それまでは自分が最初に持っていたアイデアに真っ向から取り組んでいた私にとって、人生の上でのちょっとした回り道になりました。正直に言うと、フレームワークではなくアプリケーションの開発に戻りたい気持ちがあったのですが、JavaScriptコミュニティから突然注目されたことが、Crankにとって幸福なアクシデントになりました。Crank.jsではJSX駆動のコンポーネントと非同期ジェネレータを使用している、という話がありましたが、JSXコンポーネントは、レンダリング関数を使用するフレームワーク(React型フレームワーク、ある意味ではVue)では一般的なものです。一方で、ジェネレータを使うものはすくなく、非同期ジェネレータはさらにまれです。間違いないのは、ジェネレータや非同期ジェネレータを試したのは私が初めてではない、ということです。私はいつもGitHubで新しいアイデアを探しているのですが、フロントエンドでジェネレータを実験している人はたくさんいました。JavaScriptのジェネレータが当初async/awaitやpromiseと関連付けられていたために、これらライブラリの多くは、コンポーネントに非同期依存性を指定する方法として、promiseの生成にジェネレータを使用し、JSX要素を返すだけのようでした。私はもっと単純に、JSX要素を生成することができるのではないか、と気が付いたのです。そこで、仮想DOM差分アルゴリズムに基づいた、非同期コンポーネントの新たなセマンティクスを考え出しました。要素を生成し、フレームワークがそれをレンダリングして、レンダリングされたノードがジェネレータに対して、コール・アンド・レスポンス的なパターンで返されるのです。全体的に、多くの人たち、特に関数プログラミングにバックグラウンドを持つ人たちは、イテレータやジェネレータについて考え込む傾向があるのではないかと思います。これらがステートフルなデータ構造であるがために、ジェネレータがステートフルである理由について考え過ぎるのではないのでしょうか。事実として、これはジェネレータの優れた機能のひとつだと思います。少なくともJavaScriptにおいては、ステートフルなプロセスをモデル化する最良の方法は、ステートフルな抽象化を使用することです。コンポーネントのライフサイクルをジェネレータとしてモデリングすることで、コンポーネントインスタンスごとにジェネレータを1回のみ実行し、そのクロージャをレンダ間で保持することが可能になるため、DOMの状態を単一の関数内に取り込んでモデル化するという作業が、極めて透過的な方法で実現します。Crankで同期ジェネレータコンポーネントが再起動される回数は、親がそれを更新する回数と、コンポーネント自身が更新する回数とを加えた数と同じです。このような、コンポーネントが実行される正確な回数を論証するという能力は、Reactではほぼ諦められていた類のものです。事実として、Crankを使用すること9で、期待しないタイミングでコンポーネントが定常的に再レンダリングされることがなくなるので、サイドエフェクトを直接"renderメソッド"に置くことが可能になります。"こういうものがRustにあれば"、というフィードバックを受け取っています。Crankのアイデアを他の言語、特にRustのfutureのように強力な抽象化機能を持つ言語に移植してもらえれば、本当に素晴らしいと思います。すべての状態が単なるローカル変数なので、propsやstateやrefといったReactのコンセプトとジェネレータコンポーネント内で混在することが自由にできます。これは他のフレームワークではできないことです。新旧のpropsを比較して、一致の有無をベースとした差異を描画するこのコンポーネントの例には、Crank開発の早い段階でとても驚かされました。Bob</div>"独立したライフサイクルや新旧propsを比較するフックの必要はなく、クロージャ内で単に両方を参照すればよいのです。要するに、新旧propsの比較が、隣接する配列要素の比較と同じくらい簡単になっているのです。Crankがローカル状態の概念をレンダリングから分離しているので、他のフレームワークではまったく不可能な、多くの高度なレンダリングパターンへの道も開かれていると思います。子コンポーネント群はローカル状態を持つだけでレンダリングせず、requestAnimationFrameループ内でレンダリングする単一の親コンポーネントがすべてを一気にレンダリングするようなアーキテクチャも考えられるでしょう。ステートフルだが更新毎の再描画を行わないようなコンポーネントは、Crankならば簡単に実現できます。それもCrankが状態とレンダリングを切り離しているからなのです。例として、私がまとめたこの簡単なデモを確認してみてください。これは昨年、ReactとSvelteの支持者がTwitterで議論した、3Dの立方体と球体のデモを実装したものです。Crankのパフォーマンスの高さには驚かされます。これは、コンポーネントの更新がジェネレータを通過するだけだからです。状態が単なるローカル変数であることや、上位コンポーネントがレンダリングするにも関わらず、すべてのステートフルなコンポーネントにレンダリングを強制するリアクティブシステムに強く結合していないことから、ユーザ空間においてさまざまな最適化を行う余地が生まれています。Crankの最初のリリースでは、パフォーマンスよりも正確性とAPI設計を重視していたのですが、今は可能な限り高速にすることを試みています。Crankのパフォーマンスについて、まだ具体的な主張をする気はありませんが、結果についての手応えは感じています。ModeとReactの将来的な方向性には批判的なのですが、もしReactチームがそれを実現できたならば、メインスレッドの混雑度に応じて自動的にレンダリングをスケジュールできるような、すばらしいコンポーネントになると思います。この種のスケジューリング機能をCrankに実装する方法をいくつか考えているのですが、これというソリューションはまだできていません。うまくいけば、コンポーネント内で直接待ち合わせができるという事実から、透過的かつオプトイン的な方法で、ユーザ空間内に直接スケジューリングを実装できるかも知れません。私はフックを支持している訳ではないのですが、ライブラリの作者がAPIをひとつないしふたつのフック内にカプセル化する方法については、少し言っておきたいことがあります。私が期待していて、まだ実現されていないことのひとつは、アーリーアダプタからの、自分のライブラリをCrankに統合するためのフック的な機能の要求です。それがどのようなものになるか、まだ分かっていませんが、この件についてもいくつかアイデアがあります。Kimはフリーランスのフロントエンドエンジニアです。安全な非同期イテレータを生成するための欠落したコンストラクタを自負する、オープンソースの非同期イテレータライブラリRepeater.jsの作者でもあります。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。