端的にいうと、 フロントエンドはSvelteKitやらモダンなやつで組んで Cloudflare Pagesにデプロイしたい そしてKVやD1やらも使いたいし ローカルでも実際の値を参照して開発したい つまり、サーバーレンダリングやAPIルートを実装するときに、既存のスタックに保存してある値を使いたいという話。 個人的にはあるあるのケースで、あらゆるものをCloudflareのエッジで完結させる未来を待つなら、なおさら。 ローカルから実際のKVやD1にアクセスするには 現状、これをやるには2通りの方法しかない。 REST API `wrangler dev --remote` まず前者。これはいわずもがな、HTTP経由でアクセスできる。 ただ、Cloudflare Pagesにデプロイするなら、Workersで動作するコードからアクセスするなら、あえて1クッションはさむ理由はなさそう。 つ

今年も祭りの季節がやってきましたね。 Developer Week 2023 | Cloudflare というわけで、今年も個人的に気になったものを。 （発表されるのがだいたいJST深夜かつ最後が金曜日なので、どうやっても公開するの週明けになるんよな・・） Introducing Constellation, bringing AI to the Cloudflare stack https://blog.cloudflare.com/introducing-constellation/ Workersで機械学習のモデルが動かせるようになったとのこと プライベートβ サポートされているランタイムで動作するモデルであれば、自作のものでも、用意されてるものでもOK 現状はONNX形式のみ対応 https://github.com/onnx/models https://github.com/d

したいよね？ 事の経緯としては、 とある新規プロジェクトで、技術選定をすることに 開発の土台はViteで、フレームワークはJSXが使えるやつに決まった さてCSSはどうやって書こうかとなる あれこれ考えて、とある方法に決めた というのをまとめた、まあポエムの域を出ないメモです。 CSS ModulesやらTailwindやらCSS-in-JSやら手法はいろいろあれど、どれが今の推しかっていう。 求めるもの 個人的に、CSSつまりはブラウザで表示されるUIをスタイリングするためのツールセットに求めるもの。 0ランタイムである 最終的に`.css`ファイルとしてブラウザで読み込まれる なんでもJSにしない CSSの書き味を損なわない だいたいのCSSセレクタが問題・制約なく動作する マークアップ部と1ファイルにコロケーションできる HTMLとCSSは同居させたい 非同期にロードできる JSと同

我ながらニッチなことをやろうとしてるなって思う・・。 普通の生活をしてる分には、活躍する出番はないはず。`eval()`はもっと使わない。 new Function() const fn = new Function("a", "b", "return a + b"); console.log(fn(2, 6)); という使い方ができる。 ユーザーからコードみたいな文字列を受け取って実行させたいが、`eval()`ほど無秩序にはしたくない時に使う。 `Function`コンストラクタはグローバルに生えてるけど、これで非同期な処理をしたい場合は？ new AsyncFunction() ってしたいけど、そんなものはグローバルに生えてないのでできない。 が、自作すればよいらしい。 AsyncFunction - JavaScript | MDN こんな感じに。 const AsyncFunct

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

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

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日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。

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

久しぶりに物理本を読んだけど、やっぱ物理はええな・・かさばるとこ以外。 せっかくなので読書感想文と、特に印象に残った部分を、章ごとに書いておく。 第1章: 達人の哲学 この本を読んでいくにあたって、そもそも達人とはなんぞやという話がメイン。 プログラマーというより、いわゆる社会人としてこうあれみたいなテーマで書かれてて、なんかみんな読んだらいいのではと思いました。 物事をうまく進捗させるために、 まず何を言いたくて その結果どうしたいのかまで考えて 相手の状況やタイミングを見計らって コミュニケーションを実行する・されると、あれこれスムーズにいきますよっていう。 このテクは中々に便利で、日常生活でもそれこそ夫婦間とかのコミュニケーションでも使える話かなーと思ってて。 ただ自分の場合はこれをやりすぎて、質問してるはずが誘導尋問みたいになっちゃうときがたまにある・・。 第2章: 達人のアプロー

アクセスするとメガ単位でたくさんの画像を読み込むサービスがありまして・・。 リファクタによって、動的に必要な画像だけを読み込むように改修はしたけど、それでも回遊するとサイズがすごいことになる。 これをなんとかするならServiceWorkerしかない！というわけで。 Workbox 最初は0から手書きしようかと思ったけど、ちょっとやり始めただけであれこれ面倒なことがわかったので、先人に頼ることにした。 Workbox  |  Google Developers ご丁寧に、こういうことがやりたいんじゃろ？っていうのがガイドの中にあって、そうそうこれこれ〜って感じだった。 事前キャッシュではなく、あくまでランタイムでのキャッシュがしたかったので、これ。 import { CacheableResponsePlugin } from "workbox-cacheable-response"; i

