年内に間に合わなかった… 2021年に主にお世話になった言語・ライブラリ TypeScript React chakra-ui dnd-kit Node Vite esbuild Docker(=> lima) とりあえず挙げてみたが、なにか特定のライブラリを使う、という感じではなく、レイヤーが一つ下にいった感じがあり、実際にはなんかもうちょっと下のミドルウェアみたいなものを作っていることが多かった気がする。ASTをいじるコンパイラ周辺ツールを作っていることが多かった。 サクッとなにか作る場合、 React + TypeScript + Vite(esbuild) が鉄板という感じで、 esbuild が異次元に速すぎて、typescript の変換もバンドルも、もはやこれ一本でいい気がしてる。 microsoft/typescript はもはや言語仕様の定義と型検査がメインであって、コン

今年の本業は、 3rd party script で、そこから呼ぶウィジェットを最適化するコンパイラを書く、その仕様を考えて、実装するという感じだった。要は Google Analytics と、最適化コンパイラ付き GTM みたいなものを作っていた。その内容は以下に書いた。 サードパーティスクリプトの極限環境向け Svelte パフォーマンス改善に Core WebVitals という大義名分を得た 今年は、 パフォーマンスのエンジニアをやっていた、と思う。サードパーティスクリプトの配信を生業にする会社のエンジニアとしては、来年の Core WebVitals というパフォーマンス関連の大きな変化で、波にのってやりたいことがやれたと思う。 Core WebVitals の導入で実際にどれぐらいの影響がでるか不明だが、パフォーマンスが SEO に影響する、というのは、 若干やりすぎと思いつ

基本思想 とにかく薄く。必要なものだけ。基本は ts-loader を transpileOnly: true で使うだけ。最悪これだけでいい。型チェックはIDEか yarn tsc -p . --noEmit でやる。 CRA や parcel は使わない。暗黙な振る舞いが多すぎるので。一切勉強したくない人はいれていいと思うが、その場合 eject しない、dist ディレクトリをそのまま使うこと前提。 style-loader/css-loader は外部CSSを読むときに設定する worker-plugin はなくてもいいけど、 worker もビルドしたいことが多いので、入れていることが多い html-webpack-plugin と webpack-dev-server 組み合わせると、他と組み合わせずに完結して動く。このHTMLを本番で使わずとも、デバッグで使ってることが多いの

なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。 有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。 このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。 モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介

ブラウザ上でローカルファイルの読み書きができる Native File System API が ChromeCanary で実装された。 前々から欲しかった機能なので、自分が作ってる markdown preview ツールに実装してみた。 Intent to ship https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/noan0cgEBGQ/t8DuK8_hDwAJ 仕様 http://wicg.github.io/native-file-system/ 動かすとこんな感じ https://mdbuf.netlify.com/ で Meta+O/Meta+S のキーバインドを振ってる。 有効化 https://www.google.com/intl/ja/chrome/canary/ をダウンロード chrom

デモはここで試せる https://posenet-worker.netlify.com/ コードはここ github.com 構成 getUserMedia でカメラ取得 OffscreenCanvas でバックグラウンドの書き込み Tensorflow.js + Posenet Tensorflow.js が Chrome では webgl バックエンドになったとの目撃談があったので、試してみた。 [https://twitter.com/sugyan/status/1156616432248971264:embed#動作を試せるやつ上げた。Chromeだと WebWorkerでMainThreadの動き止めずにwebglで高速に処理してくれてそう https://t.co/GsepIMRSqG https://t.co/je8ceda47L] 今の所、Chrome 以外では tens

AMP Conf 全体の感想は後回しにして(書かないかも)、 amp-script について 単に使ってみたい人は AMP で任意の JS を実行できる amp-script を試してみた - Qiita や https://github.com/mizchi-sandbox/amp-script-preact で 最初に 僕の amp に対するスタンスは http://ampletter.org/?lang=ja に示された懸念とだいたい同じで、基本的にAMPは邪悪なもの、現代のウェブの事情を考慮する必要悪と悪の中間ぐらいだと思っており、それと同時に極端にリソースが制約されたプログラミング環境というものが好きで、そういう点で AMP 由来の技術を追っている、という立場。 amp-script について知っていること 全然ドキュメントないので、コード読んで、書いて、触って、あと中の人達に直

最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ

なかなかよいおもちゃを見つけたので、紹介します。 fly.io fly.io は CDN Edge Worker で JavaScript に特化した PaaS です。既存のサービスで近いものだと CloudFlare Workers もしくは Lambda@Edge でしょうか。 アカウント登録をして、次のようなコマンドを叩くとエッジで動くアプリケーションを作成することができます。 npm install -g @fly/fly fly login # mkdir my-flyio; cd my-flyio fly new 最小コードはこんな感じ。CloudFlare Workers と同じような ServiceWorker 風と、Google Cloud Function 風の 2 つのパターンでワーカーを定義できます。 // index.js addEventListener('fe

hooks が発表されてから趣味でも現場でもずっと hooks を使っています。おかげでだいぶこなれてきて、だいたいなんのライフサイクルでも表現できるようになってきました。 最初は単に useState が state を、 useEffect が componentDidMount/componentDidUpdate を置き換えるもの、と説明を済ますつもりでしたが、 useEffect についてはライフサイクルのモデルがぜんぜん違うので、別の説明をする必要があるように感じていました。 で、その結果 React Hooks を理解するには、関数のメモ化を理解するのが最も簡単だと思ったので、その説明をしつつ、イディオムを解説していこうと思います。 最初に: React Hooks は何であり、何ではないか 関数コンポーネントが状態を持てるようにするもので、関数のメモ化のテクニックを多用しま

