Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Svelte 5: Runes

svelte.dev

Post reply on HN
Print view View original

351–360 of 404 posts

Re: Svelte 5: Runes

#351

Post by jinushaun »

gedy wrote: post #254
hajile wrote: post #122

Earlier quoted context omitted.

Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Most of us deal with average teams where half the devs are at or below par while managing very tight deadlines. The spaghetti from everything in the whole system mutating always comes back to bite. You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind…

> Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Yes, but having gone through this at previous companies, the average/non-front end specialist developers definitely had an easier time understanding 2 way binding ala Knockout, MobX, Svelte, etc. The Redux style stuff was only pushed by the frontend brainiac types.

More like so easy to shoot themselves in the foot. React’s one-way data binding philosophy is defensive position against spaghetti code.

Re: Svelte 5: Runes

#352

Post by jaeming »

Yeah, you know that thing Vue did with the composition API that a bunch of their users didn't like and then subsequently turned to Svelte over? Well, it turns out they were right and we're going to do the same thing.

Re: Svelte 5: Runes

#354

Post by vjerancrnjak »

EvanYou wrote: post #340

This is (surprisingly) almost identical to the Reactivity Transform explorations we did in Vue: https://vuejs.org/guide/extras/reactivity-transform.html let count = $ref(0) const double = $computed(() => count * 2) watchEffect(() => { console.log(double) }) We started experimenting with this ling of thought almost 3 years ago: - First take (ref sugar), Nov 2020: https://github.com/vuejs/rfcs/pull/228 - Take 2, Aug 20…

All of this looks like MobX

Re: Svelte 5: Runes

#355

Post by troupo »

recursive wrote: post #343
troupo wrote: post #337

Earlier quoted context omitted.

jQuery: returns an array-like structure that is consistent with the rest of the API whether it's one element returned, no elements are returned, or many elements are returned. DOM: - few if any DOM methods work on an array of elements. Or even on a NodeList - `querySelector`: returns null if not found, Element if found. Throws if there's a selector syntax exception. So you have to wrap it in a try/catch and in a chec…

I have never heard of a case where I need to care about selector syntax errors. If it ever happened, I guess I'd just use a try? Much of the time "checking for null" consists of adding a single question mark. document.querySelector("div#options")?.setAttribute("hidden", "true");

> If it ever happened, I guess I'd just use a try?

Exactly, you'd "just use a try". Instead of not using it.

> Much of the time "checking for null" consists of adding a single question mark.

Note: this API was introduced way before the `?` was even thought of. Which tells you a lot about the quality of the API.

So. Just for the simple task of selecting elements:

- you have to different APIs for "select 1 element"/"select multiple elements"

- these APIs differ in their behaviour. They can also throw

- almost none of the DOM APIs work with the return values of one of those APIs (e.g. your example stops working the second you use querySelectorAll)

On top of that:

- none of the DOM APIs can be chained, or combined in any meaningful way, so if you want to do more than just call one method, you're up for some very verbose and tedious boilerplate

Re: Svelte 5: Runes

#356

Post by codelikeawolf »

There's a lot of comments here so I may be asking a question that was already answered, but will the runes be explicitly importable in non-Svelte files? Or does it use an approach similar to testing frameworks like Jest and Vitest where you have access to them as globals? I'm thinking of the implications for TypeScript. I usually opt out of globals and import explicitly when I can.

Re: Svelte 5: Runes

#357

Post by codelikeawolf »

Phillippe wrote: post #229
Phillippe wrote: post #224

Earlier quoted context omitted.

I love all the changes except that single thing with let count = $state(0); I'm just brainstorming here, but what about an optional $reactive rune where everything in that is reactive by default? $reactive(() => { let name = 'world'; }); vs let name = $state('world');

Maybe reuse the $:{} here, tho that would probably be really confusing for svelte 4 developers lol $:{ let name = 'world'; }; vs let name = $state('world'); $: is valid javascript right? So that should also work in .js/.ts files I assume

I think the reason they didn't opt for this approach is that putting stuff in a {} block creates its own scope, so any variables declared within that block are inaccessible from outside said scope.

The $: label syntax is valid JavaScript, but allowing scoped variables to be accessible outside of scope is very invalid JavaScript.

Re: Svelte 5: Runes

#358

Post by madacol »

onsclom wrote: post #255
davedx wrote: post #91

Earlier quoted context omitted.

For sure. Look at this Svelte 5 example: let time = $state(new Date().toLocaleTimeString()); $effect(() => { const timer = setInterval(() => { time = new Date().toLocaleTimeString(); }, 1000); return () => clearInterval(timer); }); Current time: {time}

This example is a bit strange to me. I wonder if `$effect` will actually replace all usage of `onMount` and `onDestroy` for Svelte. In Solid you could totally do these things with `useEffect` too, but they chose to keep `onMount` and `onDestroy` (which they call `onCleanup`) to make this kind of thing more simple. Example: https://www.solidjs.com/examples/counter `onMount` and `onDestroy` feel like really useful, dep…

They don't claim they'll remove `onMount`.

They claim most (but not all) of current usage of `onMount` will be better off using `$effect` instead

Re: Svelte 5: Runes

#359

Post by josephg »

rmilejczz wrote: post #153
josephg wrote: post #126

Earlier quoted context omitted.

> What HAS been a problem is getting good code out the door as fast as business needs. MOST React code is disposable based on the whims of the company. I know you're right; but this still deeply saddens me. I want well crafted software. I want the code I write and the code I depend on to be made in a way that holds reverence and honor for the craft of software engineering. I don't want to be running crappy, badly per…

I don’t know about you, but I have bills that need paid. I’ll clutch my pearls over something else

I have a friend who's a car guy. He bought some fancy Mazda that he just adores and he takes to the track sometimes.

He's not pearl clutching. He's in love with that car. He keeps it immaculate and he has a sparkle in his eye when he talks about it.

Some people are the same with furniture. They buy super expensive, custom stuff and look after it for decades. Not me! All through my 20s I didn't care at all and my various homes were full of cheap ikea furniture. I had bills that need to be paid, and why should I pay more? Most of it is probably in landfill by now.

I'm not an expensive furniture guy. And I'm not an expensive car guy - I don't even own a car. But I am into software. Software is kind of my thing. When software works fast and well, when its clean, reliable, tested and memory efficient - its the best. I know deep down everything is right in the world.

And, obviously, I hate disposable, cheaply made software. I hate when software runs slowly. I hate seeing my expensive computer working hard to do basically nothing because of lazy code. And I hate running into stupid, avoidable bugs. I don't want to create work like that. And I don't want to use with software like that. When software is laggy and unreliable, my skin crawls and I feel disgusting.

Intellectually, I recognize that there's a place for the cheap ikea furniture equivalent in software. But craftsmanship matters to me. And I personally, hate bad software and I don't want it on my computer.

Does that make me a pearl clutching, elitist snob? Sure, whatever. But I'm done acting like I'm sorry for what I like.

Re: Svelte 5: Runes

#360

Post by ricardobeat »

steve_adams_86 wrote: post #332
ricardobeat wrote: post #320

Earlier quoted context omitted.

And lose most of the 'reactivity' since you'll now be doomed to manually track your own dependencies everywhere.

Can you explain why that is? I find hooks are flexible enough that I tend to be able to implement more sane and manageable reactivity, not the opposite. Maybe I’m misunderstand your issue, though.

I’m referring to the dependency array you pass into hooks, and any hook being able to trigger updates.

With classes there was no manual dependency tracking (except comparing old props?) and all re-renders were triggered by state, context or prop changes.

Not making a judgement either way, just stating the trade-offs.

Post reply on HN