について、Vue Composition APIのDocsに記載があったので、自分用にメモ。 Composition API RFC | Vue Composition API このRFCが出たのは2019年の7月なので、ぜんっぜん目新しい情報はないです。 React Hooksとの比較 Composition APIで関数ベースでロジックを記述できるようになる ロジックを合成できるという書き味は、React Hooksと同等であろう ただし、大きな違いもいくつかある まず`setup()`は、本当に1度しか呼ばれない これはつまり より直感的にJavaScriptを記述できる 呼び出し順序も、条件分岐も気にしなくてよい 呼ばれる回数が減るのでGCにも優しい `useCallback()`を使ったインラインハンドラーの最適化などが不要 `useEffect()`や`useMemo()`に正

https://sveltesummit.com/ https://www.youtube.com/watch?v=vHHLLJA0b70 JST夜中スタートだとリアルタイムで見れない...😴 というわけで、気になるトークだけまとめました。 The Zen of Svelte (Morgan Williams) https://www.youtube.com/watch?v=vHHLLJA0b70&t=683s Svelteはフレームワークである そして学びやすいのが特徴 Pythonのように、Zenの心得がある https://github.com/feltcoop/why-svelte#easy-to-learn 作者のRich氏もこう言ってる Frameworks are not tools for organizing your code, They are tools for

（SSR不要論者のはしくれとして）今までこれっぽっちも気にしてなかった、あのNext.jsです。 ここでいうSSRは、クライアントのリクエストに応じてSSRしてレスポンスを返すこと。 ただ最近仕事で使ったり、副業でも使ってたりする機会があって、一部認識を改めたところがあるのでそれをメモっておく。 静的サイトジェネレータとしてのNext.js それは、「元来のサーバーレンダリング用ミドルウェアとしてではなく、SSGを目的としたプリレンダリング用ツール」として見れば、実は結構よいのでは？というもの。 コマンドでいうところの`next build && next export`だけを使う前提。 プリレンダリングで最適化した静的なサイトにしたい けど、それぞれのページにはJSを使った処理がある 前者だけの場合は、だいたい`11ty`みたいないわゆる静的サイトジェネレータが検討されるけど、各ページで

https://www.netlify.com/pdf/oreilly-modern-web-development-on-the-jamstack.pdf Netlify社が2019年に公開した本？PDFです。 せっかくJamstackの会社に入ったので、読んでおかないといけない気がして。 あとJamstackは人によって解釈が違ったりするとし、Jamstackの真髄について知っておきたいですよね？と思い。 ただこれなんと127ページもあるんですよね〜。 全編もちろん英語なので、読むのも中々に大変ですよね〜。 てなわけで、ざっくり訳してまとめまておきました。（それでも長いけど） はじめに ここ最近のWebの進化はすさまじい ブラウザもJavaScriptもパワフルになった その分ユーザーの要求も増える やることが増えると処理は遅くなる 遅いページは見向きもされないモバイル当たり前の世界だ

そして子も生まれていました！ というわけで、子です🤗 pic.twitter.com/UzvIiUpCOP— りぃ (@leader22) 2020年6月10日 人生ですなあ。 いままで 2018年12月からNTTコミュニケーションズという会社で働いていて、2020年6月いっぱいで退職しました。（なのでこれはいわゆるNTT退職エントリ 🥱） N社では、 SkyWayの（歴史ある）JS-SDKをメンテしたり （おなじく歴史ある）Nodeで書かれたシグナリングサーバーをメンテしたり OSSのSFUである`mediasoup`を使って、録音SDKとそのサーバーを実装したり WebRTCに関連するRFCやドラフトをとにかく読みまくったり いわゆるエッジな技術の検証をしたり 各種SDKを使ったWebアプリをいくつか書いたり https://github.com/skyway/skyway-con

続・React x MobXな趣味プロダクトをTypeScriptでリライトした - console.lealog(); このシリーズの続編で、いわばSvelte人柱シリーズです。 どんなプロダクトなの 一言でいうと、ブラウザで動くiTunesみたいなSPA。 CDをリッピングしてMP3にしたものをVPSにおいてて、それをWebのUIから再生できるようにしてる。 使い続けてかれこれ3年くらい・・思えば最初はVueだった気もする・・。 TodoAppほど小さくはなくて、でも片手で数えられるくらいのルートしかなくて、非同期処理はあって、ちょいインタラクティブなUIになってる程度のサイズ。 なので正直いってそこまで大きくないので、どんなものを使ってもそれなりにきれいなコードは書けると思ってた。 なのでここは好奇心ドリブンで、最近イチオシになりつつあるSvelteを採用することにした。 ビフォーア