なんとなしにビルド後のCSSファイルを眺めてて、なんで使ってないUIパーツのCSS定義が含まれてるの・・？って思ったのがきっかけ。 こういうこと たとえば、こういうディレクトリ構成でコンポーネントを書いてたとする。 - components - action-buttons - index.jsx - styles.module.css - page.jsxコンポーネントの実装はこのように。 // index.jsx import styles from "./styles.module.css"; export const ButtonA = () => <button class={styles.buttonA}>A</button> export const ButtonB = () => <button class={styles.buttonB}>B</button> expor

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

初手から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

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

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

という気持ちが高まったので、とりえあず2020年末の情報として、書き残しておくことにした。 Preactとは preactjs.com いわゆるReactのジェネリックで、`react-dom`が圧縮しないと130KBくらいあるところ、なんと3KB！というもの。 Reactとの互換レイヤーである`preact/compat`を使っても、余裕でお釣りがくるというわけで、ぜひとも使いたい！となる。 なんでそんなに軽いのかも書いておくと、 `react-dom`がやってるイベントシステムを実装してない DOMネイティブのを使ってる コードゴルフがんばってる 読めばわかるけど、結構がんばってる VDOMの実装も最低限 というわけで、軽量さにフォーカスして書かれており好感が持てる。 基本的にはよい Hooksも使えるし、基本的にはなんの問題もなく、そのうえ軽くてよい。 `className`って書か

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

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という観点でいうと、最近はも

JestいいですよねJest。 あれこれプラグインとかライブラリとか入れなくてもだいたいのことができて。 さて、この1ヶ月くらいひたすらJestでテストを書き続けて、ハマったとこをメモ。 逆に言えば、ここに書いてないことでは一切困ってなくて、Jest最高って感じ。 Karmaみたいなブラウザでテストする機能さえつけばもう一生ついていきます感すらある。 before / afterでもasync Docsにそれらしいコードはないけどできる。 beforeAll(done => { // some async tasks done(); }); beforeEach(async () => { await asyncTask(); }); afterEach(async done => { await asyncTask(); asyncTask2(done); }); afterAll(()

RTCQuicTransport Coming to an Origin Trial Near You (Chrome 73)  |  Web  |  Google Developers 今回は翻訳ではなく、気になる点の抜粋です。 TL;DR WebRTCにQUICがくるよ まずは`RTCQuicTransport`がChromeに実装されます M73からOriginTrialできます WebRTCにQUICがくる まずは`RTCQuicTransport`というクラスから ICEは変わらず、`RTCIceTransport`というクラスに QUICなので順序も再送も保証！ ゲームやメディアや様々な用途に使えるよ なんで こういう低レイヤーが充実すると、もっといろんなことができる それがWebRTC Next Versionだよ なぜQUIC リアルタイム性のため UDPの上に位置する `

この記事では、 ReactやVueではなくWebComponentsだけを使いたい気持ちを胸に、とある社内プロジェクトをやってみての学び 巷にあふれるWebComponentsに対する見方への違和感 についてメモっておきます。 ただ「WebComponents」の語がもつ意味をきっちり定義してるわけではないので、そのへんは雰囲気で察してください。 そのせいで勘違いされがちな概念なんかも、知らんけど。 まずは巷にあふれる意見に対する気持ちから。 (React|Vue|Xxx)はもう古い、これからはWebComponentsだ！ 勝手なイメージですが、こういう認識の人いるよね・・？ 個人的には、「いや、WebComponentsはそういう技術じゃない」と思った・思ってます。 以下、ReactもVueもAngularも「ウェブアプリケーションを作るための技術」であるが、WebComponents

CDN Study (Akamai/Fastly) - connpass 久しぶりにすごい人混みに身をおいたわ・・。 どんな勉強会だったか CDNにもいろんな歴史がある あの頃のCDNといまのCDNでは、世界観も役割も変わってきてる 気がする ので、中の人に聞いてみよう！ という主旨の会。 from Akamai 資料は見つけたら CDNの過去と現在 1995年の時点で、中央集権的なWebは破綻するといわれていた 中央集権型ゆえに インターネットの混雑が問題になるだろう from Tim Berners-Lee インターネットは網の目 ただ実際は地震でケーブルが切れて不安定になったり 去年のGoogleの経路のアレとかも 爆発的なトラフィックによる負荷 スターウォーズの新作トレーラーとか インドのプレミアリーグとか CDNってそもそも インターネットの不安定さを避けるためにどうすれば ユー