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.

For me it is the opposite. I dislike having imperative constructs pollute my otherwise declarative markup. To each their own I guess.

Don't you still have imperative constructs if you use Svelte? It's not like any web framework can remove the need to render things conditionally.

If you have `{#if cond}`, that's imperative programming, not declarative, it's just imperative programming using a different syntax.

Using a different syntax for a conditional/loop depending on the type of the data is odd when you think about it. Why should vnodes use one syntax and every other data type use another syntax?

I will grant that the C ?: ternary operator syntax is ugly. If C had had expression based if/else like Rust then maybe people wouldn't mind JSX so much.

Absolutely, and that's one of the reasons that, as much as I was enthusiastic about svelte, it still didn't quite hit the spot. Close but not quite there yet. It's neither html nor js. Still a bit confusing.

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).

Yeah, seems that he has the credentials for this type of a push

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)

Surprised I haven't seen this before. This looks quite good! I love the store, router and batteries default inclusion!

8 years and haven't hit 1.0, that's a bit of torture, no?

In the last 8 years, we had two kids and I have a full-time job, so Mint was/is a side project with virtually no marketing.

Yes, it is a bit of torture :) however I'm getting there. Context (https://mint-lang.com/news/context) was the last bigger feature before 1.0 which I'm planning to release this year.

I'm giving it a look but I can't really figure out much about the type system and how does it compare to TypeScript.

- The type system documentation is here: https://mint-lang.com/reference/types/type-system - in short it's a functional language at heart with a Hindley–Milner type system

- TypeScript syntax comparison is here: https://mint-lang.com/from/typescript

- The feature matrix which compares languages features is here: https://mint-lang.com/feature-matrix

I hope you find those helpful :)

Thank you, wonder why I couldn't find them.

edit: by the way TypeScript supports both ADTs (through tagged unions) as well as exhausting pattern matching (on tagged unions, but an alternative can be using `instanceof`).

Technically you can yes, but the language doesn't support it out of the box, you need to jump through hoops to make it work.

But you are right, I'll change TypeScript to say it's partially supported.

This looks really well thought out

"Why?" is not made clear.

I'd like to see as the first thing on the README.md why this is different and how it's better suited to the authors preferences.

> 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.

Sorry, wrong word. I meant “complecting” but as no one outside of Rich Hickey’s talks will understand that I reached for the wrong word.

OO conflates data and methods, which makes systems harder to test, reason about, and debug, because functions are less pure due to the “hidden” internal state of an object.

It also encourages heavy constructs that can often be replaced with trivial data structures that are much easier to work with.

Let’s not get started on inheritance.

I think OO is widely discredited now, although I do see a few experienced programmers still using it.

IMHO, taking the best from React, Solid, and Svelt leaves you with Solid.

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

This shares a lot of similarities to what I’m doing with new version of Semantic UI.

Components - https://next.semantic-ui.com/components

Templating - https://next.semantic-ui.com/templates

Signals - https://next.semantic-ui.com/reactivity

DOM - https://next.semantic-ui.com/query

API Refs - https://next.semantic-ui.com/api

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?

It was a good time for change, I was working on Svelte 5 non-stop for two years! I'll be announcing my new role nearer the time :)

Makes sense xD

Best of luck! I'm curious to see what you come up with next.

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.

We've come full circle and reinvented PHP

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

Wrong frame. It's just a playground

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.

The comic works because the people creating the standard want to solve the problem of too many competing standards, but instead they just make it worse.

JS framework creators are not trying to solve the problem of too many JS frameworks.

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

Oh yes, because LLMs are known for good security practices.

I did not want to embarrass the author but the LLM showed that this library is absolutely full of major security holes.

And yes, it's an LLM that pointed them out.

So, are you saying the security holes don't exist because an LLM found them?

Please can you create a Github issue with the security holes you've found? That would be greatly appreciated. I've given it a sweep and found nothing.

Sibling's proposed approach is a recipe for false positives.

Consider Claude Code's new /security-review prompt or just use the prompt starting from "Objective" after giving the context (see the Git shell commands) to Claude Opus 4.1.

https://raw.githubusercontent.com/anthropics/claude-code-sec...

Definitely Opus 4.1 though, not lesser.

I suggest do both.

Make a minimal zip of the the source code only (cut out anything not source code) drop it into ChatGPT and say "analyse this code for security flaws".

Then ask it for more.

Then do the same this with Google AI studio - drop the zipfile in and ask it to analyse for security flaws.

If you already did so why not share the answers you got?

You should get the LLM to create a couple dozen issues on github automatically and let the author review it!! /s

Let the LLM review the issues and resolve the issues.

LLM all around, hail Skynet.

Well we presume the author actually wants his framework to be secure.