はてなブックマーク

もとい、Svelte(Kit)なプロジェクトを、Qwik(City)で書き直してみての学び。 待望のやつではあるが、端切れの悪いタイトルなのは、移行途中でどうしようもなくハマってしまい、採用を見送ることにしたから・・😇 そういうわけなので、使い込んでみたわけでもまったくないし、最高！とか微妙・・・とかそういう判断というよか、ただの感想文って感じ。 QwikCityありき `npm create qwik`のスターターが、そもそもQwik単体ではなく、QwikCityがセットになってた。 今回はSSG/SPA用途だったので、できればQwikだけ使えればいいかなーと思ってたけどそんな選択肢はなかった。こういうメタフレームワークはSSRが前提になってたりすることが多くて、SSRなコンテキストを回避するコードを書きたくないし、挙動としても囚われたくなかったのに・・。 あとはコードベースもType

移行しようと思ってしたというより、なりゆきでそうなっただけではあるけど。 が、結論としてはもっと早く移行すりゃよかった！というくらいに、Neovimいいやん！ってなってる。 ことの経緯 `coc.nvim`やめるってよ もともとエディタはノーマルVimをターミナル内で使ってた みんなVSCodeな中、やや疎外感を感じながらも LSPまわりは`coc.nvim`を使ってて、特に不満はなかった が、ある日。 手元のNode.jsのバージョンを最新のLTSにあげたら、Svelteのエクステンションである`coc-svelte`が動かなくなった。 どうやら既知のIssueらしく、リポジトリにもPRが立ってた。 Fix coc-svelte not working with Node v18 by rudolfs · Pull Request #60 · coc-extensions/coc-sve

個人的なやつなので、すべての案件にハマるわけではないはず。 今回はたまたまAstroを選んでるけど、他のものを使ってSSGする場合にも、ある程度は当てはまる内容かと。 データの取得コマンドとSSGのコマンドを分ける ビルドコマンドを叩いた時に、 SSGのフローの一貫としてデータを`fetch()`し、それを使ってページ生成 というのではなく、 データを取得し、ローカルにキャッシュするコマンド そのキャッシュを使って、SSGでページ生成するコマンド という2段構えにするということ。 こうすることで、ローカルでの開発時にネットワーキングしなくて済む。 データ取得のコマンドを賢く作れば、毎回一括ダウンロードもしなくてよくなるし。 アーキテクチャにSSGを採用した場合、遅かれ早かれCMSからすべてのデータを引っこ抜くことになるので、そこだけを個別に最適化できるようにしたほうが絶対に幸せになれる。C

Cloudflare WorkersのD1といえば、APIとして立てたWorkerの内部で操作するのがまぁ一般的なはず。 ただ、D1はSQLiteなので、その裏にいるDBファイルを持ち回すこともできるんでは？っていう。 ダンプする なんとそれ用のAPIが用意されてる！ https://developers.cloudflare.com/d1/platform/client-api/#await-dbdump というわけで、こういうコードをWorkerで実装すればよい。 export default { async fetch(_req, env, _ctx) { const db = env.DB; const arrayBuffer = await db.dump(); return new Response(arrayBuffer, { headers: { "Content-Type

久しぶりに、いわゆるポエムを。 新規・運用ヘルプを問わず、受託や副業でよくフロントエンドをやってるWeb屋の見解、そして手札のお悩み。 この先、また技術選定する際なんかにも参考になるかと思ったので。 React 「いまフロントエンドやるなら最初に覚えるべき！」は、もう過去の話かなーと個人的には思ってる。 Reactは`UI = fn(state)`なのが良い！とか言われるけど、あなたが必要としてるのは`UI = Component(props)`かもよって。 一昔前までは、たしかにあらゆる面で頭一つ抜けてる印象はあったけど、今はそうでもないか、その差はだいぶ埋まってきてると思ってる。（もちろん先行者利益みたいなところで、エコシステムはまだまだ優位な差があるかもしれんけど、それもあまり実感できたことはないし、いまからはじめる人はそんなんで困らんやろうし） 原初の時代からReactな案件をそれ

Signals – Preact Guide 端的にいってしまうと、Solidのソレとほぼ同様の体験でコードが書けるようになる・・・！ まずはコード // store.js import { signal } from "@preact/signals"; export const count = signal(0); export const add = () => count.value++; // Counter.jsx import { count, add } from "./store.js"; const Counter = () => ( <div> <p>Count: {count.value}</p> <button onClick={add}>click me</button> </div> ); さすがにこの時代になるといろいろ既視感もあって、すんなり読めるコードか

