これはなにか cloudflare スタックを使ったマイクロフロントエンドの提案。 特に service-binding を活用することで異なるサービス(ここでは cloudflare worker)から配信されるフロントエンドを統一的にSSRしつつ、開発単位を分離している。 RTT最適化のために qwik で書かれているが、SSR を意識しなければ他のライブラリを採用しても良い。 $ tree . -I node_modules . ├── README.md ├── body │ ├── package.json │ ├── public │ │ └── favicon.ico │ ├── src │ │ ├── Body.css │ │ ├── entry.ssr.tsx │ │ └── root.tsx │ ├── tsconfig.json │ ├── vite.config.t

tl;dr 生産性を上げる & SQL インジェクションを防ぐために ORM を使うのがよいとされている(諸説あります) cloudflare workers + d1 はウェブの破壊的イノベーション(諸説あります) モダンフロントエンドで大切なのは TypeScript との親和性と言われている(諸説減ってきた) 本当は理想の ORM を自作したいのけど、drizzle が現状一番自分のゴールに近いので、試したら良さそうだった 既存の問題と drizzle-orm 今までのあらすじ というわけで d1 に全振りするのが今後の生存戦略として有効だと思っているんですが、d1 client は専用のAPIからクエリ文字列を送り込む形式なので、native driver を使ってる prisma や typeorm 等が使えません。 自分が Mongodb + たまに Rails ActiveR

sqlite 用に特化したORMを作りたい 何を作るか 主に sqlite 用のクエリビルダ + マイグレーションキット クエリビルダ部分は prisma 風の TypeScript の型推論をガンガン効かせたやつ。select するとそのフィールドだけ結果に出るやつ。 Why 最近 sqlite-wasm が sqlite 公式から出たので、ブラウザから sqlite を使う頻度も増えそう sqlite3 WebAssembly & JavaScript Documentation Index d1 や lite stream 等の各種の sqlite replication 系のDB が最近増えてるから sqlite の注目度が上がってる(俺の中で) 現状、cloudflare d1 も sqlite-wasm も sql を生で書かないといけない TypeScript になれた世代の

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

プログラミング学習とはそもそも何なのか プログラミング初学者やITに関わる人が最初に知るべきこととして、プログラミングとは「あなたが問題を解決するのに用いたい手段を、あなたが思っているようにコンピュータに入力すること」ではない。 実際には、プログラミング学習はコンピュータに可能な(非常に限定された)処理セットを学ぶことであり、その応用の先に当初のゴールが含まれるかは、プログラミングを学んでその特性を学ばないと、判断すらできない。 例えば、手段 A によってゴール X を達成したいとしよう。非プログラマ/プログラミング初学者の発想は、よほど目の付け所がいいのではない限り、次のいずれかに分類される。 A には同じゴール X を解決する簡易な代替手段 B があり筋が悪い。 A で実現するほどの価値がない A は現状の人類の既存のソフトウェアの応用では実現できない。あるいは非常に困難。無理に実現し

自分が欲しい物がなかったのでサクッとでっち上げました なぜ作ったか 軽量で TS フレンドリな CLI ツールがほしい oclif がサブコマンドまで管理してくれるが色々と過剰 ジェネレータの生成コードが最新バージョンのものではなく怪しい(メンテされてる？) tsconfig の縛りがあったり、他のライブラリの一部に混ぜづらい type: module で実行できない (手元にESM生成物があった) cmd-ts が使いづらい 単なるバリデータではなく実行 handler まで渡さないといけない これ以上ライブラリ専用の DSL を覚えたくない => 引数パースを突っ込むだけの zod のラッパーでいいじゃん 使い方 // npx ts-node examples/sample.ts --name mizchi --age 34 --dry xxx 1 import { z } from