ヒストリ履歴からよく使ってるものをお焚き上げする。 注意点: npm 周り、グローバルコマンドは npm i -g で入れてて、ローカルで扱うものは yarn で使うという癖がある 追記: シェルじゃなくてCLIだろと言われるのが多かったので訂正した vscode $ code . -r 現在ディレクトリを VScode で開く。 -r が肝で、新しいウィンドウを生成せず、既存のウィンドウを開き直す。 yarn $ yarn install --prefer-offline yarn install 時にローカルキャッシュを優先する。テザリング環境下でリポジトリを作成するのに便利。 フリーランスになってから出先で作業することが多く、ギガ足りない問題が多々発生した。 git $ git clone <github-url> --depth 1 HEAD だけ clone する。テザリング環境

mdbuf, そこそこ使い物になりそうな品質になったので改めて紹介します。 https://markdown-buffer.netlify.com で遊べます。 コンセプト ブラウザで完結 編集とプレビューのみに注力 PWA 機能を最大限に活かす 特長: 高速な Markdown プレビュー 色々頑張ってみた結果、高速な入力が可能です。 試した限り、 100000 文字以上だと流石に重くなっていきます。将来的に領域を分割してレンダリングできないか実験中です。 Desktop PWA 対応 PWA アプリとして、オフラインで起動することが可能です。編集中のデータはブラウザ内に保存されます。 編集位置への自動スクロール Markdown を編集すると、プレビュー側の対応する行へ自動的にフォーカスします。 自分が知る限りこの機能を実現してるのは mdbuf だけです。 アウトライン機能 指定した

大きく、末端コンポーネントと全体アーキテクチャの視点がある。 末端コンポーネントでの Hooks ここはあまり議論の余地なく、setState で local state を持っているものや、 componentDidMount していたものを置き換えることが出来ると思う。 FC を class にせずにちょっとリッチにするのが簡単になる。 class の setState 相当 function Counter() { const [count, setCount] = useState(0); const onClick = useCallback(() => setCount(s => s + 1), []); return <button onClick={onClick}>{count}</button> } componentDidMount / componentWillUn

React Hooks は Stateless Functional Component でも setState 的な状態操作や componentDidMount のような操作を可能にするための仕様提案です。 既に開発ブランチに入っていますが、 現時点で公式に採用されたものではないです。リリース時にはAPIが変わる可能性があります。 React のメイン開発者の一人である sebmarkbage の出してる RFC https://github.com/reactjs/rfcs/pull/68 試してみる react@16.7.0-alpha.0 に既に実装されており、公式のブログでも解説が出ています。 https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-reference.html 自分は以下

この週末で機械学習を勉強した結果として、JavaScript エンジニア向けにまとめてみる。 自分が数式見て何もわからん…となったので、できるだけ動いてるコードで説明する。動いてるコードみてから数式見たら、多少気持ちがわかる感じになった。 最初に断っておくが、特にJSを使いたい理由がないなら python で keras 使ったほうがいいと思う。tensorflow.js が生きる部分もあるが、学習段階ではそこまで関係ないため。 追記: 最初 0 < a < 1.0 0 < b < 1.0 で三角関数 Math.sin をとっていて、これだと三角関数の一部の値しか使っておらず、線形に近似できそうな値を吐いていたので、次のように変更して、データも更新した。 // 修正前 const fn = (a, b) => { const n = Math.cos(a) * b + Math.sin(b

もう人生で何個目かわからない markdown エディタ作った。が、今回のは結構気に入っている。 https://markdown-buffer.netlify.com/ で遊べる。 用途としては、GitHub か Qiita か はてなブログかわからないが、なにか書こうと思ったときに、どのサービスも中途半端に重いので、とりあえずのバッファが必要、という感じで作った。なので速度重視。 ブラウザのストレージで永続化してる。オフラインで動く。できるだけエディタとしてはスコープを大きくせず、単に編集バッファ(textarea)でしかない、というのを意識している。 結構頑張って作り込んでしまった https://nedi.app が色々肥大化してしまっていて入力時にラグを感じるので、編集体験を見つめ直す自戒もある。 機能 数式対応 コードハイライト対応 バックグラウンドで自動保存 改行を br に

おもしろライブラリを見つけて興奮しているので紹介します。 UIスレッド(メインスレッド)からユーザー操作をブロックしてしまうような重い処理を逃がす off-the-main-thread を実践しようとなると、実際に問題になるのは、ほとんどの処理は何らかの形で DOM を参照し、それに連なるものが処理時間の殆どを占めている、ということです。 off-the-main-thread の時代 - mizchi's blog DOM に触れない WebWorker でビジネスロジックを処理するのは、ある種の健全性(Universal/Isomorphic)を手に入れるための「縛りプレイ」として有用ですが、現状は実用上のメリットが殆どありません。 例えば react / redux の reducer で、ビジネスロジックを worker 側に移して処理できるぐらいアイソモーフィックに(DOMに触

今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる

某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty