Cloudlflare Workersの、Node.jsとの互換性について - console.lealog();
3月くらいにもなんか発表されてた気がするけど、結局いまどういう状態やっけ？って思ったので、思い出しついでにまとめる。 Node.js compatibility for Cloudflare Workers – starting with Async Context Tracking, EventEmitter, Buffer, assert, and util 2パターンある 最初はよくわからなかったけど、どうやら、 `nodejs_compat` `node_compat` という2つのフラグが存在してる。最初はフラグ名くらい統一しろよ・・って思ってしまったけど、これらは別のやつ。 ちなみに、`node_compat`のほうはLegacy扱いらしく、これらを併用することはできなそう。 nodejs_compat Node.jsのAPIの一部を、CFWのランタイムでも動かせるようになるフ
Modern Web Development on the JAMstack を読んでまとめた - console.lealog();
https://www.netlify.com/pdf/oreilly-modern-web-development-on-the-jamstack.pdf Netlify社が2019年に公開した本？PDFです。 せっかくJamstackの会社に入ったので、読んでおかないといけない気がして。 あとJamstackは人によって解釈が違ったりするとし、Jamstackの真髄について知っておきたいですよね？と思い。 ただこれなんと127ページもあるんですよね〜。 全編もちろん英語なので、読むのも中々に大変ですよね〜。 てなわけで、ざっくり訳してまとめまておきました。（それでも長いけど） はじめに ここ最近のWebの進化はすさまじい ブラウザもJavaScriptもパワフルになった その分ユーザーの要求も増える やることが増えると処理は遅くなる 遅いページは見向きもされないモバイル当たり前の世界だ
ViteのCSS Modulesは、JSのようにTree shakingできない - console.lealog();
なんとなしにビルド後の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
2023年のCSSは0ランタイムにしたい - console.lealog();
したいよね？ 事の経緯としては、 とある新規プロジェクトで、技術選定をすることに 開発の土台はViteで、フレームワークはJSXが使えるやつに決まった さてCSSはどうやって書こうかとなる あれこれ考えて、とある方法に決めた というのをまとめた、まあポエムの域を出ないメモです。 CSS ModulesやらTailwindやらCSS-in-JSやら手法はいろいろあれど、どれが今の推しかっていう。 求めるもの 個人的に、CSSつまりはブラウザで表示されるUIをスタイリングするためのツールセットに求めるもの。 0ランタイムである 最終的に`.css`ファイルとしてブラウザで読み込まれる なんでもJSにしない CSSの書き味を損なわない だいたいのCSSセレクタが問題・制約なく動作する マークアップ部と1ファイルにコロケーションできる HTMLとCSSは同居させたい 非同期にロードできる JSと同
AstroでSSGする場合の個人的ベストプラクティス - console.lealog();
個人的なやつなので、すべての案件にハマるわけではないはず。 今回はたまたまAstroを選んでるけど、他のものを使ってSSGする場合にも、ある程度は当てはまる内容かと。 データの取得コマンドとSSGのコマンドを分ける ビルドコマンドを叩いた時に、 SSGのフローの一貫としてデータを`fetch()`し、それを使ってページ生成 というのではなく、 データを取得し、ローカルにキャッシュするコマンド そのキャッシュを使って、SSGでページ生成するコマンド という2段構えにするということ。 こうすることで、ローカルでの開発時にネットワーキングしなくて済む。 データ取得のコマンドを賢く作れば、毎回一括ダウンロードもしなくてよくなるし。 アーキテクチャにSSGを採用した場合、遅かれ早かれCMSからすべてのデータを引っこ抜くことになるので、そこだけを個別に最適化できるようにしたほうが絶対に幸せになれる。C
Qwik(City)を試してみた感想 - console.lealog();
もとい、Svelte(Kit)なプロジェクトを、Qwik(City)で書き直してみての学び。 待望のやつではあるが、端切れの悪いタイトルなのは、移行途中でどうしようもなくハマってしまい、採用を見送ることにしたから・・😇 そういうわけなので、使い込んでみたわけでもまったくないし、最高！とか微妙・・・とかそういう判断というよか、ただの感想文って感じ。 QwikCityありき `npm create qwik`のスターターが、そもそもQwik単体ではなく、QwikCityがセットになってた。 今回はSSG/SPA用途だったので、できればQwikだけ使えればいいかなーと思ってたけどそんな選択肢はなかった。こういうメタフレームワークはSSRが前提になってたりすることが多くて、SSRなコンテキストを回避するコードを書きたくないし、挙動としても囚われたくなかったのに・・。 あとはコードベースもType
2022年の振り返り - console.lealog();
まーた今年も終わってしまう！まだ何もしてないのに！ というわけで、今年もいつもの振り返りを。 やってたこと なんだかんだReact、なんだかんだNext 自分から選ぶことはもうないやろなって思ってても。本業でも副業でも、やっぱり触れる機会が多かった。 ただなんというか、既にReact/Nextで作られてるけど、メンテできないから助けてほしいとか、選んだものの自信ないから手伝ってほしいとか、そういうのが多かった。 からのコレね。 最近のフロントエンドフレームワークに対する認識とお気持ちの整理 - console.lealog(); とはいえ、まだまだ「これからReactはじめます！」っていう層もいるやろうし、もうしばらくは稼げるネタとして付き合っていく必要はありそうかなって感じ。 個人的には、SolidとかSvelteとか他の選択肢が充実してきて、React一択ではないっていう意識がもう少し
最近のフロントエンドフレームワークに対する認識とお気持ちの整理 - console.lealog();
久しぶりに、いわゆるポエムを。 新規・運用ヘルプを問わず、受託や副業でよくフロントエンドをやってるWeb屋の見解、そして手札のお悩み。 この先、また技術選定する際なんかにも参考になるかと思ったので。 React 「いまフロントエンドやるなら最初に覚えるべき！」は、もう過去の話かなーと個人的には思ってる。 Reactは`UI = fn(state)`なのが良い！とか言われるけど、あなたが必要としてるのは`UI = Component(props)`かもよって。 一昔前までは、たしかにあらゆる面で頭一つ抜けてる印象はあったけど、今はそうでもないか、その差はだいぶ埋まってきてると思ってる。（もちろん先行者利益みたいなところで、エコシステムはまだまだ優位な差があるかもしれんけど、それもあまり実感できたことはないし、いまからはじめる人はそんなんで困らんやろうし） 原初の時代からReactな案件をそれ
PreactにSignalsがきた - console.lealog();
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> ); さすがにこの時代になるといろいろ既視感もあって、すんなり読めるコードか
vercel/edge-runtime のコードを読む - console.lealog();
初手から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
2021年の振り返り - console.lealog();
子育てしてたら一日が終わってて、それを続けてたら一年が終わってた、そんな一年。 おかげさまで、👼🏻は1歳半の元気ざかりで何よりではある・・が、思ってたより大変すぎる！いやほんとまじで（ やってたこと 脱SPA、からのMPA、からの・・・ なんでもSPAにするんじゃねぇ！という主張のその先 - console.lealog(); 「とりあえずReactでNext.jsでSPAでよろしく！」みたいにやってくる案件を、「ほんとにSPAにする必要あんのけ？😒」って切り捨てる係をやってた。 もちろん、ほとんどのケースにおいてSPAである必要はなかった。 ただし巨SPAではなくても、 いくつかのページは、SPAでやるべき多機能さ いくつかのページは、SPAでなくていいけど、ちょっとだけJSほしい いくつかのページは、完全に静的でいい みたいな複合ケースがほとんど。で、それをいい感じにまとめてやる
なんでもSPAにするんじゃねぇ！という主張のその先 - console.lealog();
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日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
AudioWorkletについて調べたメモ - console.lealog();
[WebAudio API] AudioWorklet の使い方 | g200kg Music & Software この大先生の記事を読んで、自分の知ってるWebAudio知識のアップデートをしときたいなーと思って調べたことのメモです。 なので重複する部分もあるけど、+ αな部分もあります。 20191129: あらためて読み直したけど、特に更新すべき部分はない そもそもAudioWorklet Enter Audio Worklet | Web | Google Developers `ScriptProcessorNode`の後継 重い音声処理をメインスレッドでやりたくないよね いちおうAudioスレッドでやってたけど、完全ではなかった 今度こそAudioスレッドだけでできるよ 2017年12月の記事なんかこれ・・時代を感じる・・。 コード まずは使う側。 // app.js
WebComponentsへの気持ち - console.lealog();
この記事では、 ReactやVueではなくWebComponentsだけを使いたい気持ちを胸に、とある社内プロジェクトをやってみての学び 巷にあふれるWebComponentsに対する見方への違和感 についてメモっておきます。 ただ「WebComponents」の語がもつ意味をきっちり定義してるわけではないので、そのへんは雰囲気で察してください。 そのせいで勘違いされがちな概念なんかも、知らんけど。 まずは巷にあふれる意見に対する気持ちから。 (React|Vue|Xxx)はもう古い、これからはWebComponentsだ！ 勝手なイメージですが、こういう認識の人いるよね・・？ 個人的には、「いや、WebComponentsはそういう技術じゃない」と思った・思ってます。 以下、ReactもVueもAngularも「ウェブアプリケーションを作るための技術」であるが、WebComponents
React x MobXな趣味プロダクトをTypeScriptでリライトしようとした - console.lealog();
React x MobXでできてる自分専用の音楽ストリーミングサービスがありまして。 冬休みなのでTypeScriptで書き直したりしてみようかなと思ってちまちまやってた。 ただ結局は自分一人しかコード書かないので、コスパに見合わないと判断して採用は見送った。 https://github.com/leader22/mmss-client/tree/topic/ts まあその過程で色々学びはあったので、忘れないようにメモっとく。 環境構築編 Webpackでコンパイル なにはともあれ開発環境を。 元がBabel x Webpackだったので、そこをまず変える。 npm install -D typescript awesome-typescript-loader そして`babel-loader`と差し替えるだけ。 TSはReactのJSXにも対応してるので、特に困る点はない。 ただWeb
MobXを使ったアーキテクチャについて - console.lealog();
いまさらですが、俺的Real world MobXです。 いちおう半年くらい仕事でも趣味でも触ってきてての今です。 あくまで1つの例ですが、どこかの誰かの何かの参考になれば。 その前に こんな風に使ってますを紹介する前に、もやもやーっと思ってることを箇条書きにしておきます。 俺が考えた最強のアーキテクチャ そんなものはない 声のでかいやつの言うことを真に受けるな 納得できない部分があるなら採用するな Reduxとの比較 Reduxでできたクソコードがあるように、MobXでできたクソコードもありえる 役割が薄い分、そのリスクはMobXの方が高い（設計力が試される）と思ってる コードの記述量は絶対に減るので、書き味は良くなる 書きやすさと無秩序は紙一重 Flux的なアーキテクチャを踏襲するべきか Action的なものを投げる必要はないが、投げてもいい Storeも単一でもいいし、複数にしてもい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
