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.
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.
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.
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.
I wonder what made it hard for you in Rails.
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.
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
If you want to mix server with React and TS, then take a look at Astro or HTMX.
I'm curious about your experience with Rails. What specifically caused issues?
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.
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?
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.