Readit Newsmati365 commented on Quill OS: An open-source OS for Kobo's eReaders quill-os.org/... · Posted by u/Curiositry
If your goal is just to easily sync your own ebook library with a Kobo device, I've found that something like this isn't really necessary.
There is a config file on the stock OS that you just need to change, and you can point the Kobo store to your own instance of Calibre Web.
This lets you sync and download your own books to the device over wifi.
I played around with KOReader a bit but found the stock software simpler to use. All I really need is to not be tied to an ebook store.
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.
mati365 commented on Can text be made to sound more than just its words? (2022) arxiv.org/abs/2202.10631... · Posted by u/tobr
Consider learning Polish. Kurwa sounds exactly as it looks.
Writing compilers for old CPUs has some real magic in it. It helps you see how processors really work and brings back the old days when hardware was simple and easy to understand. I miss that time. I once wrote a small C compiler in TypeScript for the Intel 8086 and 8087 ([1]), and I have huge respect for the people who coded for those chips. It’s super hard but also very rewarding.
mati365 commented on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js akarshc.com/post/phoenix-... · Posted by u/akarshc
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.
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.
mati365 commented on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js akarshc.com/post/phoenix-... · Posted by u/akarshc
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.
mati365 commented on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js akarshc.com/post/phoenix-... · Posted by u/akarshc
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.
mati365 commented on Why I Chose Elixir Phoenix over Rails, Laravel, and Next.js akarshc.com/post/phoenix-... · Posted by u/akarshc
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.
[1] https://github.com/Mati365/ts-c-compiler