Bun を読むにあたって、まずZigを抑える必要があると思ったので数時間学習してみた。チュートリアルを一通りやったのと、ちょっと手を動かした程度で、正直エアプの域は出てない。 自分の動機として wasm を吐くのに使う言語をずっと探していて、Rust も悪くないが正直学習コスト高すぎでしんどく、Zig がそれに足るか調査していたという感じ。 この記事を書くにあたっての細かい作業はこちら https://zenn.dev/mizchi/scraps/287b4414da2b29 Zig 言語自体のスタンス まず Zig 言語自体がなぜ D や Rust ではないかはこの記事がわかりやすい https://ziglang.org/learn/why_zig_rust_d_cpp/ 以下 Deepl で訳してちょっと修正したもの nostd 指向 標準ライブラリなしでもファーストクラスでサポート

S3、というより S3 API は、AWS というよりオブジェクトストレージ界の標準になりつつあります。S3 互換を謳うオブジェクトストレージはそれこそ毎月一個増えてるんじゃないでしょうか。 複数の CDN 構成をとるとき、クラウドごとのSDK のコードを書くのではなく、一つの実装(自分の場合 node の @aws-sdk/client-s3)で、全部のバケット処理を統一できないか考えて実験してみました。 APIごとに有効な機能、無効な機能で細かい差がありますが、この記事ではそこまで踏み込みません。 記事中の <key> や <secret> は自分で取得してください。 AWS S3 まずは普通に AWS に繋ぐコードです。 accessKeyId や secrentAccessKey の取得方法は省略します。 import { ListObjectsV2Command, S3Clien

まだ検証足りないけど、マジで想像通りのブツなら魂震えるかもしれん…。 Announcing D1: our first SQL database Cloudflare D1 = Edge SQLite Cloudflare D1 は Cloudflare Worker で、つまり CDN Network 上で sqlite が動きます。これだけなら普通の sqlite ホスティングなんですが、もちろん Cloudflare が出すからにはそれだけではなく、CDN Edge 上に Read Replica がバラ撒かれた sqlite になります。ヤバくないですか？ 僕はヤバいと思いました。 このヤバさを知るために、Cloudflare が開発した基盤についていくつか抑えておく必要があります。 Durable Objects は CDN 上の Actor モデルを構築できます。この Acto

フロントエンド開発はフロントエンドで完結すべき過激派としてのGWの活動で、ブラウザでローカルファイルを読み書きするターミナルのプロトを作ってみました。 ローカルファイルをマウントして操作してる風景です。 ソースコード mizchi/web-shell 仕組み FileSystemAccess API を使って、FS API を実装 xterm.js 上で FS を叩く Unix 風のコマンドをいくつか実装 monaco-editor で、open <file> した内容を渡して、Cmd-S で保存した内容をFSに書き込む 最初に開いてるのは navigator.storage.getDirectory() の一時的なストレージで、これはブラウザの機嫌次第で揮発します(仕様にそう書いてある)。ローカルファイルを操作するのに mount を使うのがメインの用途です。 FileSystemAcc

JS で wasm のダウンロードや TypedArry を通じた操作をやってると、コード内や localStorage にバイナリを埋め込みたいときがあります。 考え方 JS の内部エンコーディングは UTF16 と決められているので、UTF16で表現可能な範囲を1文字として、バイナリをインライン化すればサイズが小さくて済むはず Chrome は CompressionStearm でブラウザ内で deflate できるので、あれば圧縮する https://chromestatus.com/feature/5855937971617792 Chrome ではない場合、deflate 処理は飛ばしてそのまま。localStorage の読み書きなら途中でブラウザ自体のサポート増える/消えるなどしない限り一貫性は取れる 今回はやってないが、インラインJSに埋め込む場合、50kb を超えたあた

この本は、ブルーベリー本の 8 章からインスパイアされて、 TS の型が示す情報から Promise というものを理解してみる、というアプローチで書いたJSの非同期処理の解説です。 これらの資料と合わせて読むことを推奨します。 JSのイベントループのイメージを掴む JSでは中々意識することが少ないですが、正しく理解するには OS レベルのスレッドの視点で考え始める必要があります。 ブラウザや Node.js では一つのスクリプト実行単位を1つのスレッドに割り当てます。それをメインスレッドと呼んだり、ブラウザだったら UI スレッドと呼んだりします。 例えばブラウザでは、これは秒間60回、つまり 16.6ms ごとにループを呼び出します。(node だったらこれがもっと短いです) 仮に setTimeout の実装がなかったとして、それ相当の擬似コードを書くのを試みます。 let handl

一部のライブラリ作者が terser を複数掛けているのは知識として知っていたのですが、それのホットスポットを見つけたので記事にしておきます。 この記事で書いた内容はすべて https://try.terser.org/ のデフォルト設定で試したものです。 前提 terser がオブジェクトの定数メンバをどう展開してくれるかを調べようとしました。ネストされた「定数であってほしいもの」をどう解釈するかの実験です。 入力

bundlephobia.com というサイトがあります。これは npm のモジュールを参照した際のバンドルサイズを算出してくれるサービスです。 便利なんですが、基本的に dist/.. 等の package.json の main で配られるものだけをターゲットにしているので、 ESM Treeshake で一部のモジュールだけ import {} from ... した際のバンドルサイズがわからない、という問題がありました。 なので、それに対応したものを自分で作りました。netlify にデプロイしてあります。 こんな感じです。 使い方 https://shakerphobia.netlify.app/?pkg=<>&imports=<a,b,c> どうやって動いてるか URL を踏むと、 cdn.skypack.dev (その実体は npm) からソースコードを落としてきて、 Web

(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事

Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho

最初に これは WebAssembly に GC が導入されるから紹介、という記事ではない。どちらかというと、WebAssembly GC の採用がどれだけ遠く、また GC がのればどんな言語でも wasm のコンパイルサイズが減って軽量になる、という夢を見ている人に、現実を見てもらうための記事になる。 WebAssembly GC Proposal (Team)は、それを実現するパーツを分割して仕様策定を進めていて、実際に GC が動き出すまでには数年かかるだろうし、自分の感覚的に、将来的に GC が採用されるかは五分五分といったところ。 ただ、 GC Proposal から派生した仕様郡は GC が採用されなかったとしても有意義なものばかりなので、本記事ではそれを紹介したい。 基本的にここを参照 Excuse 自分は低レベルプログラミングの経験が浅く、WebAssembly のために関

社内用の啓発記事ですが、閉じる理由がないのでここに投げます。 ブラウザにべったりなコードを書いてると、ブラウザや node.js 固有の環境をインラインで記述してしまうことが多々あると思います。 あえてダメダメなブラウザ向けのエントリポイントの例を書きます。 // main.ts let id = localStorage.get('id'); if (!id) { id = `${navigator.userAgent}-${Math.random()}`; localStorage.set('id', id); fetch('/auth', { method: 'POST', credentials: 'include', body: JSON.stringify({ id, at: Date.now(), }), headers: {'Content-Type': 'applicat

なぜ npm ツールチェインで消耗した こういうところでシュッと deno を入れておくことで、あわよくば本番で使う準備をする 経緯 久々に eslint の設定を見直したらやたら長大な感じでメンテがしんどくなった npm/yarn workspace で monorepo 化した際に、様々な eslint のバージョンが混在して peer-deps の管理が困難になった deno に組み込まれてる lint, fmt は deno かどうかはあまり関係なく、単に typescript なら使える 中身は https://dprint.dev/ と https://github.com/denoland/deno_lint deno lint は eslint の recommended 相当のものは実装してある eslint + typescript をメンテするより、 eslint 吹

tl;dr node 14.19.0 で npm のバージョンを明示的に切り替える corepack が入った package.json の packageManager フィールドで npm 自体のバージョンや yarn の使用するバージョンを指定できる 詳しくは https://zenn.dev/teppeis/articles/2021-05-corepack 現状の npm-cli 自体が corepack に対応してないので、有効にしたければ npm コマンド自体を corepack に移す必要がある 現時点で packageManager を指定するだけだとまだ他の環境で有効にならないが、将来的に npm と node の corepack 対応が行き渡った時点で段階的に有効になる。 もっと詳しく # 手元の node を v14.19.0 以上に更新する # 自分は nvm