この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。 注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。 元記事のコードを minify するとどうなるか 元コードを参考に、それにアクセスするサンプルコードを書いてみます。 const sortingOptions = { priceDesc: { id: "priceDesc", sort: "price", order: "desc", label: "価格が高い順", }, priceAsc: { id: "priceAsc", sort: "price", order: "asc", label: "価格が安い順", }, ratingDesc: { id: "ra

去年末ぐらいから Deno を使う割合がグッと増えてきた。最近のJS関連は7割ぐらい deno 環境の VSCode でコードを書いている気がする。 今回はいくつかの実例を示しながら、実際に Deno 使えるじゃんというイメージを持ってもらうためのユースケースを紹介していく。 というか、 deno が普及してくれないと、自分が作ったツールの紹介を全部 deno のインストールから書かないといけなくなる。みんなインストールしといて。 最初に: なぜ Deno を使いたいか 一番の問題点、Node は新しいプロジェクトを一式整えるための手間が非常に重い。 とくに ts で書いたものを他の環境に渡すための方法が未だにしんどい。ある環境で動いたコードをそのままコピーしても、プロジェクト設定の非互換を踏む可能性が非常に高い。 deno にそういう側面がないとは言わないが、非常に少ない。とくに TS

これだけみると LibC がよく見えますね。 オープンソースのライブラリ比較や、エンタープライズな SaaS が競合に対する優位を見せたいときに星取表が使われることが多いです。 中立な立場でライブラリを選定する過程として出てくることがあります。 自分はこれに全く意味がなく、むしろ競争的な立場では出した側が負けるものと認識しています。 星取表を作る側の意図 よく見かけるパターンがこれです。 開発自体は長いため機能が豊富だが性能に劣る先発が、後発を貶めている 恣意的な項目選定で、そもそも負けている そもそも比較対象としての土俵が違う(全部入りのフレームワークと単機能なライブラリの比較) 特に 1 と 2 の組み合わせが多く、この裏では非機能要件で圧倒的に負けていることが多いです。例えば A は機能は豊富だけどビルドに 30秒で、Bは機能は足りないけど3秒だといった場合、多くの場合ではまず B

年末年始にフロントエンド論みたいな記事をいくつか見たが、僕ら古のSPA職人がやってきたフロントエンドという職域と目指していたものが失伝しかけている気がするので、ここに時代ごとに何を考えていたか、雑に書き殴る。 注意点として、 2004から始まるが、自分がプログラミングを始めたのが2010, 業務としてコードを書き始めたのが 2012 なので、解像度が高いのはそれ以降になる。 tl;dr 2004: 動き出す HTML 2011: 構造化のはじまり 2015: 贅沢品としてのSPAとコミュニティ分化 2017: 貧者のSPA 2019: 守破離としてのパフォーマンス 2004: 動きだす HTML AJAX の時代。要は XMLHTTPRequest で取得したコンテンツに応じて、動的書き換えをDOM書き換えを行うこと。今では名付けるほどでもない操作だが、HTMLが静的なものをやめたことは、

browser preview + debugger for chrome https://github.com/auchenberg/vscode-browser-preview https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome ブラウザ内で chrome のプレビューをする。そのときの debugger を vscode の debbugger につなげられる。ちゃんと js で debugger 書くと止まって便利。 { "version": "0.1.0", "configurations": [ { "type": "browser-preview", "request": "attach", "name": "Browser Preview: Attach" }, {

本記事は、 「なぜ仮想 DOM という概念が俺達の魂を震えさせるのか」 https://qiita.com/mizchi/items/4d25bc26def1719d52e6 の 2020 年版のリライトです。 2014 年当時、日本においては React は未だ知る人ぞ知るライブラリ、という位置づけでした。それが、この記事によって一気にメジャーになったように思います。 オリジナルは2014 年末の情報によって書かれたもので、さすがに 6 年経った今では情報が古くなっており、当時の暗黙のコンテキスト、古いリソースの参照、初学者の混乱を招く表現が残ったままになってしまっています。 定期的に更新しようとも思いましたが、そうすると 2014 年末の歴史的な背景を失ってしまうため、あえてそのまま残し、新しい記事を投稿することにしました。増補改訂版というより、ほぼ書き直しです。 この記事は本来なら