2024-10-03
後追いで見てると一部はVite関係なく完全に自分のところの宣伝みたいなムーブしてるのもあるよな 歴代で一番保護者観覧が近かったのではないかと思われる
色鬼遊びで負傷した足を引きずりつつ頑張ってました
https://gyazo.com/0154f5077101f606fc0d1a211d94a9f9
一緒に視聴して参加する体験を尊重しているのでこれで壊さないかは懸念あるけど…
『Selected Ambient Works Volume II (Expanded Edition)』は、明日発売！
https://pbs.twimg.com/media/GY963XjbAAIq699.jpg
@migraine_blue: エイフェックス・ツイン王決定戦バックレ多すぎて、急遽会場の観覧者で、エイフェックス・ツイン王になりたい人たちが参加することになった @Rich_Harris: @LeaVerou @dfabu Not really. Firstly I reject the premise that pushing the burden onto users is desirable — if a tax has to be paid, it's better for frameworks to pay it. But beyond that, it's not just about the fact that WCs make the platform so much more complex and so much harder to learn. It directly affects users in subtle ways. For example if you want to clone some DOM to build a component you can just do fragment.cloneNode(true), right? Not so fast — if the DOM contains a custom element, the clone won't be assigned the correct class until it's appended to the document, and if you set properties in the meantime it won't trigger accessors (they'll shadow the prototype instead, which is very bad news). It's a real head-scratcher of a bug.
It turns out that if you use document.importNode(fragment, true) instead, it works correctly. Not that you'll casually learn that while reading MDN — this is the kind of knowledge that is only acquired with a side helping of battle scars.
But there's a catch! importNode is roughly 30% slower than cloneNode in our testing. That's unacceptable overhead given that most people aren't using custom elements (and certainly not that often). So we opted to pay a different price — the compiler adds a flag to the generated code, and the flag tells the runtime which to use. That's extra code, and extra work (albeit a miniscule amount), that would be unnecessary if we didn't have to think about this nonsense.
Having the bug? Tax.
Figuring out the solution? Tax.
Implementing the fix? Tax.
Documenting the code for our future selves? Tax.
Adding regression tests? Tax.
Running those tests on every CI job?
Shipping extra code? Tax.
Doing more work in a hot code path? Tax.
And that's just one example. There are others. The bottom line is that framework authors could ship sooner, and could ship leaner and more reliable code, were it not for this ill-designed primitive with its myriad edge cases.
自分の好きなものの解像度が非常に高く、新しい技術も実践的に試してみたり、更には自身もポッドキャストを始めていたりと、同じ仲間として学びとなる部分が多い方です。
投稿してきました
何のために役に立つの？って観点は大事だと思うけど、理解する気がないままでそこに突っ込むのは危ういなと思うようになった ド」してることに今気づいた
トップページ刷新で消えるから見納めかも
https://pbs.twimg.com/media/GY8BWoEbAAAkfeZ.jpg
https://pbs.twimg.com/ext_tw_video_thumb/1841795660674387968/pu/img/tkhPFz9bJ8yPzGIC.jpg
大石真翔さん、とても愛されていた人だとわかる所属ラスト興行だった https://gyazo.com/ba2aa888aae39bf1f3fdf4b2e232831c
赤色背景読みづらい
https://gyazo.com/1ff35fd2bbe578293a85b9acade4ec78
Rustで理解するよりもWatで書いたほうがいいよと有識者アドバイスをもらう 以下有識者による教材紹介
色々と収集開始
https://gyazo.com/f5d856ac95b32de6991deb44fa1aabae
管理が雑になって混沌が生まれないようにしたい…
https://www.youtube.com/watch?v=cZXLeQi0pb8
https://gyazo.com/e477e6da3ccdf8c3b4cf84ae6bff5854
解像度の低いEvan Youの画像.icon解像度の低いEvan Youの画像.icon解像度の低いEvan Youの画像.icon解像度の低いEvan Youの画像.icon
木村拓哉 勝負だ！.icon
解像度の低いEvan Youの画像.icon解像度の低いEvan Youの画像.icon解像度の低いEvan Youの画像.icon解像度の低いEvan Youの画像.icon
阿部寛の顔面透過.png.icon 阿部寛の顔面透過.png.icon 阿部寛の顔面透過.png.icon 阿部寛の顔面透過.png.icon
木村拓哉 勝負だ！.icon
阿部寛の顔面透過.png.icon 阿部寛の顔面透過.png.icon 阿部寛の顔面透過.png.icon 阿部寛の顔面透過.png.icon