Slow to whom, though?

Yes, they might lose the meaningless benchmarks game that gets thrown around, what matters is are they fast enough for the problem that is being solved.

If everyone actually cared about performance above anything else, we wouldn't have an Electron crap crisis.

▲

wrathofmonads 2 days ago | parent | next [-]

Seems like Windows is trying to address the Electron problem by adopting React Native for their WinAppSDK. RN is not just a cross-platform solution, but a framework that allows Windows to finally tap into the pool of devs used to that declarative UI paradigm. They appear to be standardizing on TypeScript, with C++ for the performance-critical native parts. They leverage the scene graph directly from WinAppSDK. By prioritizing C++ over C# for extensions and TS for the render code, they might actually hit the sweet spot.

https://microsoft.github.io/react-native-windows/docs/new-ar...

	▲	pjmlp 2 days ago \| parent [-]
		Anything related to WinUI is a bad joke. Have fun following the discussions and amount of bugs, https://github.com/microsoft/microsoft-ui-xaml That C++ support that WinUI team marketing keeps talking about relies on a framework that is no longer being developed. > The reason the issues page only lets you create a bug report is because cppwinrt is in maintenance mode and no longer receiving new feature work. cppwinrt serves an important and specific role, but further feature development risks destabilizing the project. Additional helpers are regularly contributed to complimentary projects such as https://github.com/microsoft/wil/. From https://github.com/microsoft/cppwinrt/issues/1289#issuecomme...

▲

IshKebab 3 days ago | parent | prev | next [-]

I don't know I think what matters is that performance is close to the best you can reasonably get in any other language.

People don't like leaving performance on the table. It feels stupid and it lets competitors have an easy advantage.

The Electron situation is not because people don't care about performance; it's because they care more about some other things (e.g. not having to do 4x the work to get native apps).

▲

pjmlp 3 days ago | parent [-]

Your second paragraph kind of contradicts the last one.

And yes, caring more about other things is why performance isn't the top number one item, and most applications have long stopped being written in pure C or C++ since the early 2000's.

We go even further in several abstraction layers, nowadays with the ongoing uptake of LLMs and agentic workflows in iPaaS low code tools.

Personally at work I haven't written a pure 100% C or C++ application since 1999, always a mix of Tcl, Perl, Python, C# alongside C or C++, private projects is another matter.

▲

zozbot234 3 days ago | parent [-]

Most applications stopped being written in C/C++ when Java first came out - the first memory safe language with mass enterprise adoption. Java was the Rust of the mid-1990s, even though it used a GC which made it a lot slower and clunkier than actual Rust.

	▲	pjmlp 3 days ago \| parent [-]
		I would say that the "first" belongs to Smalltalk, Visual Basic and Delphi. What Java had going for it was the massive scale of Sun's marketing, and the JDK being available as free beer, however until Eclipse came to be, all IDEs were commercial, and everyone was coding in Emacs, vi (no vim yet), nano, and so on. However it only became viable after Java 1.3, when Hotspot became part of Java's runtime. I agree with the spirit of your comment though, and I also think that the blow given by Java to C and C++ wasn't bigger, only because AOT tools were only available under high commercial prices. Many folks use C and C++, not due to their systems programming features, rather they are the only AOT compiled languages that they know.

▲

igouy 2 days ago | parent | prev [-]

When performance doesn't matter, it doesn't matter.