thiagolino8.bsky.social
Full-Stack Dev 💻 | Tech enthusiast 🚀 | Curious mind 💡
Exploring innovation, digital culture, and the future of tech 🌐
Here to connect, learn, and share insights ✨
https://www.linkedin.com/in/thiago-lino-gomes-5812581bb
https://github.com/thiagolino8
100 posts
21 followers
70 following
Regular Contributor
Active Commenter
comment in response to
post
esbuild is not required for rollup, but both rollup and esbuild are required for vite
comment in response to
post
It's really strange that a library that doesn't have an official framework is so afraid to recommend the main way of creating apps nowadays
Meanwhile, even libraries that have an official framework are still strongly recommending Vite
comment in response to
post
It's interesting that at the moment React comes with this solution, Svelte is moving away from it.
comment in response to
post
But it's still like a version of the Svelte 3 compiler where instead of optimizing what is reactive it tries to optimize what is not reactive, which is a much more complex job
So there are still some common cases where it is not possible to optimize and some gotchas that disable optimization
comment in response to
post
It's really impressive, it solves like 60% of React's problems
comment in response to
post
I also found writing in Svelte made me understand HTML and CSS so much better. If I had to I could not use the framework at all and still make a very functional site.
I didn't feel that way at all after writing React for 2 years.
comment in response to
post
The js is vanilla except for the few explicit runes, the html is also pure except for the interpolations and control flow
The css is pure except for the global keyword
You can literally copy code from codepen and paste it into a component or import a .html file as a svelte component
comment in response to
post
Among the syntaxes that unite js and html out there, I think svelte is the one that tries the hardest to maintain the separation between what is the base language and what is an addition
And tries to add as little as possible to achieve its goal
comment in response to
post
I believe the opposite
The further a superset moves away from the base language, the more difficult it becomes to integrate with the ecosystem
This is why TypeScript won, because it adds only the minimum necessary to accomplish a specific goal
comment in response to
post
But for sure the best part is replacing all the react-<insert-lib-name> libraries with just <insert-lib-name>
comment in response to
post
The list goes on
That's without me adding the APIs that simply have simpler equivalents
comment in response to
post
- state setter
- component function boilerplate
- memo
- useMemo
- useCallback
- dependency arrays
- CSS-in-JS lib
- context provider components
- Framer Motion
- babel bullshit (mandatory for react compiler)
- class component (mandatory for error boundaries)
- fragment
- lazy
- state management lib
comment in response to
post
Yup, do it sometimes
It's mostly pressing delete
comment in response to
post
But the code using $derived was just a joke, the correct place for reactive asynchronous code (for now) is in $effect
comment in response to
post
And you should use AbortController even with an $effect
That's why it's been added to the $effect api
github.com/sveltejs/sve...
comment in response to
post
AbortController is for any asynchronous code, not just fetch
Just listen for the abort event
developer.mozilla.org/en-US/docs/W...
comment in response to
post
You can, technically, use $derived
But please, don't
comment in response to
post
Petition for everyone to switch to Svelte-style adapters. It's so far ahead of the other solutions
comment in response to
post
This looks like a very bureaucratic version of zustand
comment in response to
post
What do you mean by 'Zustand fundamentally doesn't like this'?
You can simply do useStore.getState() or useStore.setState
comment in response to
post
Ok, reading it again it seems that what you want is the opposite of immer
comment in response to
post
Immer
comment in response to
post
Elaborate
comment in response to
post
Elaborate
comment in response to
post
This would require static analysis, meaning subscriptions and assignments would only be reactive within the scope of the variable creation
Basically the same limitations as Svelte 3
comment in response to
post
Isn't the difference between signals and observables that signals are subscribed to while reading and that signals are based on pulling updates while observables are based on pushing updates?
In fact, your implementation is even compatible with Svelte's store contract for observables.
comment in response to
post
@rich-harris.dev Looks like we're back to Svelte 4 and '$derived.by' is the new '$:'
@thomas.rocks Time to rewrite runed with this pattern
comment in response to
post
Damn!
You got quite the hater right there
comment in response to
post
That silly error prevented me from paying attention to the rest of the code
Now it's working as expected, thanks
tinyurl.com/58u53ed4
comment in response to
post
The error message doesn't really help much
comment in response to
post
I tried a thing, but it didn't work
tinyurl.com/bd4rbx7z
comment in response to
post
In the end I ended up creating my own solution that better meets my preferences and needs, with bindings for react, svelte, vue, solid and preact
I'll publish it early next year probably, after polishing it for general use.
comment in response to
post
But of course zustand also has its problems, such as not being able to infer the type of the store, having to declare the actions mixed with the states, no derived state and so on
comment in response to
post
I much prefer zustand, where instead of subscribing to a specific event you can use a selector to listen for changes to a section of your store
In my opinion, if a code must be executed in sync with an event then that code should live inside the event handler
comment in response to
post
I tried it, but the typing uses some hacks and breaks very easily
Also, I hate the system of sending events as strings
comment in response to
post
Client Rendering has never been the meaningful bottleneck.
comment in response to
post
My top 5 is:
1. createSubscriber
2. Spring and Tween
3. transport
4. $app/state
5. clsx
comment in response to
post
- Compiler
At best it does a worse version of what the svelte 3 compiler did at the cost of forcing you to use babel
No matter how good the compiler is, it's not worth this
I've already moved on, I've seen heaven, I'm not going back to hell
Let me know when there's a version for esbuild, swc or oxc
comment in response to
post
I never really understood the appeal of jotai, I've always been more of a zustand guy
That said, it's a more complex API, no fine grain reactivity and it's a pain to use outside of the react world (even more so than runes, which need a compiler)
comment in response to
post
Data flow between multiple loaders is better in Sveltekit
I love all the functionality of sveltekit hooks
Sveltekit formActions are better
$app/state module > all those context hooks
Sveltetkit has better/more page options