Post

I like a lot of the syntax changes you’ve made. My one suggestion would be get rid of the {} from inside JSX tags and just assume everything is JS. The syntax reminds me of what I proposed with lightningscript.dev

The Swift inspiration! This looks very similar to a Swift + TypeScript hybrid I was toying with years ago, I love it

Oh what the heck, what is this, Svelte 3 but in a different universe? 👀

The syntax for children looks verbose {@fragment props.$children()} Other than that it looks good and I hope you keep exploring

I'm going to get rid of that, it will just be `<$children />` instead

Someday I really want to see a JS framework use a syntax similar to Swift result builders instead of JSX component App { let $count = 0 div { div { "Count: " $count } button( type: "button", onClick: () => $count++ ) { "+1" } } }

100%, and I started with a very similar style but it just doesn't get any love from the people I showed it to. The common complaint, which I don't buy, is that the closing element makes it more readable.

Im probably alone on this but I would rather write <elm>{()=>{ switch (x) { ... } }}</elm> And get out-of-the-box IDE/web support for the syntax, than <elm> switch (x) { ... } </elm> and need custom tools. Mostly because I'm a tooling/config minimalist.

You're not alone, and I'd say it's probably wiser to bet on ever-green knowledge too when the language already provides an alternative option

It’s only an alternative for this given scenario though. It doesn’t cover the other use cases of Ripple that I’ll cover later when I get time.

Ripple has support for the IDE with an extension that provides it all too. This makes for some other nice things, like try/catch/async and other stuff I've not yet documented for handling async

That's kinda my point, I don't want to install an extension to get syntax highlighting 🙂. Also won't work for GitHub/gist web. I know that with enough adoption things can end up being built in, but that has the chicken and egg of adoption being hindered by not working with existing ecosystems.

What's the motivation for Fragments? Their transform looks almost the same as a Component. If it's primarily a performance thing, I wonder if the transform could do this automatically instead of needing the explicit concept.

I've heard that feedback before, they're a way of creating JSX anywhere – as components can only be top-level in a module due to supporting styling via <script>

However, fragments are really useful for `<Component>` cases as forming the children prop to pass through (or $children in Ripple's case). We can't bass JSX as expressions, and you can't pass around statements, so it makes fragments required in these cases – just like Svelte 5's snippets.

How funny! You’re the one who snagged the "ripple" NPM package! No joke, I was working on component model I was calling Ripple earlier this summer that has a *shockingly* similar shape to your ripple. I really love how much further you pushed the syntax tho, esp the native JS control flow!

Amusing that it's written in JS, not TS.

Yep

For execution speed reasons? Writing JS is scary to me now.

Pretty interesting! I’m curious what the design purpose of how the JSX like syntax works within a component (not returning it). is there a reason or is it purely personal preference?

This is really cool! Looking at the source code, I can definitely see how Svelte influenced it 😄 You said in your other post that it doesn't use signals, what does it use? The code looks very signal-esque...

They're not two-way subscribed, only one way

Interesting! So sources have a reactions array, while effects don't know their dependencies? Or is it the other way around?