6 ms·

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 I perso

• esperent 1y ago
  > 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.
  • n8cpdx 1y ago
    Don't worry, we're only four or five years out from the react community discovering/inventing a totally fresh UI paradigm where the entire app is run on the client, no server rendering at all. 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...
    • deleted 1y ago
      [deleted]
  • qudat 1y ago
    Hard agree. It’s all complexity and for what? SEO? So many products don’t need SEO. API proxies with secrets? These are not super common use cases. The default should be SPA and purely static.
  • brulard 1y ago
    next.js totally is overengineered and feature-bloated. But working with remix in the last 3 years (now called React Router: framework mode) I would never label it as overengineered. I'm not sure what you are talking about. If anything, it still misses features (Middleware still in beta, websockets native support, etc.). This weeks flavor is TanStack Start - which looks quite promising and not yet overengineered as well.
• btown 1y ago
  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-components https://overreacted.io/jsx-over-the-wire/#server-and-client-...
  • sophiebits 1y ago
    Nothing about the RSC format is privileged in the React client (i.e., react + react-dom). You can always make your own serialization format as long as it can represent React elements and promises somehow. You can of course also use the RSC wire format and pin to a specific client version (or vendor/fork it) but it’s not a stable format today because it’s not clear if many people would use one and we want to leave room to improve the format as new optimization opportunities arise. 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.
    • btown 1y ago
      That's fair, though IMHO some marketing from Vercel does make it difficult for someone not versed in the internals to understand what is "privileged in the React client" and what is not. That's their prerogative as a leading maintainer, of course. 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!)
• chabska 1y ago
  > 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?
  • technion 1y ago
    Much of the official documentation now refers to server components as the "right" way to do certain things. Cra is end of life, with the replacement nextjs being heavily biased towards server components. 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.
    • math_dandy 1y ago
      I view create-vite-app with React presets as the spiritual successor of create-react-app, rather than NextJS.
    • johnny22 1y ago
      I'd already switched to vite due to the lack of customization that one has with CRA.Even if create-react-app was still maintained, I'd never go back to it.
    • arkaic 1y ago
      Vite all the way....until that gets deprecated and forced to move to nextjs
  • mvdtnz 1y ago
    Really? So class components are still first class citizens and play well with existing ecosystem code?
    • esperent 1y ago
• voat 1y ago
  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.
  • dhruvrajvanshi 1y ago
    You can use React without jsx too. JSX is just a very thin wrapper over React.createElemental ``` 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.
• josephg 1y ago
  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> }
  • thomasfromcdnjs 1y ago
    Thanks for the answer. 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.
    • josephg 1y ago
      Yeah. 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-application/api-routes https://docs.solidjs.com/solid-start/building-your-applicati...
• pests 1y ago
  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.
  • presentation 1y ago
    The point of RSC is that you get the behavior you’re describing without the dev pain points you are describing, and with a high degree of flexibility in customizing what code gets run/sent over the wire where. 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.
• maxloh 1y ago
  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> );
  • re-thc 1y ago
    It’s officially deprecated. See: https://opencollective.com/styled-components/updates/thank-you https://opencollective.com/styled-components/updates/thank-y...
• lelanthran 1y ago
  > 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.
• richrichardsson 1y ago
  > 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.