Ripple – A TypeScript UI framework that takes the best of React, Solid, Svelte

4 months ago (github.com)

It's great people experiment. Yet, after a quick glance the framework seems to break expected semantics for no gain? For example: the "component" construct auto-renders the JSX within the brackets instead of being a function that "returns a view as value" (if I understood correctly). I'm cool with breaking the "f(x)=>UI" but what for? The TS and VS Code integration is all fine and good but what's the gain of using JSX (again) instead of the beloved HTML-like Svelte markup? Have people ever loved JSX? Nostalgia maybe? Again, I'm all for tearing down the house but shouldn't we get more elegance or expressive semantics in return?

Still, great he did it I just hope he'll be bolder next time! Of the 7 mentioned features 3-4 are not actually about the language but minor tooling hook ins (prettier, VSCode,) ... maybe that's the wrong focus.

Either way, the strong similarity with other JS/TS frameworks (semantics & syntax) suggests that for really new ideas the community should look elsewhere? Perhaps Clojurescript or Laravel (PhP) ...

  • I love JSX and hate HTML template syntax, so there's at least one person.

    What I like about JSX is that you can reuse all of the control flow primitives from JS. You have if, for, map, filter, flatMap, etc. if you want a new combinator, just write a function as you would for any other type of data transformation.

    I consider this one of the biggest advantages of React compared to the approach of having separate templating and scripting languages.

  • I've never liked JSX, much prefering HTML like (Vue, Svelte), but I do like this template syntax. On reading it makes sense to me in a way that JSX never did, feeling squashed into the 'language'.

  • HTML is an implementation detail and JSX is a syntax for describing UI components. For example JSX can be reused across different contexts such as for React Mobile. It just so happens most usage of JSX is used to render HTML so it superficially appears to be writing HTML syntax. But I prefer JSX because it allows me to write UI HTML components as pure functions, without having to syntactically write out actual functions in whatever programming language I'm using.

    • Fair enough. IMO the best solution is/was always hiccup (cljs) since it has no extra syntax to the core of the language (vectors/maps)

In case people don't know who the author is... Dominic is the original author of Inferno, was part of the React team, and also was a major contributor to Svelte 5 (the runes thing).

I don't mean to sound reductive, but there's something exhausting about the conceptual approach that necessitates importing array primitives from a package. The react meets svelte concept seems cool, but maybe this particular syntax is just not for me.

  • The array primitive seems to be a reactive version of an array; which seems to be weird since a basic primitive like an array should be able to be made reactive by default.

    Tangentially Svelte also provides some reactive primitives, namely SvelteMap and SvelteSet [0]. But I've never had to use any of them.

    [0] https://svelte.dev/docs/svelte/svelte-reactivity

