I have spent most of my career building things that live in a browser talking to a server. Request comes in, application does work, response goes out. Even when the work is a queue, a cache, or a third-party API, the mental model is still a process serving the network.
Qt is not that.
This is not a tutorial, and I am not going to pretend I am a Qt expert. I am a backend/web engineer learning a desktop toolkit and writing down the parts that refused to map cleanly.
The first wrong translation
The instinct, coming from Laravel or any web MVC, is:
- QML or widgets ≈ Blade / Vue
- C++ classes ≈ controllers
- signals/slots ≈ events or listeners
- the
.proor CMake file ≈ Composer, somehow
That translation is close enough to get you into trouble.
A web app is a sequence of short-lived requests. A Qt application is a long-lived process with an event loop. State is not rebuilt from a database on every click unless you designed it that way. Memory is not “PHP-FPM will recycle this worker eventually”. If you leak, you leak in front of the user.
Ownership is not a metaphor
In Laravel I think about object lifetime loosely. A service is resolved from the container, a request ends, PHP throws the whole thing away. I can be sloppy about who owns a listener and the process still survives.
In Qt, ownership is a real design axis. Parents delete children. A QObject tree is not a cute diagram; it is how you avoid use-after-free. Signals connected to objects that have already been destroyed are a category of bug I did not have to care about in PHP.
Coming from web development, this feels like being asked to think about garbage collection and UI at the same time. That discomfort is the point. Desktop applications make lifetime visible.
UI is not HTML with extra steps
I kept expecting a layout engine that works like CSS. Qt has layouts. They are not CSS. Constraints, size hints, and “why is this widget 17 pixels too tall” are a different discipline.
QML looks more like the web than widgets do. That is a trap. It is declarative, it has components, it even has something that reminds you of reactive data. It is still sitting on top of C++, compilation, and a runtime that is not a browser.
The useful reframe for me:
The browser is a huge, opinionated application platform that you have been treating as if it were just HTML. Qt makes you notice the platform.
Build systems will humble you
I am used to Composer and npm being annoying. I was not prepared for how much of “learning Qt” is actually learning:
- CMake vs qmake
- kits, compilers, and the difference between having Qt installed and having this Qt installed
- why a kit looks valid and then the project will not configure
- Windows + Visual Studio + Qt Maintenance Tool as a three-body problem
I lost real time to the installer itself. That belongs in the Problem Log, not here. The lesson for this article is simpler: in web development, “I installed the framework” is a five-minute story. In Qt, installation is part of the engineering.
What I am keeping from the web
Not everything transfers badly.
- Separate the domain from the chrome. Whether the chrome is Blade or QWidgets, the business rules should not live in the click handler.
- Make failure visible. A toast is not a log. A log is not a metric. Desktop apps still need all three, just with different clothes.
- Do not invent a framework on day two. I have seen this in Laravel and I can already feel the temptation in C++.
What I am unlearning
- Assuming I can restart the world after every user action
- Treating configuration as a
.envfile that appears by magic - Believing that “it compiled” is close to “it is correct”
- Expecting the internet to have a Laravel-quality answer for every error message
I will keep writing as this gets less foggy. If you also arrived here from PHP or Node and felt mildly offended by moc, you are not uniquely broken. The toolkit is from a different tradition. The tradition is worth learning, slowly, without pretending you already live there.