I don't think it's that at all. The motive is quite clear. It's right there in the article:
> We’re excited to return to active contributions to WordPress core, Gutenberg, Playground, Openverse, and WordPress.org *when the legal attacks have stopped*.
This is a move to show how much the development of WordPress depends on Automattic (some 4k hours per week) and how WP Engine is using the product of that effort without giving much back (45 hours per week) - "A Level Playing Field". It all started from this and it sends a message "don't take it for granted".
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.
Hi there! Indeed, QML is very buggy. 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. So, many bugs get fixed through open-source contributors (KDE, individuals, etc) And that might be a big reason why non-critical bugs don't get prioritize enough.
Like with anything, we're dealing with abstractions. Qt and QML are also abstractions. But I'd argue they are better abstractions than the web for dynamic semi-complex to complex applications (for static sites/simple applications, the web is fine). The reason Qt and QML are a great abstractions are mainly:
1. Native modules/APIs - you can always plug in native modules into your app as needed. For example, I use native Objective-C APIs to draw the window on macOS for my app. It just looks better than what you get with just Qt.
2. Performance - Almost all QML-based components (called Qt Quick), are written in fast, compiled language C++, and if needed, you can create your own components in C++ and expose them via QML.
3. There are many more reasons, one of them is that I think QML is the best declarative UI language I've seen, and it plays very nicely with Qt style of C++ (signal and slots etc.).
> Could it be that QT has some optimisation technique to not render all those lines out of view?
Well, I detailed in my blog post my technique - it's not really novel - you can build virtualized lists in many languages, including JavaScript. You can look into the source code of many web apps that have done the same type of block editor that I implemented. MarkText[1] seems to be the most efficient one from my testings. My point is that building upon the abstractions of the web makes it very hard to write truly efficient code that is well-optimized for your computer resources. You might be an amazing programmer, but you're limited by a certain upper bound of performance, by the mercy of the web standards council and web browser engines implementation of those standards.
> 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 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).
Haha, that's interesting. But to be honest, it's really not that bad as it seems. Again, crash reports tend to be highly prioritized and most of the time you can find your way around them until they get fixed. It's indeed a frustrating experience when non-crash related bugs aren't being prioritized, but then again, like I explain in the blog, I could use a different library, probably an open source solution like I described using QBasicHtmlExporter[1] since QTextDocument toHtml uses weird inline HTML (and has some other bugs).
The thing is, with experience I kinda start to have my own boilerplate of battle-tested components/tools/libraries. I made the following client for Ollama[2][3] while not working on it full-time (still WIP) in around a month. It already is better than many web apps I tried who kept hanging while the model was generating a response. Also, try to copy text from a code block in web apps while a model is still generating a response -> it's almost always impossible since most web apps keep re-rendering everything on each completion, while I (like the native macOS chatGPT app) do incremental parsing which is much more efficient. The binary is 28MB (and can be even smaller), the app is fast and can handle very large amount of data. So I can build QML apps really, really fast these days due to the experience I gained and still gaining. I'm also wondering if I should open source my components as AGPL and then have some commercial licensing for it... Not to mention, I rarely use my own heap allocations myself - I try to put as much as I can either on the stack or in QML - so Qt handles all the heap allocation itself. While I'm relying on Qt to do an appropriate job, it seems to be very, very stable for now.
A country that was aligned ideologically with USSR is an understatement. They were under occupation as a satellite state. Those people did not sign up for communism in 1945 willingly.
> Look, Automattic can change their license away from the GPL any time they wish. The new license will only apply to new code, though, and WP Engine, or anyone else, are eligible to fork the project. That's what happened with Redis after Redis Labs dropped their BSD license and went with a commercial source-available alternative.
No, that would not be a possibility. Since Automattic is not the copyright holder and GPL prohibits redistribution under an incompatible license, unlike BSD.
It's a completely different thing. You are talking about civilisation constructs, parent is talking about things like mental fitness, abilities to perform tasks in real-time by yourself.
For example, card payments are a crutch. If you pay by card / phone everywhere and then out of the sudden you are to pay in cash, it becomes mildly challenging vs. if you are used to pay in cash you don't think about it. The brain is capable of a great deal of automation, performing learned actions is effortless. Unlike a calculator or a spreadsheet, the buyer is not doing anything, just buying. It's not a bicycle, it's a crutch. It simply atrophies the mental bandwidth. The mind becomes more lax, less sharp, when it does not engage.
Now imagine what it will do to people's brains when instead of thinking about solutions themselves, they will ask the AI for everything. Those neurons will atrophy and the person will be even less skilled to ask the AI the right questions than if they did not use the AI in the first place. I think the key will be a balance between doing the work yourself and delegating the stuff to AI, but it will be difficult to find that balance. Just like smartphones can be very useful but in the end are a net negative to society.
> The need for icebreaking vessels will remain even as climate change reduces the extent of sea ice: paradoxically, as new polar routes become accessible and sea ice becomes more mobile, the demand for icebreakers is likely to increase.
And it really does permeate it. I'm on Linux but I run it on an Intel Mac. It will be very hard to find a non-Mac replacement. I look at the laptops at the electronics store and simply nothing comes even close. Beautiful products, it's very unfortunate though that they become ever more closed.
I for one started working on a new project in C++ rather than Rust. I think it's unclear whether Rust is going to be the successor at this point. It's probably never going to pick up in the games industry, QT is C++ (and Rust bindings will always be second class or they could end up unmaintained), has better compile times and is said to be undisputed when it comes to high performance. Obviously the tool for the job factor is most critical.
Career wise, many people are picking up Rust and almost no one is picking up C++, while experienced C++ devs either retire or switch to a higher level language due to landscape change. I would trust supply and demand to be in favour of C++ 10 years from now.
There are also attempts to make C++ more memory safe like Carbon[1] or Circle compiler [2]. If they succeed, why would anyone want to switch to Rust? Also Rust is not ideal for security from a different perspective - I think the lack of a package manager is one C++ strongest points. After working for 9 years with npm, you really appreciate that the dependency you install is usually just a single dependency (even an option for a single header file is common), when there's a package manager, people will abuse it (like install a package with 3 dependencies of its own for something that could be 50 LOC copy-paste) and managing the security of the supply chain is nearly impossible (it will be a legal requirement soon in EU though).
Anyway, I wanted to ask. How is the contracting market looking in C++ world? I'm guessing it depends on the domain heavily? I'm mainly asking about QT and anything that would be desktop / mobile apps / systems programming except video games, but I'm curious in general.
> We’re excited to return to active contributions to WordPress core, Gutenberg, Playground, Openverse, and WordPress.org *when the legal attacks have stopped*.
This is a move to show how much the development of WordPress depends on Automattic (some 4k hours per week) and how WP Engine is using the product of that effort without giving much back (45 hours per week) - "A Level Playing Field". It all started from this and it sends a message "don't take it for granted".
https://web.archive.org/web/20240927025102/https://wordpress...
https://wordpress.org/five-for-the-future/pledges/?order=hou...
reply