https://www.solidjs.com ずっと調べたいものリストにはあったやつで、Astro熱がちょっと収まったのでこのタイミング。 めちゃめちゃ雑にまとめると、React + MobX feat. Svelteって感じのUIフレームワークです。（つまり好みは分かれるであろう） Solidとは 基本はReactライクな書き味 JSXでコンポーネントを書く、Propsでデータを単方向に流す もちろん細かい挙動に差異はあるし、互換性はない `Suspense`とか`Portal`とか`ErrorBoundary`とかもある MobXライクなリアクティブの仕組みがビルトインされてる Propsが自動でProxyされてるイメージ 依存配列なしに、状態を読み取ったコンポーネント・関数だけが更新できたり ストア（ちょっと大きめの状態用）関連のコードもある Svelteと同様に、コンパイルして最

初手からREPLがついてたりと、なかなか洗練されてそう・・ってのが第一印象。 What is Edge Runtime | Edge Runtime あとは`cloudflare/miniflare`のコードを読んだ身として、どういう実装になってるんやろ？ってのも気になったので。やはりNode.jsの`vm`を使ってるのか、はたまた未知のテクノロジーか・・・！ 読んだのは最新の・・というか、いま時点ではまだ1コミットしかなかった。 https://github.com/vercel/edge-runtime/commit/0b11a95e2f470d278db27982e4905febc6ac9bb7 リポジトリの構成 モノレポ。 . └── packages ├── format ├── jest-environment ├── primitives ├── runtime ├── ty

HTMLファイルをパースして、 特定の文字列を抜き出したり 特定の属性を書き換えたものを書き出したり ってことをやりたい時、今までは`cheerio`を使うことが個人的には多かった。 GitHub - cheeriojs/cheerio: Fast, flexible, and lean implementation of core jQuery designed specifically for the server. 懐かしい`jQuery`的な記法で操作できる・・とはいえ、もはや`jQuery`のことぜんぜん覚えてなくて、生DOMのAPIばっか使っちゃったり。 かといって、`cheerio`が内部で使ってるHTMLのASTパーサーである`parse5`や`htmlparser2`をそのまま使うのは、ローレベルすぎて乗り気じゃなかったり。 というところで、なんか代用できるものはないかな

Platform Week - The Cloudflare Blog この中から、個人的に気になったものたちをさっくりまとめ。つまりWorkersとかPagesとかに関連するものが多く、それ以外のStreamingとかWeb3系はスルーしてる。 The next chapter for Cloudflare Workers: open source The next chapter for Cloudflare Workers: open source CFWのランタイムのソースコードをオープンソースにするっていう発表 現時点でコードが見れるわけではなさそう これで`miniflare`と実環境の境界もなくせるねって言ってた https://twitter.com/_mrbbot/status/1523652262115278848 がんばれ〜 コードとして公開されたとして、誰しもが簡単

GitHub - withastro/astro: Build fast websites, faster. 🚀🧑‍🚀✨ 読みはじめた時点でのコミットは`21926278ba664d8362694efe51943968dfcb4b26`で、バージョンでいうと`1.0.0-beta.9`です。（めちゃめちゃ頻繁に更新されるので、今はもう最新ではないはず） はじめに 最近のAstroですが、順調にメジャーリリースを目指して開発中です。 the official Astro v1.0.0 release will be available on June 8, 2022. https://astro.build/blog/astro-1-beta-release/ という感じなので、コードを読むのにも丁度いいかなと。 もちろんバグやら挙動不審なところは散見されるものの、Partial Hy

なんとなく察しはついてるけど、いちおう確かめておこうかと。 GitHub - leader22/workers-benchmark 詳細はこのリポジトリに。 Rustで書くには ドキュメントなどあらゆる情報は、Cloudflare公式のこのリポジトリにある内容がすべて。 GitHub - cloudflare/workers-rs: Write Cloudflare Workers in 100% Rust via WebAssembly Workerグローバルのコードがそれ用のcrateになってて、それを使ってRustでコードを書く。RequestやらKVやらだけでなく、いわゆるRouterやちょっとした便利関数まで実装されてた。 READMEにあるコード例をそのまま貼るとこんな雰囲気で。 use worker::*; #[event(fetch)] pub async fn main(

