mati365

I really love Quadlet. I used to host my rootless containers on Hetzner, Ansible, SystemD and RockyLinux for years without any issues and extracted it to template repo [1].

[1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

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

ofc it's sold. Take a look at this: https://www.rb2b.com/

It identifies users that visit your site and then shows their email, phone number and living place based on their Li profile ;))

Oh, it looks like my X86-16 boot sector C compiler that I made recently [1]. Writing boot sector games has a nostalgic magic to it, when programming was actually fun and showed off your skills. It's a shame that the AI era has terribly devalued these projects.

[1] https://github.com/Mati365/ts-c-compiler

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.

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.

[1] https://github.com/Mati365/ts-c-compiler

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.

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.

CKEditor 5 integration for Laravel Livewire. Since Livewire doesn’t have an easily embeddable WYSIWYG editor, I built one.

https://github.com/Mati365/ckeditor5-livewire

What's special about this?

That's messed up, because now he's working for the employer for free, hoping the company will somehow replace the social connections it made him lose in the first place. It's definitely not something to look up to - it's just sad.

This article seems to be written entirely by AI :/

Nice! I’ve been using a similar approach for years with my own setup: https://github.com/Mati365/hetzner-podman-bunjs-deploy. It’s built around Podman and systemd, and honestly, nothing has broken in all that time. Super stable, super simple. Just drop your units and go. Rock solid.

Gratz Gyn!

If anyone interested - I made recently Ansible template for Quadlet deployment that shows how easy is it.

GH: https://github.com/Mati365/hetzner-podman-bunjs-deploy

Systemd .container services (Quadlet) are excellent. I used them to set up multiple smaller sites without any issues. Containers work just like regular systemd services. I created a small Ansible template to demonstrate how simple yet powerful this solution is.

GH: https://github.com/Mati365/hetzner-podman-bunjs-deploy

One of the biggest issues is that newer tools often lack Rails integrations. I recently built one for CKEditor - happy to share details if anyone's interested.

https://github.com/Mati365/ckeditor5-rails?tab=readme-ov-fil...

Imho, it's possible. Generally speaking, it depends if PDF can render any sort of canvas.

These 'tricks' are exactly what makes programming the passion I love. Thanks for capturing the difference between coding for joy and coding for a paycheck so succinctly. Also, it's not a wrapper—it's a full parser and compiler.

What about running Adobe Acrobat in Adobe Acrobat?

So it's possible to port C compiler to PDF. Compiler is already done https://github.com/Mati365/ts-c-compiler. We can run DOS in PDF basically..

That white clock looks cool. What's the name?

Just spawn another VPS with your application and connect to load balancer. Even better - use Fedora CoreOS with Butane config and make that VPS immutable.

Just use Podman with plain simple .container file which is controlled entirenly by SystemD. Rock solid and easy to fix.

Why not? Install trafeik or any other load balancer, setup two services, and restart one after one.

It looks like you don't even care about opening documentation before pressing reply. Podman is a simple hammer without any moving parts, that used properly can be used to build fancy stuff without much knowledge.