mckravchyk

If you wanted to develop a cross-platform native desktop / mobile app in one framework without bundling / using a web browser, only QT comes to mind, which is C++. I think there are some bindings though.

C++ does not have a function keyword at all, I wonder why did they add it in the first place.

I think the bigger problem would be license key sharing. If there's no server involved, there's no way (?) to prevent the same license key from being shared freely on the Internet and being used an unlimited amount of times, is it? This allows pirates to use a clean version with 0 risk of installing some malware.

The same Europe that introduces Cyber Resilience Act? Good luck. Imagine how many businesses will not be created because no one wants to risk burdening themselves with obligatory by law, 5 years of security maintenance of the product. It does not just suffice that you risk failing, you risk having to maintain it for years after the potential business failure.

I remember that another comical argument was performance. Supposedly, having extensions run in the background all the time is bad. So it's better to constantly, completely re-initialize them whenever an event wakes them up.

Is it possible for steam from boiling water to contain any impurities?

> No magic.

There's plenty of magic. I think that Electron Forge does too many things, like trying to be the bundler. Is it possible to set up a custom build system / bundling with it or are you forced to use Vite? I guess that even if you can, you pull all those dependencies when you install it and naturally you can't opt out from that. Those dev dependencies involved in the build process are higher impact than some production dependencies that run in a sandboxed tab process (because a tiny malicious dependency could insert any code into the app's fully privileged process). I have not shipped my app yet, but I am betting on ESBuild (because it's just one Go binary) and Electron Builder (electron.build)

This is a sabotage so the next major release doesn't get any attention ;)

> Additionally, it eliminates the need to parse HTML, as every node state is represented in a Go-based virtual DOM, with only updates being pushed directly to the actual HTML nodes.

That looks really interesting. I'm curious, are there any performance drawbacks to updating DOM via WebAssembly or is it negligible? I.e. let's say you are building an editor of some kind. If the entire app is in Go, that means sending the keydown event to the WASM module and having it update HTML back. Is it not better (from performance perspective) to just use JavaScript all the way?

> Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.

I would not be surprised if in 10 years from now, there will only be full stack web developers.

I am a desktop developer (yeah, Electron). There's really no front-end / back-end split in this domain. Electron is pretty much everything web front-end (in a "SPA, choose your own adventure" way rather than relying on a framework to do the heavy lifting) and all the business logic that is self-contained within the app and putting it all together with the APIs Electron exposes. I know that a local self-hosted back-end does not have the complexity of a distributed web-backend, but it's still much more than just front-end and there are areas of development that are probably more "wide" and definitely more complex than this anyway - like video game development or C++ / QT desktop development.

Now what happens to the front-end now? Full-stack frameworks like Next.js. They also simplify the front-end part to death, where you do not even get to think about state management anymore. Then you add generative AI...

Also consider this, is a front-end and back-end engineers with 10 years experience at a large co that much better at their respective domains than a full stack with 5 years of experience at a startup? I cannot say for the back-end, but I can say for the front-end - there's a ceiling and it does not take long to reach it (maybe 5 years). You stop getting much better once the ceiling is reached. So what makes someone good is both reaching the ceiling and continuing to do the work on a daily basis, rather than specialising in an area, in my option. A video game dev with 20 years of experience probably is much much better than one with 5y. But front-end? I don't think so.

> But there's also a large discrepancy between Chromium's budget (Google) and The Qt Company. Also The Qt Company tend to prioritize advancement in the embedded world (where it probably gets most of its cash) rather than regular applications

Yep. That's precisely the point, you get all this stuff from a billion dollar project for free.

I really would not mind writing some C++ instead, even if it was more difficult. If anything, it would only be better because of higher moat of the project as well as my own skills. I agree 100% on the principles that native is better, faster and JS is an unnecessary layer of abstraction slowing things down.

However, if I can compare 2 timelines, one where I am using QML for a project, another one where I am using Electron and think about the time spent working around bugs, reporting bugs and the users of the app complain about crashes in the former, or not have any of that at the trade off of having something slightly slower, to me it's a no brainer.

In the context of what you wrote in the article:

> One of the most frustrating aspects of developing a Qt application is the slew of Qt bugs you encounter along the way. During ten months of development, I reported seven bugs, three of which were assigned 'critical' priority—two of which resulted in crashes. I also came across many bugs already reported by others that remain unfixed.

I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).

That's just the unfortunate state of industry where we are at. Hopefully it changes one day. Maybe Chromium could be forked into a C++ GUI toolkit where DOM could be manipulated directly by C++. Has anyone ever considered that?

I am not sure if it's worth it though.

As you have pointed out, QML is buggy. Chromium's rendering engine is probably the most stable and polished GUI toolkit there is, not to mention a cross-platform one too. Throughout the last 10 years I only had to deal with 2 Chromium bugs and they were very minor. Well-written JavaScript is fast and the machines are getting faster every year. It does not take much real time computation to provide a UI for a desktop app, it's not a video game. And many of the those things that are real time, like the caret in the text editor or hover states are implemented in native code by the web browser, with no JS interaction. I agree though that a block editor is a little more real time than the average UI.

The key word is well-written JavaScript. What is the most popular state management framework? Redux, possibly. What is the most inefficient state management framework? Also Redux. With Redux, if you have an app that displays a timer that updates every second, every subscription to any piece of the state throughout the entire app will trigger. I'm not sure if the app used Redux, but I used to use a time tracker app that would use 30% of my CPU when idle (I since moved to a CLI C++ solution and it is so much faster, but that does not mean a decent time tracker could not be built with web technologies). So if Redux is the most popular framework, you can see just how little the average web dev cares about writing apps that are not slow resource hogs.

> Also, all web apps couldn't handle loading a very large text file (they were all hanging).

Could it be that QT has some optimisation technique to not render all those lines out of view? I.e. if you have a huge file that can still be loaded to RAM, C++ won't sweat it, but is it actually getting all rendered at the same time in a savvy implementation, whether at the level of the app or the framework? Probably not. On the other hand, the textarea element or a contentEditable div just was not made for something like this. It could still be developed by implementing a custom element / component that loads the text dynamically while scrolling. If it's too much for JS to hold, it could use WASM or another process and pass it with IPC. It is definitely possible to write an Electron-based text editor that can open a 1 GB text file efficiently, it's just not out of the box experience and most people do not think there's a need for such a use case.