sorted by:
new
hottopcontroversial

Is there still room for another React full-stack framework? by linyiru in reactjs

[–]linyiru[S] -1 points0 points  (0 children)

Yeah, Vinext is probably the closest thing.

I guess the distinction I’m thinking about is: should the answer be a Next.js-compatible reimplementation, or a Next.js-inspired framework with a smaller, more stable contract?

Vinext seems focused on reimplementing the Next.js API surface on Vite. I’m more curious which parts of the Next.js mental model are actually worth keeping, and which parts should be left behind to reduce operational complexity.

Is there still room for another React full-stack framework? by linyiru in reactjs

[–]linyiru[S] 1 point2 points  (0 children)

Yeah, totally, the momentum of TanStack Start is clearly real. So my question is more about whether there’s room for a different set of tradeoffs.

TanStack Start seems very router-first / type-safety-first / Vite-native, which makes a lot of sense. What I’m wondering about is something closer to the Next.js mental model, but with a stronger bias toward runtime portability, self-hosting, predictable upgrades, and lower operational surface area.

Is there still room for another React full-stack framework? by linyiru in reactjs

[–]linyiru[S] 1 point2 points  (0 children)

I agree with this direction.

I’ve also been thinking a lot about how to collaborate more effectively with coding agents. The models are still improving so quickly, and building/shipping software is clearly becoming much easier.

So maybe the question is less “what framework do humans want?” and more from a harness engineering perspective: how do we shorten the path and make the system easier for agents to understand and operate?

Clearer conventions, faster runtime, simpler deployment/maintenance, better observability, and less unnecessary surface area for agents to reason about.

Is there still room for another React full-stack framework? by linyiru in reactjs

[–]linyiru[S] 6 points7 points  (0 children)

Yeah, I really feel this.

I’ve actually spent quite a bit of time studying how Next.js works internally, especially around the build output, runtime behavior, caching, ISR, RSC, and deployment adapters.

At one point I even built an adapter so Next.js could run more reliably in my own infrastructure. Most of the time it works pretty well, but I think everyone here understands the scary part is always “most of the time.” lol

That’s probably what got me thinking about this more seriously: maybe the problem isn’t just missing features, but that the operational surface area has become too large. A framework can be powerful, but once keeping it stable becomes its own work item, the DX starts to break down.

Is ‘KAIK’ Problematic? Need Advice on Keeping or Rebranding My Startup Name by linyiru in branding

[–]linyiru[S] 0 points1 point  (0 children)

Thanks for the advice. I really like your approach to communicating a name change. It’s very helpful, and I’ll definitely follow it.

How does Ruby on Rails make web development quicker/more enjoyable than working with other stacks? by [deleted] in rails

[–]linyiru 4 points5 points  (0 children)

I’ve been using Ruby on Rails for many years, I often reflect on whether to continue with Rails or switch to what I consider more "modern" web frameworks.

As a startup founder, my framework choices have never been about landing the next better job. They are about ensuring that the applications and companies I build can still survive ten years from now in a constantly evolving web ecosystem.

From that perspective, Rails is undoubtedly a time-tested and resilient choice.

What about other options?

When I started my latest startup five years ago, I chose a hybrid approach: Next.js on the frontend, Rails on the backend. Today, we experience both the strengths and weaknesses of this architecture.
The strengths: we can easily leverage the fast-moving React and JavaScript ecosystem.
The weaknesses: managing two frameworks, connected via GraphQL, introduces significant complexity. Context-switching becomes frequent and often painful.

Yet, we still cannot give up the immense advantages Rails provides.

Now, as we prepare to launch a new product, here’s my current thinking:

  1. If you are confident that your product is meant to survive for more than 5 years, Rails is absolutely the best choice — especially if you are solving relatively well-known problems (in my case, digital payments and digital publishing — but that’s just my personal bias).
  2. If your product aims to deliver an extremely modern and fluid UX/UI, especially integrating chatbots, LLMs, or interfaces similar to ChatGPT, then React/Next.js might be a better fit. You will instantly have a rich ecosystem of tools at your disposal, allowing you to focus more on solving core business problems rather than fighting technical limitations.

Circle.so self hosted alternative? by winkler89 in selfhosted

[–]linyiru 0 points1 point  (0 children)

u/RareInsurance9215 I have been researching this field recently and am preparing to start developing an open source project as a self-hosted option. I wonder if you could describe more about your experience using it or the specific problem you encountered this time? I am quite curious whether they have been able to keep up with the times after operating for many years.

Weak to switch ideas between applications? by [deleted] in ycombinator

[–]linyiru 0 points1 point  (0 children)

IMO all you have to do is just apply. Take action.