//
sign in
Profile
by @danabra.mov
Profile
by @dansshadow.bsky.social
Profile
by @jimpick.com
AviHandle
by @danabra.mov
AviHandle
by @dansshadow.bsky.social
AviHandle
by @katherine.computer
EventsList
by @katherine.computer
ProfileHeader
by @dansshadow.bsky.social
ProfileHeader
by @danabra.mov
ProfileMedia
by @danabra.mov
ProfilePlays
by @danabra.mov
ProfilePosts
by @danabra.mov
ProfilePosts
by @dansshadow.bsky.social
ProfileReplies
by @danabra.mov
Record
by @atsui.org
Skircle
by @danabra.mov
StreamPlacePlaylist
by @katherine.computer
+ new component
Profile
Loading...
Tech enthusiast, passionate software engineer and hardcore dark mode advocate
Antoine








Loading...
One should make a quote-of-the-day-like API from inspiring Patak posts There is more and more good ones to pick from!
I want to talk about being a software engineering manager in a world where AI is changing everything all at once. First, change is hard on humans. Even good change is stressful. People are built for survival, which means: if you aren’t dying, keep doing whatever already “works”
It's not that bad of a point by itself, because you can now opt-_out_ of the reactivity if you somehow need to, and you get the ability to be more expressive with $derived.by in the template, but yeah
The main issue is about reactivity related to Svelte block, something hidden from the user before. Is an {#each} loop variable a $state? Is a snippet prop a $state? This requires either codebase layers digging or internal knowledge, which can only be mastered by tooling or time
Honest feedback about this after migrating everything in SC Pros: - Same mental model as in the script tag - Same syntax as in the script tag - Native syntax Cons: - More verbose (with deriveds), especially for simple things like `{let Component = $derived(icon)} - But the worst part for me is...
It's probably a tooling issue, though: the LSP should tell you if you miss reactivity, as it does in the script tag with state_referenced_locally. It successfully throws it as soon as you introduce a $state or $derived and depend on it in another {let ...}, but not with external data sources.
So yeah, TL;DR I *love* the feature and using it, but a tooling improvement would be welcome, if possible, to avoid having to _think_ about reactivity in the template! :D
I desperately need a big whiteboard in my office Planned for a year and still haven’t got my hands on one It’s very handy for things like–purely generic and hypothetical–software breakdowns and redesigns
...the "fear" of accidentally losing reactivity. With @const, reactivity was taken for granted (as for every state used in the template); now, you have to be careful about it. It's the other side of the coin of my "same syntax" pro-point: explicit reactivity made its way into the template.