[mati365]

I implemented CKEditor integrations for Rails, Livewire, Phoenix, and React. I think the best developer experience was with Phoenix - at every step I was surprised by how well thought-out the framework is and how easy it is to build integrations for it. I definitely can’t say the same about Rails or, especially, React with the awful Next.js. For anyone curious: https://github.com/Mati365/ckeditor5-phoenix

As for Livewire - it feels like a simplified copy of Phoenix. In my opinion, it’s less advanced and less intuitive. For example, Livewire components don’t support slots, while Phoenix components handle them without any issues. Slots are critical for clean component composition - without them, you end up with messy, repetitive templates and a lot of unnecessary logic in the components themselves.

When it comes to Next.js, constant router changes and questionable decisions have become a daily routine. There’s no point integrating with something that gets rewritten every week and can’t be trusted to stay stable.

[dominicrose]

PHP (Laravel) + JQuery still works for me in 2025, but I would never use Livewire.

Using Node.js would hurt productivity but it's more powerful if needed. It may be needed because it has async/await and it has socket.io. It's also possible to use Typescript.

Next.js can be useful if you need everything (good SEO + highly interactive) but let's be honest how many websites need good SEO and websockets? LinkedIn maybe.

[mati365]

I'm not so sure Next.js is as SEO-friendly as people claim. The JavaScript bundles are pretty heavy, and the page still needs to hydrate before it becomes fully interactive. There are attempts to speed this up with React Server Components, but the developer experience there is already worse than with Phoenix components.

Next.js server performance isn’t great either - honestly, it’s pretty bad. Pages don’t feel that fast for users despite all the tricks and optimizations. In my opinion, metrics like LCP and others are much easier to optimize in older, more traditional frameworks. Unless you’re building a full-blown web application, a classic web page will almost always be faster and simpler to deliver without all the Next.js complexity.

[tracker1]

I think if you're going to push closer to the server in a client+server app, I'd probably look towards either HTMX integration options with a preferred backend (there's some cool C# integrations from Jetbrains as an example) or Astro over Next.js ...

That said, I'm not necessarily a big fan of mixed environments since IMO most web apps can be mostly client side and most websites can be mostly server driven. Either is simpler than the mingling tends to get. That's just my take though.

[crowcroft]

I don't understand the 'Nextjs is good for SEO' hype. I think it's better to frame it as Nextjs isn't bad for SEO. Whether a site loads without client side rendering is a pretty binary thing.

If you're using Nextjs to get a high level of rich interactivity then your SEO issues aren't about CSR vs SSR anyway though. As you point it it's just bundle size and site speed, and URL structure that end up causing a negative impact. Nextjs doesn't fix that.

[rustystump]

Next is all about that server rendering for seo which i remember doing for a spa wedding website a decade ago. Eg, if a crawler, server render otherwise spa style.

Nextjs with pages router was pretty good for me but app router is where it got complicated

[Tade0]

I'm curious about your experience with Rails. What specifically caused issues?

[mati365]

The main issues were related to how JavaScript is integrated and distributed within Rails. In older versions, you have to deal with Sprockets and dependency bundling, which is tricky if you want your integration to work across a wide range of Rails versions.

In newer versions, import maps are recommended instead. The problem is that import maps enforce ESM, while Sprockets (as far as I know) doesn’t support ESM at all. On top of that, there are compatibility issues with Turbo links, various form libraries, and the limited extensibility of the import map library itself - adding extra dependencies is just painful.

Installing CKEditor wasn’t straightforward either, so I ended up creating a small DSL to simplify it. But then came another challenge: providing support for custom plugins in a way that would work with every Rails version, even without a bundler.

All of this is made even harder by the fact that CKEditor is distributed in both cloud and NPM versions, which complicates integration paths further.

In contrast, Phoenix makes things much simpler. From what I remember, the standard setup uses esbuild, which automatically pulls NPM dependencies from the deps directory - the same place where Elixir libraries are installed. This means you can distribute a package that includes both the Elixir and NPM parts of the editor, without having to manually modify package.json or worry about dependency conflicts.

[danmaz74]

It looks like a lot of these issues are due to the fact that Rails has been around for a long time, has lots of versions, and you wanted to support many versions (Which is commendable, by the way). If you only had to support the latest Rails version, how much harder would it have been than doing the same for Phoenix?

[mati365]

In the latest Rails versions, it’s probably just as easy as in Phoenix. The question is whether, after years of churn in the Rails frontend ecosystem, the core team hasn’t already driven away most developers who might have cared. At this point, few people would use a library that targets the newest Rails versions when most teams treat Rails purely as a backend and handle the frontend with something else.

[axelthegerman]

While Rails indeed tries to support old versions for a while I found that many devs are eager to stay on top of upgrades (which also has been less painful the last few years and definitely when done incrementally)

Fair there will be some old never updated backend only services, but that seems like a stretch that those will need a FE library all of a sudden

[jarek83]

I wonder what made it hard for you in Rails.

[sodapopcan]

As a fan of both, the LiveView DX is simpler than Hotwire's (though of course there are trade-offs both ways). With Hotwire you have the think about frames whereas LiveView is more like React where you just change the state and the appropriate diff is patched in without having to think about much else. This is not to say that Hotwire's frames are complex, LiveView is just that much simpler in that regard.

[omnimus]

Liveview is also websockets. For many usecases going with simple http requests is a good limitation.

[sodapopcan]

Yep, that's the whole thing, these technologies have strengths and weaknesses for different application. But of course most people just want to learn only one (and I don't blame them).

