6 ms·

>There are a number of solutions that are either dead or are not ready for production yet, such as React NodeGUI[0], Proton Native[1] or react-native-desktop-qt

by jasode 5y ago

>There are a number of solutions that are either dead or are not ready for production yet, such as React NodeGUI[0], Proton Native[1] or react-native-desktop-qt[2]. Just looking at your 3 examples, I notice they all depend on Qt ... and hence the Qt UI components instead of the more familiar HTML/CSS of Electron. So the code ends up looking like: const { QLabel, QMainWindow } = require("@nodegui/nodegui"); const win = new QMainWindow(); const label = new QLabel(win); label.setText("Hello world"); label.setInlineStyle("color: green; background-color: white;"); win.show(); global.win = win; So the idea of programmers having to learn a bunch of unfamiliar QXxx() like QLabel() etc -- will be a tough sell to gain mindshare. Yes, it's Javascript instead of C++ but the QXxx() will still create a lot of friction for adoption. Also, a dependency on the Qt framework may be worse than Chromium for various strategy/technical/license reasons. >Is "just stick Chromium into all your apps" seriously the best we can do as an industry? It's resource-inefficient to high heaven, The complaints about "resource-inefficient" attract a lot of agreement but also ignore the productivity of the developers that get to leverage their existing knowledge of Chromium-based components. If whatever alternative to Electron has SuperiorResourceEfficientTechnology also comes with unacceptable extra friction (aka learning curve) for adoption, it will then also lose to Electron.

Aeolun 5y ago
You have react wrappers for all of those (hell, some already include React in the name, so they are the wrappers), so you really don’t have to learn unfamiliar syntax, just a bunch of new components.
- jasode 5y ago
  >, so you really don’t have to learn unfamiliar syntax, just a bunch of new components. Even with React wrapper, consider the differences and additional learning curve: Example from https://react.nodegui.org/docs/guides/styling https://react.nodegui.org/docs/guides/styling : import React from "react"; import { Renderer, Text, Window } from "@nodegui/react-nodegui"; const App = () => { return ( <Window> <Text style={textStyle}>{"Hello World"}</Text> </Window> ); }; const textStyle = ` color: green; background-color: white; `; Renderer.render(<App />); Compare with example from https://reactjs.org/docs/hello-world.html https://reactjs.org/docs/hello-world.html : ReactDOM.render( <h1>Hello, world!</h1>, document.getElementById('root') ); Maybe the Qt-based Nodegui even with the more accessible React syntax -- is still too much friction for wide adoption. Yes, everybody wants lower cpu & ram usage but that goal always competes in the marketplace of ideas with DX Developers' Experience. The DX of leveraging existing knowledge is a bigger priority to many devs. Does replacing QXxxx() with <Unfamiliar></Unfamiliar> really change the equation to adopt the Qt alternatives to Electron?
  - dkersten 5y ago
    Since you're not applying color to the browser sample and are inlining the component, a more apples to apples example would be: import React from "react"; import { Renderer, Text, Window } from "@nodegui/react-nodegui"; Renderer.render( <Window> <Text>Hello World</Text> </Window> ); which really doesn't seem any worse to me, especially given that in most React code I've seen, outside of the simplest apps and the fundamental components, you build up custom components anyway instead of doing everything with HTML equivalents.
    - jasode 5y ago
      >which really doesn't seem any worse to me, I wasn't trying to compare noisy lines-of-code so your simplification still doesn't change the underlying issue: unfamiliarity and not being able to leverage existing knowledge/libraries in the Electron/Chromium landscape. In this perspective, the "<Window><Text>" is already "worse" to many devs even if you reduce the source code line count to be the same. In an ideal world, developers wish for this (unrealistic) technology: - No need to change any code or learn any new knowledge and just effortlessly recompile with NewTool and then the executable magically runs 3x faster with 3x less memory and cpu usage. But such tools don't exist so we end up with the following tradeoff and reality of prioritizing costs: - You can make your executable use X less resources and be more efficient -- if you expend this extra mental cost of Y And that "Y" cost ends up being extra friction that many developers don't want to do. (E.g. use React-Nodegui-Qt instead of Electron.) 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."
      - dkersten 5y ago
        > 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." Yes, absolutely agree.
kijin 5y ago
> also ignore the productivity of the developers And that is the problem. We're living in a world where it's considered acceptable to make millions of users waste quadrillions of CPU cycles and petabytes of RAM every day (pennies, really) so that a relatively small number of developers can be more productive. When you don't have many users, the time and money you save by being more productive might still outweigh the combined cost to the users, so your app is still a net benefit to the world. At a certain point, though, if you're lucky enough, you will begin to push a heck of a lot more externalities onto your users than you're saving internally. (I'm looking at you, Slack.)
auxym 5y ago
Unfamiliar... for whom? Are we at the point where all developers, or all GUI developers, are expected to be familiar with HTML/CSS/JS/DOM concepts? The QT stuff is familiar to me (from python mostly), but I have only very barebones knowledge of HTML/JS and almost none of the DOM and CSS.
- krapp 5y ago
  >Are we at the point where all developers, or all GUI developers, are expected to be familiar with HTML/CSS/JS/DOM concepts? Unfortunately, yes, and we've been there for a while. >The QT stuff is familiar to me (from python mostly), but I have only very barebones knowledge of HTML/JS and almost none of the DOM and CSS. Feel free to join the rest of us dinosaurs out on the patio to watch the world burn.
