> In this perspective, the "<Window><Text>" is already "worse"
I disagree, because most of my react code is already components rather than raw HTML tags. I'm already using component libraries that provide widgets and such. I'm already using component libraries that are applying styles. I only use raw HTML tags when I'm building such a component from scratch.
My point is that when writing a React UI, developers are already used to using custom components and used to learning to use them. Just because the components are modeled after Qt's widgets instead of Material UI, BlueprintJS, React Bootstrap or what have you, doesn't really change much. They all already have their own idioms and API's and learning them isn't hard.
> In an ideal world, developers wish for this (unrealistic) technology:
Sure. In an ideal world, such a thing would exist and life would be awesome. Sadly, we don't live in that world. Java tried it and failed. I'm not saying that the current state couldn't be improved, because of course it can, I'm just saying that I don't believe the Qt-based React wrappers are such a big deal as you seem to be suggesting.
> if you expend this extra mental cost of Y
Leaving aside the React wrappers, using alternative UI technology is only extra mental cost because you're unfamiliar with it. I found switching to web to have extra mental cost after doing native development years ago too. You get over it quickly enough, as you learn the new tools. Of course I would love if there was a single tool that worked for all cases, just like you.
> So the answer to "Why aren't there any real alternatives to Electron?" ... ends up being: "There _are_ alternatives to Electron but developers don't want to pay the _costs_ of switching."
>I disagree, because most of my react code is already components rather than raw HTML tags. [...] My point is that when writing a React UI, developers are already used to using custom components [...] Just because the components are modeled after Qt's widgets instead of Material UI, BlueprintJS, React Bootstrap or what have you, doesn't really change much. They all already have their own idioms and API's and learning them isn't hard
If the above is true, your disagreement and all the supporting arguments (custom components) for React-Qt you listed can be summarized to "zero learning effort compared to Electron". That would mean that using Qt-based alternatives to Electron would really be free of switching costs.
But that's not happening out there in the marketplace of ideas so there must be an extra hidden cost somewhere in React-Qt that you're (inadvertently) underselling. Some possibilities:
- Even if the higher-level Electron custom components are <unfamiliar> tags that must be learned, there is value in web devs being able to see (copy/modify) the underlying HTML rather than Qt components. HTML components has more survival characteristics than Qt components. This bubbles to higher levels of custom components.
- wider ecosystem of libraries, hooks, code samples to copy-paste from web, etc that grow from HTML survival characteristics.
- Electron without React/Vue/Angular (raw HTML) is more familiar to web devs than Qt QXxx()
- Chromium runtime has extra capabilities (e.g. play media formats) that's not available in Qt runtime
So proposing that learning React-Qt is "different-but-irrelevant-because-it-is-actually-equal-effort" to Electron/Chromium is missing something about the switching costs. Otherwise, devs could just effortlessly switch to React-Qt and get resource-efficient executables and positive vibes from fellow devs for free.
I disagree, because most of my react code is already components rather than raw HTML tags. I'm already using component libraries that provide widgets and such. I'm already using component libraries that are applying styles. I only use raw HTML tags when I'm building such a component from scratch.
My point is that when writing a React UI, developers are already used to using custom components and used to learning to use them. Just because the components are modeled after Qt's widgets instead of Material UI, BlueprintJS, React Bootstrap or what have you, doesn't really change much. They all already have their own idioms and API's and learning them isn't hard.
> In an ideal world, developers wish for this (unrealistic) technology:
Sure. In an ideal world, such a thing would exist and life would be awesome. Sadly, we don't live in that world. Java tried it and failed. I'm not saying that the current state couldn't be improved, because of course it can, I'm just saying that I don't believe the Qt-based React wrappers are such a big deal as you seem to be suggesting.
> if you expend this extra mental cost of Y
Leaving aside the React wrappers, using alternative UI technology is only extra mental cost because you're unfamiliar with it. I found switching to web to have extra mental cost after doing native development years ago too. You get over it quickly enough, as you learn the new tools. Of course I would love if there was a single tool that worked for all cases, just like you.
> So the answer to "Why aren't there any real alternatives to Electron?" ... ends up being: "There _are_ alternatives to Electron but developers don't want to pay the _costs_ of switching."
Yes, absolutely agree.