はてなブックマーク

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.. などなど一通り思案して、必要ならメモを書いて、頭の中でコードをイメージする作業を先にやる。 そしてイメージできたものを、ガッとエディタに打ち込んで動くコードにしていく。 もちろん書いてみてはじめて気づく落とし穴もあったりするけど、その時はまたエディタから離れる。 コードを見てコードを治そうとすると、あ

久しぶりに物理本を読んだけど、やっぱ物理はええな・・かさばるとこ以外。 せっかくなので読書感想文と、特に印象に残った部分を、章ごとに書いておく。 第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

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