One of my biggest gripes about this is that the wire format for React Server Components is neither standardized nor documented. Every bundler has its own format [1], but what this means in practice is that every bundler wants to be able to "move fast and break things" and treat the format as an internal implementation detail, which in turn means that there's no reference implementation and no way to have interop between, say, a RSC "backend" and a non-JS-based frontend (or crawler/scraper), or to have a non-JS backend emit RSC-compatible updates. Or to be able to allow people to iterate on it with fresh JS server-side code, rather than needing to build around a bundler.

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

> I personally don't like that direction so looking forward to exploring new frameworks

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.

I've been using solidjs (via solidstart) for awhile on a medium sized project.

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

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

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 personally don't like that direction so looking forward to exploring new frameworks.

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.

Yep. Solid js stays true to js. A div is literally a div. And you can use Solid without jsx, and used tagged templates if you so desire.

Never did I ever once think React would one day be compared to PHP.

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.

You can just use styled-conponents on React.

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

> I personally don't like that direction so looking forward to exploring new frameworks.

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?