Maurizio Cescon

@cesmaur.bsky.social

Frontend tech lead at @EU_Commission

this is your weekly reminder that: ⚪ intelligence != wisdom ⚪ correctness in sphere <a> doesn't port to <b> ⚪ being unchallenged leads to very dark places ⚪ be very careful of trajectory and dhh is racist much love my friends

A couple of weeks ago at @perfnow.nl I gave a talk called "Fine-grained everything". It's about @svelte.dev (obviously), and the new frontiers of framework-land, but it's also about some stubborn misconceptions in web performance circles Gift link: conffab.com/presentation...

Fine-grained everything

<p>Modern frameworks like Svelte are fast thanks to signal‑based fine‑grained reactivity, but performance is more than 60fps. This talk covers new approaches to build fast, reliable, data‑efficient ap...

conffab.com

another async feature: out-of-order rendering. this means a component can begin rendering children while it's awaiting data. demo stolen from @ryansolid.bsky.social — these components should render in 3 seconds, but they only take 1: svelte.dev/playground/2...

Out-of-order rendering • Playground • Svelte

Web development for the rest of us

svelte.dev

rich harris@rich-harris.dev · 9mo ago

today we landed a @svelte.dev feature i'm pretty stoked about — we call it 'forking', and it lets you run state changes offscreen and later choose whether to commit them (e.g. user hovers on a link, preload data in case they click) - docs svelte.dev/docs/svelte/... - demo svelte.dev/playground/a...

svelte kinda stopped marketing performance as a feature because "react is fast enough" but... it just isn't. so many of these stories. maybe the compiler will fix it. anyway the real money quote is "Features that took days in React could be built in hours with Svelte". many such cases!

passage from the quoted post:

---

Why React Wasn't Working for Our Graphic Editor

React is excellent for many applications, but it presented specific challenges for our graphic editor:

1. Performance with complex visuals: When users edit designs with hundreds of SVG elements, React's approach to comparing the entire component tree became noticeably slow, especially during real-time editing.

2. Too many unnecessary updates: A particularly painful example was text editing. When a user changed a single character in a text box, React would re-render not just that text element but often dozens of unrelated components. Despite our team spending weeks implementing memoization and careful prop management, we couldn't eliminate the stuttering.

3. Delayed visual feedback: React's batched state updates sometimes created noticeable delays in visual feedback, which is particularly problematic in a design tool where users expect immediate, pixel-perfect control.
davipon@davipon.bsky.social · last yr.

The guest blog post is finally out! Huge thanks to Chris and Budi for accepting my proposal. Hope you have a good read. sveltejobs.com/blog/increme...

Running a project pilot on dropping component / service / directive file and class suffixes in a huge enterprise app (required just some eslint adaptions in our case)! So far only positive feedback! I hope we'll make it... and end up with "We Are Never Ever Getting Back Together"! 😂 #Angular

🚀 Meet Angular v19 ‣ Incremental hydration ‣ Server route config ‣ linkedSignal, resource, renderEffect ‣ Auto CSP ‣ Unused import reporting ‣ Standalone by default ‣ Enhanced theming ‣ Time picker ‣ 2D drag & drop ‣ Many codemods to modernize your code Much more! blog.angular.dev/meet-angular...

Meet Angular v19

In the past two years we doubled down on our investment in developer experience and performance — in every single release we’ve been…

blog.angular.dev