Conquering JavaScript Hydration
SSR was never the problem. The problem was, and still is, the client-side hydration. For all the effort we've put into Server Rendering on the web, we still haven't found a universally good solve for balancing the developer costs with end user costs. Regardless of how we optimize for server rendering, hydration hangs over us. That JavaScript that needs to be run on page initialization, that makes
2021 JavaScript Rising Stars
Welcome to the 6th edition of the JavaScript Rising Stars, our annual round-up of the JavaScript landscape. If you took a break to escape the JavaScript fatigue in 2021, you are in the right place! We'll be talking about meta frameworks, the need for speed and all-stars are joining forces at tech companies. But first, we have a new "champion" this year, that no one expected, and it's a command lin
JavaScript Framework TodoMVC Size Comparison
Size in JavaScript Frameworks is actually a pretty tricky thing to estimate. Even nailing down the size of runtimes is unclear. You might go to bundlephobia.com but the size there can be misleading. With tree-shaking not all code is included. Bundlephobia also doesn't include sub-modules. Things like svelte/motion or preact/hooks. There isn't only the size of the runtime but the size of the compon
Components are Pure Overhead
A couple of years ago in the The Real Cost of UI Components, I explored the cost of components in JavaScript frameworks. I asked whether components were just overhead? And the answer was: it depends. The Virtual DOM library I tested, ivi, had no issues handling more components. But Lit and Svelte were dramatically worse. They scaled back to almost React levels of performance as I broke them down t
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What Web Frameworks Solve And How To Do Without Them (Part 1) — Smashing Magazine
https://www.solidjs.com/
GitHub - solidjs/solid: A declarative, efficient, and flexible JavaScript library for building user interfaces.