[omnimus]

I am not sure you can say Livewire is a copy. The name suggests that is the case but both projects were started at similar time Livewire is afaik even older project than Liveview (Hotwire is youngest - in a way). They both take different approaches because PHP/Elixir have very different characteristics.

I think Livewire is still pretty great. Since PHP can't do websockets easily they focus on http and in most cases thats just fine. Liveview websockets can be an overkill.

[rustystump]

It makes me sad that today you cannot say react without nextjs in the same sentence.

React used to be the leader in how to make ui reasonable in the generic client sense. Having done java swing, android, swift ui, and custom game dev ui work with all the forms of state management, react was on to something… until the ssr fad attacked. Now it is all but nextjs in disguise.

[axelthegerman]

If the industry wouldn't have pushed React as the magic bullet that is always to be used it could have stayed an awesome interactive frontend library.

In some cases it's just not what you need and SSR etc are more important - then just use appropriate tools instead of forcing React to do that too

[port11]

There really isn't any need to conflate React with Next. React has its issues — notably more after exposing its internals in hooks —, but Next should be seen as something on its own.

I don't mind picking up a contract for maintaining React code, but never again am I touching anything built by Vercel; unless I specifically crave the “automagically different every release” quicksand masochism of their tools. I'm sorry to the people working on, say, Next; these are qualified and talented individuals. But the DX over time, gods…

React is still a reasonable view library, although not a top choice at all (for me). Insisting on using it for SSR via Next is self-inflicted pain down the road.

[lowercased]

> For example, Livewire components don’t support slots

IIRC, Livewire 4 will support slots, but... that's still a few weeks away from release. There seem to be a number of perf and qol improvements in LW4.

[ramon156]

I want to give both of these a try, especially if you say react+next.js is awful. You'd think TS-TS would be well thought out

[tracker1]

If you want to mix server with React and TS, then take a look at Astro or HTMX.

[Exoristos]

Don't preemptively give up on React with Next.js because some posters turn their frustration with it into contempt. Many of us use React 19 and Next App Router to great effect, and enjoy it, although there was certainly a learning curve.

[tengbretson]

NextJS app router/server components is incredible. By focusing on server-component-compatible patterns for interactivity, my rather complex web app retains like 90% of its functionality even with client side js disabled. I think the hate it gets really might be a skill issue.

[mati365]

It’s not about frustration, unwillingness to learn, or dismissing the tool altogether. My point is about trust. I just can’t imagine a Next.js app being as easily maintainable 10 years down the road as a Rails one. Honestly, I can’t even picture upgrading to a new major version without breaking something, because the pace of changes is just too fast. Sure, it’s great for small, simple projects. But building a business on it and risking breakages or dropped support? Not for me.

[Exoristos]

This isn't accurate. Most Next shops continue to use Page Router with no problems. We have an internal tool that uses both Page Router with React 13 and App Router with React 19, all seamlessly supported OOB, including frontend composition. So, again, I have to assume most of the FUD is rooted in inexperience.