2022年現在に、Cloudflare Workersで（CDNエッジでWorkerで）SSRする方法は2つある。 Cloudflare Pages(w/ Functions) Cloudflare Workers(w/ Workers Sites) 静的サイトホスティングサービスであるPages + Functionsで動的な部分を追加するというアプローチか、動的なWorkers + 静的なアセットを配信するためのWorkers Sitesという機能を使うかの2択。 で、この記事で調べたいのは、どっちのアプローチでもいいけどこの動的な部分でいわゆるSSRができるフレームワークたち。 誰だってある日突然、エッジでSSRしたい気持ちに駆られることってあるじゃないですか。というわけで、独断と偏見で調べたものをまとめた。 SvelteKit Repo: https://github.com/sv

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の特徴 遅いモバイル環境だとしても、

子育てしてたら一日が終わってて、それを続けてたら一年が終わってた、そんな一年。 おかげさまで、👼🏻は1歳半の元気ざかりで何よりではある・・が、思ってたより大変すぎる！いやほんとまじで（ やってたこと 脱SPA、からのMPA、からの・・・ なんでもSPAにするんじゃねぇ！という主張のその先 - console.lealog(); 「とりあえずReactでNext.jsでSPAでよろしく！」みたいにやってくる案件を、「ほんとにSPAにする必要あんのけ？😒」って切り捨てる係をやってた。 もちろん、ほとんどのケースにおいてSPAである必要はなかった。 ただし巨SPAではなくても、 いくつかのページは、SPAでやるべき多機能さ いくつかのページは、SPAでなくていいけど、ちょっとだけJSほしい いくつかのページは、完全に静的でいい みたいな複合ケースがほとんど。で、それをいい感じにまとめてやる

公私問わず`mediasoup`をここ半年くらいずっと触ってて、ドキュメントだけでなく中のコードもそれなりに読み通してる身として。 mediasoupとは mediasoup OSSで公開されてる、Node.jsから利用できるWebRTCのSFUです。 SFUを簡単に説明すると、WebRTCの接続をクライアント同士で行うのではなく、共通のサーバーでリレーさせて実現する仕組み。 サーバーにだけ送信すれば良いのでクライアント側の負荷も下がる クライアントは受け取りたいメディアだけを選択して受け取れる サーバー側で録音したりメディアの二次加工ができる などなど、トポロジとしてのP2Pが必要でないなら、WebRTCのユースケースのほとんどはSFUありきなのでは？と思ったりもする・・。 もちろん片手で数えられるくらいの人数がビデオチャットするくらいなら、SFUなしでもやれんことはないけど。 コードと

なんだかんだここ半年くらいずっとCloudflare Workersを触ってます。 で、CDNエッジでコードが動くことはわかった。制約があることも、それなりに速いこともわかった。 で、これをどう扱っていくのが人類にとって良いんかな〜？みたいなことをずっと考えてた折に、VercelやらRemixが「これからはエッジだ！」（意訳）みたいなメッセージを出してて、ふふ〜んってなった今日このごろ。 We believe the modern Web is at the Edge and embraces the open Web platform. https://vercel.com/blog/vercel-funding-series-d-and-valuation We leveraged distributed systems at the edge instead of static bu

Cloudflare社は、定期的に「なんたらWeek」って感じでまとめてアップデートを発表する取り組みをやってるっぽく、今回のテーマはフルスタック！ なんでもかんでもCloudflareでできるようにするよ！という強い意志を感じる発表たちだった。 Full Stack Week - The Cloudflare Blog 今回は実験的にTwitterでもまとめて流してたけど、やっぱりブログにまとめるほうがしっくりくるなってことで、改めて。 https://twitter.com/leader22/status/1460451057109127169 https://twitter.com/leader22/status/1460772775010791430 https://twitter.com/leader22/status/1461158193631936512 https://tw

我らがCloudflare社が、先日のブログで"Web3"なるものに言及してた。しかも3記事も続けざまに。 不勉強な身としては、ざっと読んだだけではふわっとしか理解できなかったので、もう少しちゃんと理解したいなーと思った。 というわけで、概要を訳しつつあれこれ調べてみたというメモです。 これは単に自分の視野が狭かったことに気付いたんですが、そもそも"Web3"という単語やそれを表すトレンドみたいなものは、2018年くらいのブロックチェーンな頃から既にあったんですね。 そういうわけなので、知ってる人にとっては何をいまさら？って話かもしれんし、それをこのタイミングでCloudflareが言及したことに、特別な意味を感じるのかも？とか。 Web 3.0とは Web3 — A vision for a decentralized web まずこの最初の記事をざっくり。 Web3とは、Web 3.0