If you want something that is similar but looks better and more mature, check out Mint (mint-lang.com - I'm the author)

> Now given $startingCount is reactive, it would mean that $count might reset each time an incoming change to $startingCount occurs. That might not be desirable, so Ripple provides a way to untrack reactivity in those cases: ...

This automatic reactivity thing is really what makes these frameworks more complex than they need to be.

I'd much rather handle all re-rendering calls manually. It's more work for me, but at least I don't work with a chain-reacting foot gun that's hidden in a black box.

  • Frameworks handle more than 95% of cases to make your life easier. For the corner cases, you can write custom logic yourself outside the framework.

    > ...handle all re-rendering calls manually.

    Have you considered writing web components? With them, you handle the rendering logic and lifecycle yourself.

Since this is marked as a departure from HTML and has it's own syntax, I think this is a good point to improve upon JSX.

- Remove curly braces from props and children

    <MyComponent name="Joe" onClick=(() => canBeInParanthesis()) />
    <div>userName</div>
    <div>"Text contents"</div>

- Add punning (like how { age: age } becomes { age } in JS)

    const age = 40;
    <MyComponent age />/
    <MyComponent active=true />  // explicit boolean attributes

  • Or (hear me out) we don’t need any DSL that doesn’t add anything while making code just more verbose compared to Js/ts.

  • How about... inlining children:

        const age = 40;
        const children = [<div ~ "Moe" />, <div ~ "Larry"/>, <div ~ "Curly" />];
        return <div age ~ children />;
    

    Rationale: single child elements are ubiquitous in web dev, but most JSX formatters will require 3 lines of code even if there's a single child.

This would have been very exciting 5 years ago. Today I’m longing for reducing lock-in to specific frameworks, and using the platform more directly.

I feel like these functional GUI renderers are all trying to make JS something it is simply not.

I want to render my view with instances of classes as a model.

  • > I feel like these functional GUI renderers are all trying to make JS something it is simply not.

    I wholeheartedly agree.

    I liked React's support for function components and hooks are quite a treat, but still I think class components are a far better fit for complex components that have logic and state. I'm seeing all this complex logic being expressed as a convoluted mix of hooks and I can't help myself thinking it would be far cleaner to have a class where this logic was handled eith plan old inversion of control.

  • Please keep OO away from web dev. The mess is bad enough and adding OO will only increase coupling.

    • Calling OO to increase coupling is a weird take in a world where React's "functional components" and similar patterns encapsulate their state and rendering pipeline.

      1 reply →

What's the benefit of this, over just using proxies [1][2] to manage state? You then get to mutate objects however you want without having to use templating.

    const state = proxy({
      dur: 1,
      count: 141
    });
    const incDur = () => {++state.dur};
    const decDur = () => {--state.dur};
    const incCount = () => {
      ++state.count;
      setTimeout(incCount, 100 \* state.dur);
    };
    return (
      <div>{state.count}, {state.dur}</div>
    );

Is it specifically proxies only work on objects, and in this approach you can have direct variables?

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://valtio.dev

Looks quite nice, I'm not 100% sold on having flow exposed (for, if) and plain text always escaped (wrapped in {''}), I suppose at least it encourages not having magic strings everywhere. There's some other details that look interesting like the @use feature. I like the reactive prefix concept but having had so many reactive headaches I'm interested in how this plays out. Overall it's a wait and see project for me with no clear must haves, at least right now.

  • I really like having to escape all the plain text. I think all the React-like code I’ve written has been at least 90% code and tags, not plain text, and the lack of escaping occasionally causes bugs (usually printing the name of a variable instead of its value).

    • Fair enough, on reflection I think I would lean towards escaping both as a principle of least surprise. There's something a bit 'doing magic' about the way it reads at the moment.

I just want to say, I love it when I get laid off sometimes and I have the time to pursue some of those side project ideas. Kudos. I’ll have to take it for a spin on my next project.

Honestly, from a person who has been part of both React and Svelte, this feels like the (for the lack of a better word) bastard child of both. It looks like a very opinionated, mish-mash of Svelte and React.

Kudos to the dev for working towards realizing their ideas, but Svelte and Solid have essentially solved front-end frameworks for the better part. People still hung up on React happily use Next in prod, people who want simple SSG go towards Astro or Hugo, people who use Svelte/Solid will not switch because this simply doesn't seem to improve upon anything that either do, so I really don't see what this solves in the slightest.

I very happily use Svelte for work, for my personal projects because of fine grained reactivity through signals, no bs syntax that feels like writing "just" HTML & Typescript, mature tooling and great performance. I have no interest switching to something that makes me feel like I'm stuck in the middle of a better React and a worse Svelte.

So much negativity... I for one really like the look of this, I've been yearning for something that's not the current crop of frontend frameworks to see where we go. The author definitely has the past experience to build something like this based on being a core member of both Svelte and React. It'll be cool to see where this goes, though I wish we had more Elm-like frameworks (that don't lock down the compiler).

I noticed Dominic mentioned he is "between roles" in the README; I suppose that implies he left Vercel? Does it mean he is leaving the Svelte team too?

  • I left Vercel a few weeks ago and I left the Svelte team earlier this year.

    • Thank you for all your contributions! Svelte 5 is a blast.

      If you don't mind me asking, why did you leave? What do you plan on working on going forward?

      2 replies →

I have always been attentive to trueadm's work. But this time, it's really something else. I think it's an excellent synthesis between React and Svelte.

I think I enjoy how explicit solid is about all this stuff. I can generally follow why a random thing does or does not update (with some work)

The ability to output JSX between native control flow is the real cool part here's, imo. Besides that it looks kinda like Rezact.

one framework to rule them all!

given how much code is being written in AI today (for better or for worse), something like this might not be the worst thing

https://xkcd.com/927/

  • This isn't proposing a standard, it's a new framework which takes inspiration from the other mentioned projects, while choosing a different set of trade-offs. This is just what it looks like when people try new stuff, and I don't think the snark of the comic is appropriate.

    • if frameworks are specifications, then a new framework is definitionally a new standard. it’s not an ISO or ANSI standard. but the point of the comic is, there are 10 web frameworks, we need one to be the best of all of them! there are 11 frameworks.

      1 reply →

You need to drop your source code into some LLMs and ask for a security review - there's lots of holes.