なんとなく察しはついてるけど、いちおう確かめておこうかと。 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(

久しぶりに、いわゆるポエムを。 新規・運用ヘルプを問わず、受託や副業でよくフロントエンドをやってる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> ); さすがにこの時代になるといろいろ既視感もあって、すんなり読めるコードか

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

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 がんばれ〜 コードとして公開されたとして、誰しもが簡単

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

GitHub - webrtc/adapter: Shim to insulate apps from spec changes and prefix differences. Latest adapter.js release: 界隈で脊髄反射的に必要って言われてる気がする 個人的にはお世話になったことはない SkyWayのJS-SDKでもサンプルでも使ってないし（いちおうメンテナしてるけど） なので余計にフロントエンドでいうjQueryと同じノリを感じる なので、実際に何やってるのか読んで調べてみて、その確証を得たい ちなみに、2018/04/23時点での`master`ブランチの内容。 ディレクトリ構造 `/src/js`が本丸。 . ├── adapter_core.js ├── adapter_factory.js ├── chrome │   ├── chrome_shim.j

未来の自分のためのメモです。 仕事でやってないせいですぐ忘れるし、都度思い出すの大変なので・・。 ただまぁだいたいの人はSkyWayとかEasyRTCとか何かしらのライブラリを使うはずで、そういう人たちにはあまり関係ない内容かも。 生のjsでWebRTCを書くときに、先に知っておきたかった系のメモです。 素人ではないがベテランでもない、そんな微妙な知識レベルだと思います。 まだ枯れた仕様ではないので、記事を読む時は日付に注意してください... WebRTC is 何 WebでRealTimeCommunicationできる仕様 もといクライアントどうしでP2Pで通信できる仕様やそのAPI群 See WebRTC Home | WebRTC 仕様まわり WebRTC 1.0: Real-time Communication Between Browsers Identifiers for W

Media Capture and Streams この仕様書をだらーっと流し読みしたので、知らんかったことをメモ。 あとついでに気になった指定について調べたことも。 MediaTrackConstraints navigator.mediaDevices.getUserMedia({ video: {}, // <- この引数 audio: {}, // <- この引数 }); ざっくり`true`指定しかしたことなかったけど、実は細かく指定ができる。 見ればわかるけど、定数のconst(ants)ではなく制約というconst(raints)と捉えるとイメージしやすいかも。 指定できるもの 仕様書より。 dictionary MediaTrackConstraintSet { ConstrainLong width; ConstrainLong height; ConstrainDoub

2018年2月verです。 基本的に2017年8月に書いた記事と変わってない。NO進歩。 2017年版: getUserMedia()で画面のストリームを取得する - console.lealog(); この記事に書いてること + さらに最近調べたことをメモ。 なんかおかしかったら教えてください。 対応ブラウザ Chrome Firefox 以上。 Safariの実装は進んでるらしいが、まだ。 Chrome Chrome拡張が必須 参考実装 https://github.com/muaz-khan/WebRTC-Experiment/tree/master/getScreenId.js https://github.com/skyway/skyway-screenshare/ これで得た`screenId`を使って`getUserMedia()`するだけ。 { video: { manda

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

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

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

http://github.com/facebookexperimental/recoil 先日のReactEuropeで発表されたてホヤホヤの、ExperimentalなReact向けの状態管理ライブラリであるRecoil。 ただAPIとかやりたいことを見てると、「MobXファミリーとの違いってなんぞ・・？」って個人的になってました。 インターネットでも同じような印象を受けた人はいるらしく、なんやろな〜と思っていた矢先。 MobXの作者である `@mwestrate` 氏が、さくっとTweetしてるじゃありませんか！ なのでこの記事では、そのTweetを引用して、翻訳+ざっくりまとめをしておきます。 元Tweetはこちら #MobX or @recoiljs? Saw a lot of questions on whether they're the same, so a quick t

フロントエンドエンジニアからみる、この界隈で今どんなIssueが話題になってるのかと、この先どういう動きがありそうかについて。 そこまで自分に先見の明があるとも思ってないけど、アウトプットしておかないと忘れてしまいそうなので・・。 ちなみにここでいうフロントエンドは、いわゆるブラウザとかJavaScriptのAPIのことです。 プロトコル的な側面はそこまで詳しくないのであまり触れません。 WebRTC 1.0 GitHub - w3c/webrtc-pc: WebRTC 1.0 API まず、RTCといえばズバリのWebRTCから。 昨年末にWDからCRへ格上げということで、もうAPIが激変したりはしない・・はず。 実際のところ、ここ半年くらい大きな対応した覚えがないです。（WebRTCそのものを実装してる人は、地味にいろいろ対応してると思うけど） ガワのAPIという観点でいうと、最近はも

なんとなくアテはついてたけど、中身が気になるという話を聞いたので調べてみた。 WebRTCやってるみなさんならお馴染みのあのページです。 chrome://webrtc-internals WebRTCのデバッグといえばこのページ。 特に何も仕込んでないのに、見てるページで`getUserMedia()`したり`RTCPeerConnection`が作られればその様子が見えるし、実際に流れてるメディアやデータのことまでわかる。 あれってどういうしくみ？っていうのを調べていきます。 ただのWebページ URLが`chrome://`になってるけど、れっきとしたWebページです。 なのでDevToolsでNetworkタブ見ればだいたいわかる！というわけで。 構成要素はこんな感じ。 webrtc-internals.html ただのHTML/CSS 以下の2つのJSを読み込んでる util.j

Mercari x Merpay Frontend Tech Talk vol.3 - connpass 六本木のメルカリ社にて。 Creating Serverless CMS from Scratch by @sottar_ create own CMS from scratch - Speaker Deck 海外のカンファレンスで発表したやつの再演だそうな CMSをつくったはなし 期限つきキャンペーンページを作ることがおおい 今までの業務フロー デザインをPMが考える デザイナーがHTML/CSSなど JSが必要ならフロントエンドエンジニアに頼んだりも レビューもする 問題だったところ デザイナーがコードを書く必要がある（HTMLはまだしもpugとか エンジニアのレビューのコスト ちょっとした修正でも同じフローをたどるので時間がかかる キャンペーンページの複雑さに比べて、コスパが悪い