Ethan Wolfe
Ethan Wolfe
@vipero07.bsky.social
But why
May 23, 2025 at 11:06 PM
No! I recently wrote out a very robust action leveraging runes and I'm very attached to it! J/K, looking forward to migrating it to this.
January 14, 2025 at 2:09 AM
It reminds me of one of my past jobs where the manager wanted to put the Julian date in the app version and build number.

I'd have just arbitrarily said "this is v1" if it was some higher ups saying no one understands this is production ready. This feels like a protest 🤣.
January 14, 2025 at 1:11 AM
All that to say, in my view, even though Unocss has introduced changes that broke my code, I don't think it's had many that broke contract and ironically was correctly at 0 (or maybe 1). As all I've really seen is new features, or fixes. This new version scheme seems off, can't put my finger on it.
January 14, 2025 at 1:11 AM
Finally the last number {Fix} changes when a fix happens (string to number that was supposed to be a number in the first place). Fix changes can be grouped with a minor change and minor and / or fix changes can be grouped with a major.
January 14, 2025 at 1:11 AM
I view semver as the first number {Major} changes when something the user currently has access to changes in contract in some breaking way, like a string to a number. The second number {Minor} is when a new feature is added, like a new endpoint, or property.
January 14, 2025 at 1:11 AM
So epoch aside, I don't see a difference (not beyond the appearance of "prod ready").
Personally though, the epoch concept seems unnecessary. As defined in his blog, this forces an epoch to roll over every 100 major versions (if it isn't done by someone's well defined whim).
January 14, 2025 at 1:11 AM
That being said, I find this versioning change kind of funny. To me, and probably most devs, I've always seen the uno major version as the version after the 0, meaning if that number changes I need to make sure my apps still appear correctly.
January 14, 2025 at 1:11 AM
or individual object states inside of a collection like when you want to trigger an effect when a single item changes. Say when you want to post back the single changed item, instead of the full list, on every change.
January 5, 2025 at 5:34 PM
Ya I've had similar issues I think depending on your use case you either want a collection state (when you want to just send the whole collection up to an endpoint on form submission for example)
January 5, 2025 at 5:34 PM
While I understand that JSX is just a DSL, it is no different from "a template language" which is a DSL for templating. It, like svelte's templates, will not run inside a browser. Plus svelte:element, in this case, allows to opt out of the {if} template.
January 5, 2025 at 3:48 AM
Svelte has been compiled since 3... their new signals from 5 wouldn't cause a reevaluation, and even since 3 any reevaluation stops at the component with changes (as in the parent changing wouldn't necessarily affect the children).
January 5, 2025 at 3:42 AM
I'm not sure the dom not updating when there is no changes affects much in this regard. The problem is react is still reevaluating every component, not that it is or isn't changing the dom. But as I said, similarly bad if components could be written for svelte, and they too wouldn't affect the dom.
January 5, 2025 at 3:39 AM
The same can be said for svelte's if else template syntax, as svelte:element opens up the litany of JS options just the same.
January 5, 2025 at 3:36 AM
Where svelte similarly mentions two methods, the in markup if else method, and the svelte:element method. Opening up every other way to achieve the same result in js that react has.
January 5, 2025 at 3:35 AM
The same is true for any framework, svelte included... svelte's if's are just a way to embed js if logic into the markup. However, the react docs show two methods for if / else. So when I say the standard, I mean it is what the docs, if nothing else, suggest. react.dev/learn#condit...
Quick Start – React
The library for web and native user interfaces
react.dev
January 5, 2025 at 3:35 AM
You can do the same in svelte in this case too, I believe the point was to show an if with components. Heck svelte could have a js ternary for text {condition ? "Content" : otherCondition ? "Other Content": "Fallback Content"}
January 5, 2025 at 3:30 AM
Learning svelte set is the same as learning a JavaScript set, but I think the dilemma you are running into has to do with how complex handing state mutation and reactivity is.
January 4, 2025 at 11:48 PM
Svelte element is intended for use to not have a bunch of if statements for example and would be easy to implement with a dictionary. svelte.dev/tutorial/sve...
<svelte:element> • Svelte Tutorial
svelte.dev
January 4, 2025 at 10:45 PM
The if component is worse. Every if has to be evaluated and any library can do it too. The switch however is basically the same thing. The react standard is to use a ternary and it is inarguably less readable.

A better way IMHO is to have a dictionary.
January 4, 2025 at 10:45 PM
Good advice. If using sveltekit, enhanced-img does this (and more) for you.

svelte.dev/docs/kit/ima...
Images • Docs • Svelte
Images • Svelte documentation
svelte.dev
January 4, 2025 at 10:27 PM
Honestly I think you could just get away with $state([]) instead of a SvelteSet. Set is useful if you were going to have duplicates but that should be avoidable by just having a group with no duplicates.
January 1, 2025 at 9:03 PM
SvelteSet is a signal just like anything made with $state. It's just that Set is a complex class that requires a more complex integration than a basic js object. It's curious that it doesn't seem to be working for you... 🤔
January 1, 2025 at 8:46 PM
Worth it just to learn and work with something different then. I do something similar with just starting new personal projects every couple of years. I'd probably pick astro just to play in it next time 😁
January 1, 2025 at 8:38 PM