If I want to make an Erlang or Rust based system that emits RSC-compatible updates (which itself is an undefined statement) in real time, say - there's no way to do that without either having a JS layer as a separate microservice, or calling the code from JS in some way.

The PHP analogy is very much earned, in my view. It doesn't make it a bad choice for all projects, but it will tend to isolate the ecosystem from new directions.

[1] https://overreacted.io/jsx-over-the-wire/#server-and-client-...

Though you do lose a lot of the magic if you don’t have JS on the server at all. Part of the core proposition of RSC is that it’s easy to move logic across the boundary as your app evolves. What goes over the wire can be a performance decision instead of a “that’s too much of a pain to move to the other side I’ll just leave it” decision. For that reason I’d generally make a thin “backend for frontend” in JS that talks to an Erlang/Rust/etc backend. It’s conceptually part of the frontend but runs on your server.

And completely understand that freezing a format causes all kinds of difficulties, and semver alone doesn't solve for the resulting community frustration. So I understand why the decisions were made - it's just all a bit foreign to me compared to the groundbreaking simplicity of React's APIs in its earliest days, where if you understood a render cycle the entire world was your oyster. The internals of the renderer were always fine to be "off limits" - but wire formats just feel quite different to me.

(Also, just want to say you're an absolute hero of mine, and my hopefully-gentle nudging on this is because I love everything the React team has created, and I want React to see its full potential!)

Basically the entire elaborate RSC apparatus just ultimately outputs a tree of plain React elements with promises and <Suspense> to make it streamy. Sounds like groundbreaking simplicity to me! I kid a bit but really I’m not sure that the RSC wire format is any easier as an output target than the existing public React client API.

Maybe I should make a little demo to show that.

But anyway the point is that the wire format is an implementation detail because the two sides of the wire are actually the same program. Even if they’re running on two different computers.

I personally am becoming dissolutioned with React because of this, as a former strong advocate.

Next.js and Remix - or whatever the hell it's called this week - are both over-engineered messes.

Yes, I'm aware that I don't have to use them, but they are where the momentum and energy of the community is being spent in recent years. And I do want a monolithic framework, I just want one that focuses on simplicity and ease of development rather than one designed to funnel me into using Vercel.

It will be totally fresh and solve all the annoying problems of legacy react server pages. Of course then 6 months later they'll discover a need to make it work with SEO...

The default should be SPA and purely static.

> Portions of the react community are excited about how it's starting to feel more like PHP with the movement towards server actions in "client" code etc

Solidstart definitely pushes you to use their magic server functions. I used them at first - but increasingly I've been moving back to writing a normal, real REST interface on the server side. It still works fine, its just a few more lines of code to do it yourself. The biggest benefit is that I can control my HTTP verbs and headers. This lets me set up caching correctly, both in the browser and any intermediate caches.

> Things like Vue/Svelte where they mash together css and js in the same file if you want kind of turns me off.

Solidjs doesn't mash css and JS together. You usually use normal, real CSS or CSS modules. Eg:

    import styles from './style.module.css'

    function BannerComponent {
      return <div style={styles.bannerBar}>Banner</div>
    }

And http caching is definitely a huge factor for me too, graphql gives me similar sorts of pain. Sure, you can cache anything if you hack around for long enough, but in a real world engineering org (not the unicorns or uniquely positioned tech giants), it's so much easier for me to tell the CEO I can put some cache headers in by end of day and move on.

To be clear, solidstart also makes it very easy to set up a REST API server endpoints. They're ~10 more lines of code compared to their magic RPC handlers. They work great.

https://docs.solidjs.com/solid-start/building-your-applicati...

I personally found Svelte much more intuitive than React.

Code first, then markup, then style.

React I have always just found a bit confusing and annoying.

I have a proposal for a new approach to front-end components. Even used it at a big client in production.

Want to put it on arxiv[1] before showing it to the world, but it's largely impossible to find an endorser unless you're active in academics already.[2]

Academics in a nutshell: the largest number of papers are authored by recent graduates with little to no industry experience.

Now, remember just how clueless your recent MSc graduate was when they started their first job in your organisation? Yeah - those are the types of authors driving state-of-the-art in SE.

---------------------------------------

[1] I have my reasons. If you're an endorser for software engineering, DM me.

[2] Academic gate-keeping got stupid, then pushed past to ridiculous, and appears to be now accelerating over the madness event-horizon.

``` const h = React.createElement

h('div', { id: 'foo' }, [ h(MyComponent, props) ])

```

Of course the props to divs are a bit different and event listeners/styles can be written inline, but none of this is JSX specific.

Reading that post the other day and seeing modern terminology being applied to old backend rendering was quite the experience. "Imagine on initial page load it returns the complete screen UI with all props and components already hydrated".

I remember those days but I remember some of the bad as well. I really started to hate that every UI change in the template/HTML meant changing the page controller to handle the new data. I specifically remember wanting some technology that allowed the UI to dictate what data it needed.

The pendulum swings though and it seems we are reversing course lately. Perhaps we land on a solid middle ground finally.

HN likes to dunk on React but I think the paradigm is pretty cool and I hope that other meta frameworks beyond NextJS find ways to support it in simpler to follow ways - Tanstack Start has a promising looking philosophy, excited to see where they land on.

  const Button = styled.button<{ $primary?: boolean; }>`
    /* Adapt the colors based on primary prop */
    background: ${props => props.$primary ? "#BF4F74" : "white"};
    color: ${props => props.$primary ? "white" : "#BF4F74"};
    ...
  `;

  render(
    <div>
      <Button>Normal</Button>
      <Button $primary>Primary</Button>
    </div>
  );

See: https://opencollective.com/styled-components/updates/thank-y...

Why? React core has been exactly the same as it was ten years ago. Building a React SPA has not changed significantly, other than the growth in third-party libraries that complement the Core.

Recent developments in React has been about enabling its usage in wider problem domains, but not at the detriment of its previous use cases, so why would that affect you?

Your tooling certainly has changed in that you won't use cra any more, and I wouldn't agree that this direction does not detriment previous use cases.

It's not 10 years yet, but we're pretty close to that.

Yes, time flies.

Yes

https://react.dev/reference/react/Component

> play well with existing ecosystem code?

That's not something the React team has any control over so it feels like an unfair complaint.

However, besides external libraries that are specifically designed to work with hooks, I'd say quite a lot of things would still work. And you can always just use older versions of things, nobody is forcing you to upgrade.

Anyway, React has been using hooks for about 6 or 7 years now. Not quite the ten years claimed in the previous comment but not so far off either.

Sure it is — they could let you run hooks from within class components. Not only do they not allow that, they actively discourage you from writing class components in the documentation.

Even if they didn’t have control over that, though, how does the complaint feel unfair? When I buy into a tool, I’m buying into the ecosystem as well. If the ecosystem moves in a direction I don’t like, that’s a strong disincentive to using that tool!