> skipping cmake completely? would this be feasible?
Feasible but difficult. CMake has a tremendous user mass, so you do want to be able to use a CMake-based project as a dependency. The CMake Target/Config export system expose CMake internals and make that difficult to consume a CMake built project without CMake.
The cleanest way to do that is probably what xmake is doing: Calling cmake and extract targets information from CMake to your own build system with some scripting. It is flaky but xmake has proven it is doable.
That's said: CPS should make that easier on the longer term.
Please also consider that CMake is doing a lot of work under the hood to contains compiler quirks that you will have to do manually.
> integration of other languages in the project?
Trying to integrate higher level languages (Python, JS) in package managers of lower level languages (C, C++) is generally a bad idea.
The dependency relation is inverted and interoperability betweens package managers is always poor. Diamond dependency and conflicting versions will become quickly a problem.
I would advise to just expose properly your build system with the properties I described and use a multi-language package manager (e.g Nix) or, at default, the higher level language package manager (e.g uv with a scikit-build-core equivalent) on top of that.
This will be one order of magnitude easier to do.
> how to handle qt?
Qt is nothing special to handle.
Qt is a multi language framework (C++, MOC, QML, JS and even python for PySide) and need to be handle as such.
Hosted Securely in Germany
Your emails are protected by strict EU privacy laws and hosted on infrastructure you can trust. With servers located in Germany, Thundermail prioritizes your privacy while ensuring reliable, fast delivery worldwide.
I don't see how it's different from Amazon or Microsoft datacenters in the EU, which are not safe from the US government. As long as the US parent company can somehow get at the data, it is obligated to do so when a US agency asks for it.
Wait why is that fine? The whole point was that ladybird is yet to enter alpha which is the very reason why it's not the correct benchmark. And you said the Chrome comparison isn't the correct one but... didn't follow it up with an actual reason.
I meant it's fine for others to want to move faster and hire more people (like Google). just replying to your sentence. it's fine for others to want things different...
About ladybird, I think it is quite a good benchmark:
- they have accomplished a task many thought impossible in the modern world
- they accomplished it while having a handful of people
- they had a fraction of resources compared to both google and Mozilla. only about a year ago they had few hundred of thousands as support money to get them started.
The engine may not be finished yet. may not be as performant as the other two. but they did a 3rd engine. and given 10% of the budget Mozilla has, they would progress much more. Ladybird Team has shown how everything about Mozilla is mismanaged and simply broken.
Embedded development, high critical systems, mobile platforms (the choice isn't really there), game consoles.
It is mostly C or C++, Swift/Objective-C, Java/Kotlin.
There are other alternatives you might want to point out, notice however they need integration layers, leaky ones, some yak shaving not much different than targeting WebAssembly, and still having to talk to JavaScript.
The options for embedded are similar to asserting WebAssembly is an option to JavaScript.
Assembly is not an option per se, some embedded devices like PIC, usually still have to be written in Assembly.
Yes you might have Rust, Ada, Pascal, Basic as alternative, however the choice only goes as far as the CPU vendor SDK supports alternative toolchains, or the whole certification process allows for a choice (hence why Ferrocene exists now).
So if in the end you still have an option to go outside the trailed path, it usually means yak shaving to make your toolchain work on the target, or have bindings to the official SDK, instead of actually solving the problem, had you started with the official SDK languages.
webassembly is not an alternative to Js. if someone else said it, fine, but I didn't.
the reason why I didnt is because I despise JavaScript and was hoping that webassembly would give an alternative. which never became an alternative.
with embedded you are arguing for my point. you say sometimes there are alternatives (maybe depending on the platform). sometimes not. you can change platforms as well. that's fine. sometimes is very much different from none. and we have none for the web.
different point of view: tab grouping took 20+y to develop (since opera had it in 2000s).
in 2026 firefox should have:
- fast ui
- fast js
- fast rendering
- hw acceleration for video
- same look and feel on all platforms
- faster adblocker
just the basics, no? didn't add more advanced features here.
and let's see what is actually here:
- UI rendered via HTML/xul. an abomination. a slow abomination at that. right clicking something can show you stagers of rendering of a menu.
- check any Js benchmarks, you will see how FF stands
- rendering,... there was a talk in one of the conferences explaining timing requests and time-to-picture. this may be blamed on the standards, but chrome does it better
- video hw acceleration on Linux? is this actually working? and I don't mean 3/100 relevant codecs
- same look and feel - done
- AdBlock is the only advantage you have over other platforms. it would make sense to implement this in the browser and not rely on Js and extensions
it's sad and funny that people with only a couple million are going to soon catch up to Mozilla and make it obsolete, by building a Bowser engine, not only a shell around blink/WebKit.
Look at what happened to Opera. They fell apart, abandoned their Presto engine for Chromium and sold to an outside investment group and now they serve ads based on user data.
There was, in my opinion, no better browser company past or present than Opera in the 2000s and 2010s (sorry Mozilla). But their example exposes the fallacy of assuming that building out great features guarantees market share gains.
opera had a different business model. I don't think they had millions upon miliona that Mozilla gets from Google for antitrust reasons.
opera had to earn their money.
this aside, Mozilla just now implemented tab grouping. does that mean they are going to, because of the added features, follow opera's path?
my point was that someone said how they increased development speed. and I'm saying they are breaking record in how slow it is. it's not 1y, it's since the feature appeared anywhere and it's 20y ago. what the f was Mozilla doing since then? obviously they didn't work on the features. but also they didn't work on the other list of things I mentioned since only one is fully delivered (look and feel on all platforms) and those are non-features like fore mentioned tab groupings, but core capabilities for a browser.
in everything else they are so much behind it's really a wonder they still have market share as much as they do.
What are you talking about? Opera and Mozilla are both in the business of trying to deliver a good browser, which means good features. Different financing doesn't change the mandate to deliver good browser features, and Opera most definitely did rely on search licensing as their primary income stream anyway, despite attempts to diversify (for years they relied on Google and Yandex and got more money from that than other forms of financing).
As I said, my opinionated hot take is that Opera was probably the best ever at delivering features and performance beloved by users, but that wasn't enough to move the needle on market share, which is why Opera perfectly exposes the fallacy of assuming better features = better market share. In this context appealing to "business structure" is a deflection.
Also, this tab grouping argument is mistaken both on its own terms but more broadly as a stand in for the argument that the Mozilla team has supposedly done nothing. Firefox had native tab grouping years before Chrome ever had it, had arguably the best tab grouping extension of any browser due to an intentional choice to invest in an extension ecosystem that made that functionality possible, and for the most part, Firefox has never not had tab grouping. What's new is that it's back as a baked-in default rather than merely present as a best in class extension.
The idea that Firefox has done nothing is an unfortunate impression that comes from looking at a serious of unfortunately critical tech headlines and losing sight of nuts and bolts development. I don't have the patience to recite everything here, but every year they push millions of lines of new code, thousands of patches, and deliver measurable improvements to major browser components like webGPU, javascript rendering, shipping production quality rust code, and more for a browser with 30 million lines of code.
> Standards bureaucracies like the Linux Foundation (which consumed the Free Standards Group in its' ever-growing accretion disk years ago) happily document and add to this sort of complexity without ever trying to understand why it was there in the first place.
this is the reason in my opinion and experience
as a lead dev in a rather complicated environment I tended to solve the problem many times where some identifier was used. short deadlines and no specification made us solve the problem quickly, so some shortcuts and quick actions were done. this identifier gets asked about later and super overcomplicated explanations given as a reason by people that don't know the history.
...and the history is often like 'they mounted stuff to /usr because they got a third drive'. and now, people even in this thread keep giving explanations like it's something more.
- skipping cmake completely? would this be feasible?
- integration of other languages in the project?
- how to handle qt?
reply