>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 alrea

>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.