調べたのでメモ。 TypedArray TypedArray - JavaScript | MDN いわゆる型付き配列。 通常の配列と違って型が固定できる分、内部的に最適化がしやすいとか諸々で住み分けられてる。 そういう意味で一般的なフロントエンドのJavaScriptコードで出てくることはそうそうない。 たとえばWebAudioとか、CanvasとかWebGLとか、いわゆるバイナリに近い処理をブラウザでやる場合に必要になるAPIたち。 Node.jsだと、`Buffer`っていうそれ用のクラスがあったりする。 種類 Int8Array Uint8Array Uint8ClampedArray Int16Array Uint16Array Int32Array Uint32Array Float32Array Float64Array BigInt64Array BigUint64Arra

ということに仕事で困らされて、最近それなりの時間を持っていかれた記念のメモ。 とりあえずのワークアラウンドは見出したけど、あとでどこかの誰かがもっといい感じにやってくれへんかな〜って。 やりたかったこと ViteのMultiple-Page機能を使ってアプリを作る 各Pageでは、そのページで使われてる最低限のJS・CSSのみを出力したい つまり、 たくさんのUIがあるPageA JSもCSSもそれなりのサイズになることが予想される ちょっとしたテキストがあるだけのPageB JSはおろかCSSのサイズもちょっとだけ ということがしたかった。 ViteのMPA あえて書くまでもないけど、`vite.config.js`でこういう指定をするだけ。 const { resolve } = require('path') const { defineConfig } = require('vit

Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。

https://github.com/mrbbot/miniflare Cloudflare Workers（以下、CFW）相当の実行環境をローカルで再現できるアレです。 そんなんは公式が出してほしいな〜と思い続けてはや1年弱、いつまで経っても出てこない！ というわけで、コード読んでみたシリーズです。 そもそも、なぜローカルで動かしたいのか これはひとえに、現状のCFWはローカルで開発できないから。 いちおう本家のCLIに`wrangler dev`という開発用のコマンドはあるけど、インターネットにプライベートなやつがデプロイされてそれを`localhost`にトンネルするだけで、実質ローカルではない。 そのうえ、 （インターネットに上げるからか）動作も速くない そしてとにかくクラッシュする 変更も反映されたりされなかったり謎 そのくせしっかり課金対象（無料枠の圧迫） という感じで、あまり

というアプローチを紹介してる記事があって、なるほど？と思ったのでまとめてみる。 元記事はこちら。 Leveraging Web Workers to Safely Store Access Tokens – The New Stack 毎度のことながら、今にはじまったことではない。 元記事いわく WebWorkerであれば、メインスレッドで実行されるであろうXSSや3rdのコードから触れないので安全！ 設計としては、 メイン: まず`Worker`をロード メイン: 初期化のメッセージを`postMessage()` クレデンシャルがあるならそれを渡す ワーカー: アクセストークンの準備 受け取ったやつ or そこで`fetch()`して、オンメモリに保存 （これで準備OK） メイン: APIにリクエストしてほしいと`postMessage()` ワーカー: APIに向けてアクセストークン

Cloudflare Workers docs 巷で話題のエッジワーカーというやつ。 お仕事で使えるかもしれないというわけで、Docsを一通り読んでみて、ちょっとしたコードをデプロイしてみたところまでの感想。 Docsを読んでの学び コールドスタートがない AWSやらGCPのそれと違って、ランタイムごとにコンテナを〜という構造ではないから。 V8のIsolateなる機能を使って、基本的に立ちっぱのホストの上で、ランタイムだけを起動できるとのこと。 How Workers works · Cloudflare Workers docs なので、たまーに動かすコードでも実行が速いというわけ。 リージョン: 地球 普通にそう書いてあってカッコいい・・ってなった。 実行時間の制限がない 時間に関する制限は、CPU時間だけ。 Limits · Cloudflare Workers docs Netl

達人プログラマーを読んだせいか、最近よく考えてることでもあるので、この際なのでポエムにしてみた。 受託の会社バイアスはあるかもしれないけど、基本的にコードを書くエンジニアには通ずるところがあるはず。 設計に時間をかける これは、「いきなりエディタに向かってコードを書き始めない」ということ。 フォーマットはなんでもいいけど、 まずどういうものを実装しようとしていて 愚直にやるならこうする それによって既存のコードに影響がないか 過去のコードと一貫しているか 他の要件とぶつからないか etc.. などなど一通り思案して、必要ならメモを書いて、頭の中でコードをイメージする作業を先にやる。 そしてイメージできたものを、ガッとエディタに打ち込んで動くコードにしていく。 もちろん書いてみてはじめて気づく落とし穴もあったりするけど、その時はまたエディタから離れる。 コードを見てコードを治そうとすると、あ