4 ms·

> Instead of striving to be the fastest or smallest or whateverest, we explicitly aim to be the framework with the best vibes. Except that svelte advertises it

> Instead of striving to be the fastest or smallest or whateverest, we explicitly aim to be the framework with the best vibes. Except that svelte advertises itself constantly as being faster and with smaller bundle sizes. Which is a good thing. I don't buy that it priortizes 'good vibes' at the cost of those other things. If it's saying it prioritizes 'good vibes' and everything else, then that's pretty meaningless - they might as well say they're good at everything. Would also help to actually define what 'good vibes' are because I think every tool tries to make DX as nice as possible. I honestly dislike fluff like this because it conveys nothing and gives fodder for people to ignore practical evidence in favor of biased advertising i.e. someone's going to make a bullet point list about things they dislike, and someone will just point to this and say "nuh uh, you're wrong, they care about being user-friendly, it says so right here". Since we're talking about front-end frameworks, I still maintain that vue has some of the best documentation. I fell in love with vue 2 because the documentation did a great balancing act between being brief, simple, and somehow dense at the same time. In particular, I remember a page about it's comparisons to other frameworks that in a few paragraphs, gave a history lesson, simplified differences to barebones, explained the practical implications all in a way that put vue in a good light. It was much better than the angular and react docs at the time.

gmaster1440 3y ago
> Except that svelte advertises itself constantly as being faster and with smaller bundle sizes. Maybe this is a subtle difference, but I understood it as Svelte still caring about and prioritizing speed and bundle size, but not necessarily as the primary focus with the goal of being the smallest or the fastest.
shdh 3y ago
Svelte is better than Vue IMO
- Aerbil313 3y ago
  I love Svelte, but please make substantial comments on HN. Flagged.
pier25 3y ago
I agree but there's a difference between the DX vs the execution (how the thing runs internally). I believe the vibes thing refers to the DX, not the engine itself.
doctor_eval 3y ago
I gotta say, the “vibe” of the new $props syntax, to me, is awful. I love that I can just use export let prop; because it’s just JavaScript. The new runes syntax let { prop } = $props Is not. This just makes me incredibly sad. Like all things, everyone is going to switch to the new syntax because it’s shiny, even though it objectively has a greater cognitive load (and IMO, looks ugly). My components are going to start looking like Svelte, rather than JavaScript. The reason I prefer svelte over Vue is because there’s less to remember. Looks like I’ll be looking for a new framework after Svelte 5. Just like I did after Vue 3. Also, > Snippets are more powerful and flexible, and as such slots are deprecated in Svelte 5. Removing slots, which feel really natural in HTML, with snippets - that are expressed as JavaScript values passed to a component - honestly, I don’t see the prioritisation of vibe, here. These changes are going to make it so, so much harder to teach Svelte that I honestly feel despondent. I feel like svelte 5 has just totally forgotten that Svelte is supposed to feel like JavaScript. Super sad.
- __jonas 3y ago
  How is this new syntax not javascript? I’m not familiar with it but your example is just object destructuring no? What am I missing?
  - doctor_eval 3y ago
    Because it’s introducing a magic global compiler directive - $props - that’s unique to Svelte. Everyone knows what export let prop = 10 means. But what’s $props? It’s a magical invocation (literally, a rune) of a compiler directive. So while it’s valid JS, it’s actually a signal to the compiler, with special behaviour. It’s something you need to learn and understand beyond just JavaScript. Also, to your point, it’s not actually destructuring. This statement is declaring “prop” as a new property. And finally, this statement actually does export “prop” to a user of the component. But that’s no longer explicit.
    - __jonas 3y ago
      > Everyone knows what > export let prop = 10 > means. What? I mean that's technically syntactically correct JavaScript but it makes no sense outside of Svelte, and if the prop is not literally named prop like in your example here, it's much harder to understand what this is doing compared to taking a prop value out of a $props object (or rune or whatever), like you would in many other frameworks. I'm just a bit surprised because while I like Svelte I feel like all of is like this, it's all technically JavaScript syntax but all of it is magic that only works through the Svelte compiler, and this new syntax actually looks slightly less so to me, although I wouldn't say I prefer it.

gmaster1440 3y ago

> Except that svelte advertises itself constantly as being faster and with smaller bundle sizes. Maybe this is a subtle difference, but I understood it as Svelte still caring about and prioritizing speed and bundle size, but not necessarily as the primary focus with the goal of being the smallest or the fastest.

shdh 3y ago

Svelte is better than Vue IMO

Aerbil313 3y ago
I love Svelte, but please make substantial comments on HN. Flagged.

pier25 3y ago

I agree but there's a difference between the DX vs the execution (how the thing runs internally). I believe the vibes thing refers to the DX, not the engine itself.

doctor_eval 3y ago

I gotta say, the “vibe” of the new $props syntax, to me, is awful. I love that I can just use export let prop; because it’s just JavaScript. The new runes syntax let { prop } = $props Is not. This just makes me incredibly sad. Like all things, everyone is going to switch to the new syntax because it’s shiny, even though it objectively has a greater cognitive load (and IMO, looks ugly). My components are going to start looking like Svelte, rather than JavaScript. The reason I prefer svelte over Vue is because there’s less to remember. Looks like I’ll be looking for a new framework after Svelte 5. Just like I did after Vue 3. Also, > Snippets are more powerful and flexible, and as such slots are deprecated in Svelte 5. Removing slots, which feel really natural in HTML, with snippets - that are expressed as JavaScript values passed to a component - honestly, I don’t see the prioritisation of vibe, here. These changes are going to make it so, so much harder to teach Svelte that I honestly feel despondent. I feel like svelte 5 has just totally forgotten that Svelte is supposed to feel like JavaScript. Super sad.

__jonas 3y ago
How is this new syntax not javascript? I’m not familiar with it but your example is just object destructuring no? What am I missing?
- doctor_eval 3y ago
  Because it’s introducing a magic global compiler directive - $props - that’s unique to Svelte. Everyone knows what export let prop = 10 means. But what’s $props? It’s a magical invocation (literally, a rune) of a compiler directive. So while it’s valid JS, it’s actually a signal to the compiler, with special behaviour. It’s something you need to learn and understand beyond just JavaScript. Also, to your point, it’s not actually destructuring. This statement is declaring “prop” as a new property. And finally, this statement actually does export “prop” to a user of the component. But that’s no longer explicit.
  - __jonas 3y ago
    > Everyone knows what > export let prop = 10 > means. What? I mean that's technically syntactically correct JavaScript but it makes no sense outside of Svelte, and if the prop is not literally named prop like in your example here, it's much harder to understand what this is doing compared to taking a prop value out of a $props object (or rune or whatever), like you would in many other frameworks. I'm just a bit surprised because while I like Svelte I feel like all of is like this, it's all technically JavaScript syntax but all of it is magic that only works through the Svelte compiler, and this new syntax actually looks slightly less so to me, although I wouldn't say I prefer it.