GitHub - BuilderIO/qwik: An Open-Source framework designed for best possible time to interactive, by focusing on resumability of server-side-rendering of HTML, and fine-grained lazy-loading of code. 去年から気になってて、調べたいなーと思ってたやつ。 昨今の覇権を握ってる系のJavaScript-firstなフレームワークたちとは違い、HTML-firstを謳うユニークなアプローチをしてるのが一番の特徴。 中の人による一連のシリーズもあって、そこも読んでまとめてみた記事です。 Qwik Series' Articles - DEV Community Qwikの特徴 遅いモバイル環境だとしても、
2018年9月5日、第70回となる「HTML5とか勉強会」が開催されました。今回のテーマは「開発環境」。 Webフロントエンドの開発環境をテーマに、エディタプラクティスやServiceWorkerを開発ツールとして使うアプローチ、長期運用されたサービスのリニューアル方針など、登壇者たちがその知見を語ります。プレゼンテーション「ServiceWorker Side XXX」に登場したのは、mizchi氏。ServiceWorkerを駆使したある取り組みについて紹介します。講演資料はこちら 開発環境のためにServiceWorkerを使うmizchi氏（以下、mizchi）：では「ServiceWorker Side XXX」ということで発表させていただきます。mizchiです。よろしくお願いします。 （会場拍手） ちょっと自己紹介とかはする気ないんですけど、最近本を書いたので、その紹介だけさ
現状整理 JavaScript では末尾再帰最適化(PTE: Proper Tail Call) は、完全には期待できない https://kangax.github.io/compat-table/es6/ 末尾再帰による最適化 - Qiita なので再帰は注意して使わねばならない スタックオーバーフローしないことをチェック 再帰を辞めて for 文とかに何とか変換する とはいえ再帰を使いたい こともある じゃあどうするか？が本稿の目的 再帰におけるスタックオーバーフローは、末尾再帰の最適化ができる他の言語でも起こりえる(例: 末尾再帰できない場合)。じゃあ、他の言語の場合どうしているかというと、トランポリンするらしい。もちろん JavaScript でもトランポリンできる。トランポリンすると、再帰が深くなってもスタックオーバーフローしない。 処方箋 ざっくりいうと以下の処方でスタックオ
ゲームなどのコンテンツにおいて、「当たり判定」から逃れることはできません。オブジェクトとオブジェクトが衝突したかどうかという判定は、インタラクティブコンテンツにおいて最も重要な部分になるからです。 当たり判定の実装自体は難しくありません。ですが、素朴な実装ですと、対象となるオブジェクトが大量である場合に、十分なパフォーマンスが出ません。これはオブジェクトの多い、現代的なゲームでしたり、弾幕シューティングなどを作るときに大きな障害となります。 この記事では、大量のオブジェクトの当たり判定を処理する、効率的な方法について紹介します。 まずは素朴に実装してみる 当たり判定の処理を語るには、ある程度ゲームの骨組みのようなものが必要になってきます。もちろんクラスなどを使わないベタ書きでもよいのですが、大変読みにくくなってしまいます。ですので、今回は、まず簡易的なゲームエンジンのようなものを作って、そ
問題提起 （※タイトルはキャッチーなのにしましたが、Middleware全般の不要論ではありません。非同期処理において不要論です。） Redux使うときに非同期処理はどう書きますか？ 「よくわからないけどMiddleware使うらしい」と思考停止していませんか？ この記事では、Reduxは本来どのように扱うことを想定されているのかと、なぜ非同期処理の文脈でもMiddlewareが出てきたのか、そして「実はMiddleware無くても読みやすく書けるよね」という話をしていこうと思います。 Reduxでの設計を悩む人への個人的な解です。 （気になる・詳しく知りたい箇所などありましたらお気軽にコメントください） この記事のゴール ActionDispatcherという筆者が命名したクラスを使うことで、 複数の非同期処理を含むロジックでも読みやすく書ける ネットワーク通信などを含んでもテストがしや
こんにちは。プレイドの藤川(@atsushiss15)です。 プレイドには学生時代よりインターンとして参加しており、今年の４月に新卒社員として正式に入社しました。現在に至るまで弊社の提供するKARTEの機能開発を担当しています。 今回はVue.jsを利用したコンポーネント指向のUI開発において、私たちが実際に遭遇した問題とその解決策として導入したStoreパターンについてご紹介したいと思います。 Vue.jsというフレームワークが題材にはなりますが、Storeパターンの考え方自体は他のフレームワークを使った開発にも転用できると思うので、ぜひ読んでみていただければと思います。 目次 Vue.jsとは？ アプリケーションの大規模化に伴って生じた問題 解決策としてのStoreパターン サンプルコード他 Storeパターンに移行した感想 最後に Vue.jsとは？ Vue.jsを一言で表現するなら
追記 最新の感想も合わせてご覧ください。 jinjor-labo.hatenablog.com React界隈では結構前から「CSS in JS」と言って、雑に言うと「CSSはイケてないからJSでインラインスタイルを書いてしまえ」という話がある。（ちゃんと知りたい人はこちら） 自分も前々からCSSは変数が使えないとか名前が被るとか諸々イケてないのは同意してたんだけど、じゃあJSで書くのが良いかと言われたら「いや流石にロジック汚れるんじゃね？」とか「CSSの便利機能を捨てて平気なの？」とか色々と懐疑的だったんだけど、１～２か月書いてみたら想像以上に良かったので感想を書くことにした。 まず一番に主張したい部分を先に言うと、こう。 （誤解）JSのコードがスタイル記述で汚れる （正解）JSのコードがスタイル記述から解放される 前提 実際に書いたのはJavaScriptではなくElmなので以下は全て
追記: 情報が色々と古くなったため、2020年に書き直した版へのリンクを張っておきます。 この記事は VirtualDOM Advent Calendar 2014 - Qiita の初日です。 初日ということで、基調講演風に、Virtual DOMとはなにか、なぜ僕はこんな興奮しているのか！という話から。 Virtual DOMとはなにか 既存の概念で当てはめると、JavaScriptのMVC, MVW(Whatever)フレームワークのViewに位置します。が、その程度では終わりません。仮想DOMとは世界を革命する力であり、このjQueryのDOM操作で汚れきったフロントエンドを救う救世主なのです。 現時点で自分が知っている限りは、以下の実装を指します。 facebook/react 最も使われてるFacebookの実装 Matt-Esch/virtual-dom Altenative
はじめに この話はGuillermo Rauch氏が書いたhttp://rauchg.com/2014/7-principles-of-rich-web-applications/ という記事の翻訳です。許可を得て翻訳しています。 ここ最近Web業界を賑わしているSingle Page Applicationの必要性、HTTP2/SPDYといった技術、リアクティブプログラミングやIsomorphicデザインという考え方について包括的にまとめたすごく良い記事になっております。 最初に断っておきますが、ものすごく長いです。各セクションがわかれているので時間がない方はセクションごとに書かれたtl;DRとまとめを読むだけでも参考になるかと思います。 ちなみに明日のNode学園祭には、本記事を記述したGuillermo Rauch氏が見えるので、そこで詳しく聞いてみるのもいいのではないでしょうか。
MEANとは、LAMP(Linux, Apache, MySQL, PHP)に変わる技術としてじわじわと注目されはじめているアーキテクチャです。このアーキテクチャMEAN(MongoDB, Express, AngularJS, Node.js)は、シンプルでかつ強力なアーキテクチャで、現在のJavaを利用したアプリケーション開発とは一線を画すところです。HTML5開発にとってJavaの役割が殆どなくなるというのも注目すべき点だと考えます。MEANで一般的に言われる注目すべき事項は次のところです： JavaScriptフルスタックである データモデルとしてクライアントからデータベースに至までJSON そして、この記事を書こうと思ったきっかけですが、2014/10/5(日) Mozilla Open Web Day in Tokyo | Mozilla Japan でのMEAN解説展示で、様
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下本編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから（あるいは Marionette.js を使ったらから）といって自動的にお前のアプリケーションが MVC になるわけ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
