mati365

It must be magic. I don't believe it's possible in such short snippet of code.

You can also use Dropbox to sync your data on some kobo devices. It used to be disabled, but you can enable it manually in one config file.

Consider learning Polish. Kurwa sounds exactly as it looks.

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.

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.

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.

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.