- jasode 5y ago
  >Unfamiliar... for whom? For the web developers who want to re-use their existing frontend skills of Javascript+HTML+CSS to create cross-platform desktop executables ... instead of learning a different GUI toolkit such as C++ QT, or C# Winforms WPF, or Java SwingGUI, Pascal Delphi, etc. The op's links of Electron alternatives based on Qt do offer re-use of Javascript skills but I guess that's not enough of a compelling value proposition to gain mindshare.
rathboma 5y ago
As the creator of a desktop app (https://beekeeperstudio.io https://beekeeperstudio.io) I can tell you there's no way I'd have been able to do it without electron. No way. Electron let's me provide feature parity for three platforms on a nights and weekends time budget. Plus the whole Vue ecosystem is available to me.
- ClumsyPilot 5y ago
  The question is not why do you use electron. The question is why is that the only viable choice goven to you

by jasode 5y ago

Aeolun 5y ago

You have react wrappers for all of those (hell, some already include React in the name, so they are the wrappers), so you really don’t have to learn unfamiliar syntax, just a bunch of new components.

jasode 5y ago
>, so you really don’t have to learn unfamiliar syntax, just a bunch of new components. Even with React wrapper, consider the differences and additional learning curve: Example from https://react.nodegui.org/docs/guides/styling https://react.nodegui.org/docs/guides/styling : import React from "react"; import { Renderer, Text, Window } from "@nodegui/react-nodegui"; const App = () => { return ( <Window> <Text style={textStyle}>{"Hello World"}</Text> </Window> ); }; const textStyle = ` color: green; background-color: white; `; Renderer.render(<App />); Compare with example from https://reactjs.org/docs/hello-world.html https://reactjs.org/docs/hello-world.html : ReactDOM.render( <h1>Hello, world!</h1>, document.getElementById('root') ); Maybe the Qt-based Nodegui even with the more accessible React syntax -- is still too much friction for wide adoption. Yes, everybody wants lower cpu & ram usage but that goal always competes in the marketplace of ideas with DX Developers' Experience. The DX of leveraging existing knowledge is a bigger priority to many devs. Does replacing QXxxx() with <Unfamiliar></Unfamiliar> really change the equation to adopt the Qt alternatives to Electron?
- dkersten 5y ago
  Since you're not applying color to the browser sample and are inlining the component, a more apples to apples example would be: import React from "react"; import { Renderer, Text, Window } from "@nodegui/react-nodegui"; Renderer.render( <Window> <Text>Hello World</Text> </Window> ); which really doesn't seem any worse to me, especially given that in most React code I've seen, outside of the simplest apps and the fundamental components, you build up custom components anyway instead of doing everything with HTML equivalents.
  - jasode 5y ago
    >which really doesn't seem any worse to me, I wasn't trying to compare noisy lines-of-code so your simplification still doesn't change the underlying issue: unfamiliarity and not being able to leverage existing knowledge/libraries in the Electron/Chromium landscape. In this perspective, the "<Window><Text>" is already "worse" to many devs even if you reduce the source code line count to be the same. In an ideal world, developers wish for this (unrealistic) technology: - No need to change any code or learn any new knowledge and just effortlessly recompile with NewTool and then the executable magically runs 3x faster with 3x less memory and cpu usage. But such tools don't exist so we end up with the following tradeoff and reality of prioritizing costs: - You can make your executable use X less resources and be more efficient -- if you expend this extra mental cost of Y And that "Y" cost ends up being extra friction that many developers don't want to do. (E.g. use React-Nodegui-Qt instead of Electron.) 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."
    - dkersten 5y ago
      > 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." Yes, absolutely agree.

kijin 5y ago

> also ignore the productivity of the developers And that is the problem. We're living in a world where it's considered acceptable to make millions of users waste quadrillions of CPU cycles and petabytes of RAM every day (pennies, really) so that a relatively small number of developers can be more productive. When you don't have many users, the time and money you save by being more productive might still outweigh the combined cost to the users, so your app is still a net benefit to the world. At a certain point, though, if you're lucky enough, you will begin to push a heck of a lot more externalities onto your users than you're saving internally. (I'm looking at you, Slack.)

auxym 5y ago

Unfamiliar... for whom? Are we at the point where all developers, or all GUI developers, are expected to be familiar with HTML/CSS/JS/DOM concepts? The QT stuff is familiar to me (from python mostly), but I have only very barebones knowledge of HTML/JS and almost none of the DOM and CSS.

krapp 5y ago
>Are we at the point where all developers, or all GUI developers, are expected to be familiar with HTML/CSS/JS/DOM concepts? Unfortunately, yes, and we've been there for a while. >The QT stuff is familiar to me (from python mostly), but I have only very barebones knowledge of HTML/JS and almost none of the DOM and CSS. Feel free to join the rest of us dinosaurs out on the patio to watch the world burn.
jasode 5y ago
>Unfamiliar... for whom? For the web developers who want to re-use their existing frontend skills of Javascript+HTML+CSS to create cross-platform desktop executables ... instead of learning a different GUI toolkit such as C++ QT, or C# Winforms WPF, or Java SwingGUI, Pascal Delphi, etc. The op's links of Electron alternatives based on Qt do offer re-use of Javascript skills but I guess that's not enough of a compelling value proposition to gain mindshare.

rathboma 5y ago

As the creator of a desktop app (https://beekeeperstudio.io https://beekeeperstudio.io) I can tell you there's no way I'd have been able to do it without electron. No way. Electron let's me provide feature parity for three platforms on a nights and weekends time budget. Plus the whole Vue ecosystem is available to me.

ClumsyPilot 5y ago
The question is not why do you use electron. The question is why is that the only viable choice goven to you