[HN Gopher] Ask HN: Why aren't there any real alternatives to El...
___________________________________________________________________
Ask HN: Why aren't there any real alternatives to Electron?
I have to use Discord and Element on a regular basis (which both
use Electron). They both use an unreasonable amount of RAM, and I
feel this even more as my laptop is quite old and has 4GB of RAM.
I keep looking for alternatives to Electron, which wouldn't require
such heavy resources to run, but my searches always seem to come up
short. 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]. There's react-native-
windows, but I'm not running Windows, and even if that did gain
Linux compatibility it seems that they're quite focused on
Microsoft-owned platforms. Is "just stick Chromium into all your
apps" seriously the best we can do as an industry? It's resource-
inefficient to high heaven, not to mention that it's slow and
doesn't integrate with the native platform styles at all. As a
JavaScript developer, I'm quite surprised this is the best there is
for cross-platform JavaScript development. [0]:
https://github.com/nodegui/react-nodegui [1]: https://proton-
native.js.org/ [2]: https://github.com/status-im/react-native-
desktop-qt
Author : tentacleuno
Score : 88 points
Date : 2022-03-26 10:44 UTC (12 hours ago)
| kkfx wrote:
| Because of sheep effects and state of things: Big&Powerful want
| all to be web, to be hosted on their datacenters, with the
| maximum lock-in possible, so they push desktops toward classic
| mainframe dumb terminals.
|
| The outcome of such push is:
|
| - we do not have anything really cross platform, at least in
| look&feel terms, there are classic, old, and nearly ignored by
| most (T)Tk but not much more. Windows have it's own GUI, OSX it's
| own as well, Qt have derailed long time ago toward a bloated
| monster with an uncertain future, GTk have derailed since GTk3,
| and both still do not have a real "native look&feel" on all
| platforms;
|
| - developers fear having invested a big amount of time and
| resources on something and then being forced to reinvest time and
| effort just because at a certain point in time a dependency they
| used vanish or substantially changing imposing a almost total
| rewrite of the UI.
|
| WebUI then seems to be the "safest" way to go, at least they can
| "float" between various platforms as needed and people know them
| and like their colored style... However chosen a classic local
| server for a localhost webapp is longer than just grabbing
| something already made and then...
|
| IMVHO the real alternative is say STOP. Witch means for now ok-
| ish to develop locally served WebUIs _or_ classic Tk /fltk/OpenGL
| (depending on the kind of GUI) but certainly not in the
| Electron/node sauce, only the UI and as much detached as possible
| from the core logic for the narrow target. For the broad target
| push back toward a real desktop model. Push _networked_
| applications that are not web thing, like pushing again emails
| with a local MUA, not a webmail, a local maildir not on a remote
| IMAP, locally indexed to have GMail like search (notmuch /mu for
| instance), file sharing apps like SyncThing/Retroshare, Jami for
| audio/video communications etc.
| YATA0 wrote:
| laurent123456 wrote:
| > Why aren't there any real alternatives to Electron?
|
| Because it's not as easy as it seems to create a proper cross-
| platform framework. And even if there was an alternative, these
| days you often need rich text, images, videos, etc. all of which
| are essentially HTML pages. So you'd end up adding a webview
| anyway, which is getting quite close to being Electron.
|
| And I think that's the key - why create an "alternative" to
| Electron if you end up bundling webviews, ffmpeg, libpng and so
| on. It might be a bit smaller in size than Electron but not
| enough that it matters.
| rhl314 wrote:
| I am working on app that I wrote initialy in electron, but now
| have moved away from it.I have perspectives on both good and bad
| sides of electron
|
| _The good parts_
|
| Low barrier to entry - if you know javascript you are good to
| good. No need to learn C++ or Java for building a desktop app.
|
| Truly cross platform - any platforms that chromium supports,
| electron supports
|
| A very active ecosystem - The community around electron is
| amazing. I am a big fan of electron.build, things like code
| signing / auto updates etc are provided out of the box
|
| _The not so good parts_
|
| _IPC hell_
|
| Electron has a main process and renderer process and they
| communicate via events. I found myself swimming in the event soup
| very often.
|
| _Easy to make mistakes_
|
| This is more for a note for me or any beginner, but it is easy to
| write compute heavy code in the renderer and make the ui
| unresponsive or sluggish. There are many other things like this
| where it is easy to do things the wrong way.
|
| _Security_
|
| Electron still has a capable browser which can open any webpage.
| Mix that with native access and you have a remote code execution
| vulnerability on your hands.
|
| _Bloated binaries_
|
| Even the simplest of the electron binaries are large, thats just
| the nature of electron.
|
| Shameless plug
|
| The app that I am working on is https://loadjitsu.com, I rewrote
| it using golang, couldnt be happier.
| zozbot234 wrote:
| > Electron has a main process and renderer process and they
| communicate via events. I found myself swimming in the event
| soup very often.
|
| Ironically, this might also be what you need to write a fast
| _non_ web based client to your app. By keeping the UI renderer
| is in a separate process, it could be written in any language
| or technology at all and the "main" app would be none the
| wiser.
| PhilippGille wrote:
| > but now have moved away from it
|
| What did you move to? You mention Go, but which GUI framework?
| Fyne, Gio UI, bindings for GTK or Qt?
| sys_64738 wrote:
| > Low barrier to entry - if you know javascript you are good to
| good. No need to learn C++ or Java for building a desktop app.
|
| What language would you write the actual app logic in?
| Spivak wrote:
| Rendering engine and toolkits in C++ but application logic in
| Python/Ruby/JS with layouts and styling in their own file
| format. Which describes QT and the Web.
| beowulfey wrote:
| I'm not a JS developer, so take this with much salt, but one that
| caught my eye was SciterJS [1]. It is built using Fabrice
| Bellard's QuickJS engine [2], and appears to be very efficient.
| Definitely has great potential I think. See previous discussion
| here: [3]
|
| [1] https://github.com/c-smile/sciter-js-sdk
|
| [2] https://bellard.org/quickjs/
|
| [3] https://news.ycombinator.com/item?id=24797423
| snarfy wrote:
| The problem with alternative implementations like SciterJS is
| the compatibility is not 100% and you loose access to the rest
| of the ecosystem. All of the js libraries will be hit or miss.
| kaffee wrote:
| Not having access to the js libraries seems like a feature
| rather than a bug. With rare exceptions, third party code
| written in javascript distributed via npm is a liability.
| bavell wrote:
| > *third party code is a liability
|
| FTFY :)
| andrew_shay wrote:
| Sciter is great. It's similar to Electron but very light on
| resources. The creator is very active on the forums too. It'd
| be great to have a GUI/widget toolkit that would look native
| across all platforms but also work be valid HTML/CSS/JS on
| current browsers. It really feels like there is a lot of
| potential for sciter to take over.
| tored wrote:
| Thinking of writing an app in Sciter. I'm doing a mixin
| approach with my own custom backend against Sciter pre-built
| dll.
|
| What would you say is the pros and cons of Sciter?
|
| Is it so lightweight as it claims?
| nunez wrote:
| the funny thing is that all of the apps that run in Electron use
| much fewer resources when run in the browser itself. so thats
| what I do.
|
| i don't think many people outside of us technical folk care about
| electron apps using tons of resources to do what they need to do.
| (many folks run chrome, for example).
| mherrmann wrote:
| There are great alternatives. I used Python and Qt to create my
| file manager fman [1]. It's a tool that needs to start quickly so
| Electron was not an option [2]. I open sourced my build system
| for creating cross-platform desktop apps with this stack in
| minutes [3]. For a quick tutorial, see [4].
|
| 1: https://fman.io
|
| 2: https://fman.io/blog/picking-technologies-for-a-desktop-
| app-...
|
| 3: https://build-system.fman.io/
|
| 4: https://github.com/mherrmann/fbs-tutorial
| baxuz wrote:
| Isn't QTs licence quite expensive for commercial products?
| ronyfadel wrote:
| A true Electron-killer will be one that allows migrating from an
| Electron codebase with 0 code changes, and offer low usage of
| resources by e.g. using WebKit on Mac.
|
| In the meantime, no one will bother explore other options,
| because it just works, even if it's a resource hog.
| zarzavat wrote:
| > Is "just stick Chromium into all your apps" seriously the best
| we can do as an industry?
|
| Yes. What other rendering engine are you going to use? If your
| answer is anything but a web browser rendering engine, then
| consider that any serious UI toolkit in 2022 is certainly going
| to need a WebView UI component: so if you want the WebView UI
| component to be consistent across platforms (you want this), then
| you will have to bundle a web rendering engine _anyway_. In that
| case, why not just use the web rendering engine as your main
| rendering engine?
|
| There's nothing wrong with Electron as a concept. The issue is
| with either: blink being under optimized for this use case, or
| bad Electron apps.
| zozbot234 wrote:
| The Web _is_ semantically consistent across platforms. There 's
| no need to use the exact same rendering code on every platform.
| Spivak wrote:
| Look I get the idealism but being able to target a single
| version of a single browser at a time is vastly simpler than
| dealing with every browsers quirks and missing features.
| ClumsyPilot wrote:
| > There's nothing wrong with Electron as a concept.
|
| There is nothing wrong with Communism as a concept.
|
| Nack in the real world, open Whatsapp desktop and scroll though
| any chat dense with images, it takes me over 40 minutes to
| acroll back 1 year on a 12-core ryzen.
|
| On Telegram Desktop, native client, this takes 30 seconds.
|
| If you think this spitefull disregard of end users is
| justified, you live in cloud coocoo land
| jokethrowaway wrote:
| You could use a webview shared at the system level, so you
| don't have in memory 4 different browser engines.
| oceanswave wrote:
| Browsers themselves don't do this for security snd sandboxing
| reasons. Each tab is another instance.
| kevincox wrote:
| Each tab is a partial instance. There are still many
| resources that are shared globally for performance and
| memory use reasons.
| gmueckl wrote:
| But operating systems are free to map the same read only
| memory pages (e.g. program code) into different process
| address spaces. This is an optimization that running
| processes are generally completely oblivious of. But it
| only works when e.g. the program code is mapped into memory
| from the same file. If every program has a private copy of
| the same library (even if it's bit for bit identical), the
| operating system doesn't have enough information to pull
| this off.
| proto-n wrote:
| I think the part "if you want the WebView UI component to be
| consistent across platforms (you want this)" is a reference
| as to why a built in webview won't be good enough.
| tentacleuno wrote:
| > There's nothing wrong with Electron as a concept.
|
| I'm mainly avoiding it because I want to make an app I can
| _use_ (after all, I 'm primarily making this for myself), and
| not just have a desktop app for... someone. My laptop only has
| 4GB of RAM, so Electron is off the cards for what I need.
| dbbk wrote:
| I'm not even sure that laptops are still sold with 4GB of
| RAM? You have a very niche usecase.
| Beltalowda wrote:
| It lists 37 here [1]. Pretty sure people are still buying
| them.
|
| https://www.mediamarkt.nl/nl/category/_windows-
| laptops-64106...
| skydhash wrote:
| I can say a lot of people only uses computer for typing
| papers or watching movies - bigger display and storage.
| My cousin does everything else on her phone.
| tentacleuno wrote:
| I wish I wasn't poor. Hoping to get a laptop with a bit
| more later on.
| bavell wrote:
| What range of memory usage are you going for? You could maybe
| look into using Electron solely for the GUI and using
| C/Rust/Go for the backend. Haven't done anything like that
| myself but from what I've read it's a decent compromise.
| tentacleuno wrote:
| I'll take anything under 300/500MB as a win, though I admit
| under the circumstances that's going to be very tight.
| dkersten wrote:
| This always frustrated me with Slack. It has often been the
| thing running on my computer using the most RAM, yet Slack is
| _never_ the primary tool I 'm using the computer for. That
| is, communication is always a secondary thing to support my
| work doing something else or to allow me to do that something
| else in a team. Its about that other work though, not the
| communication. Maybe some day soon I'll have a laptop with 32
| GB of RAM and there will be more spare resources available
| for Slack to eat, but until then, I really dislike running
| Slack.
|
| So yeah, I still greatly prefer desktop applications to use
| native UI's and prefer to avoid browser applications where I
| can. But its becoming increasingly hard.
|
| Of course, I, too, am building browser things, since that's
| what the industry seems to demand, so I'm not really helping
| the situation. I do keep meaning to learn Flutter though.
| tentacleuno wrote:
| > This always frustrated me with Slack. It has often been
| the thing running on my computer using the most RAM, yet
| Slack is never the primary tool I'm using the computer for.
| That is, communication is always a secondary thing to
| support my work doing something else or to allow me to do
| that something else in a team.
|
| Same with me, but s/Slack/Microsoft Teams. I personally
| find it absolutely horrendous to use and wouldn't recommend
| it.
|
| > Of course, I, too, am building browser things
|
| Same. That's what I'm primarily familiar with, especially
| React. I hope some day we have something like React Native
| for _desktop_ , where it integrates with the native widgets
| of the platform (Qt, perhaps?) and you just integrate them
| with your app through components... like React Native on
| mobile. It's such a shame this space isn't being properly
| explored yet.
| newaccount74 wrote:
| I would say, use native webviews, eg. WKWebView on macOS.
|
| But unfortunately it comes with occasional bugs that are
| impossible to fix for app developers, so if you want complete
| control you can't use it
| foxhill wrote:
| > What other rendering engine are you going to use?
|
| the native window environment?
|
| > any serious UI toolkit in 2022 is certainly going to need a
| WebView UI component
|
| citation needed. why do slack and discord - communication
| applications - need a web view component?
|
| > In that case, why not just use the web rendering engine as
| your main rendering engine?
|
| because, aside from the frankly obscene memory usage, it adds
| so much to the binary (mIRC used to fit on a floppy), it's
| slow, is bad for battery usage, it doesn't look in line with
| native apps, and it's a _huge_ attack vector.
| easrng wrote:
| > citation needed. why do slack and discord - communication
| applications - need a web view component?
|
| YouTube/SoundCloud/Spotify/etc embeds would need a webview
| component if Discord was a native desktop app.
| foxhill wrote:
| so we can lose local browse history, have to maintain two
| separate login session to each respective service (repeat
| for slack too, where appropriate), all just to have the
| video or song play _in the same window_..?
|
| well, fine, if that's what's required. all of the platforms
| have webview components, i believe.
| qorrect wrote:
| > it's a huge attack vector.
|
| I'm confused by this phrase. Wouldn't it have a 'huge attack
| vector _space_ ' ? I never really understood that phrase.
| otterley wrote:
| Vector is being used here in the epidemiological sense, not
| the mathematical sense.
| nurettin wrote:
| vector is like an angle and a magnitude, perhaps you mean
| attack surface, which is the integral of known attack
| vectors.
| klabb3 wrote:
| > the native window environment?
|
| I'd rather build an app that doesn't require me to start with
| the question "which OS and window environment are you using?"
| followed by "sorry, we couldn't afford to build for that".
|
| The idea that app developers have resources, skills and
| manpower to build ~3-7 UIs using ~2-3 different stacks - for
| exactly the same app - is imo more preposterous imo than
| assuming most users have enough ram to run a chrome+node
| instance.
|
| The failure of standardizing UI has led to this. Electron is
| a stop-gap, a good one. As a Linux user, I am very happy that
| Electron exists, otherwise I would have far fewer apps.
|
| Yes, Electron hogs resources. I am personally using Tauri,
| which has a much lower footprint. Importantly, I can write my
| app once.
| zarzavat wrote:
| > the native window environment?
|
| This means you'll be limited to the intersection of features
| of each platform native rendering engine.
|
| On the other hand you get the union of all bugs and
| performance issues over each native rendering engine on each
| platform.
|
| Text will be a particular nightmare, what browsers do in
| terms of pixel consistent yet native-feeling text rendering
| and input is a miracle.
|
| > citation needed. why do slack and discord - communication
| applications - need a web view component?
|
| Perhaps those apps specifically don't use it, but it is a
| standard component and all modern UI toolkits are expected to
| have one because many apps do need this functionality.
| mikewarot wrote:
| You can use Lazarus IDE/Free Pascal to build small efficient
| executables on most platforms. A small GUI built without debug
| information clocks in at less than 3 megabytes on Windows.
|
| To get to the non Mac/Linux/Windows end users, Free Pascal is
| working on a WebAssembly back end, which should allow you to run
| in a browser. Here's their RoadMap/Status page -
| https://wiki.freepascal.org/WebAssembly/Roadmap
| OJFord wrote:
| Tauri is certainly not dead, and with a security audit in
| progress and a stable release in its fourth RC, it's surely very
| close to 'production ready'.
|
| https://github.com/tauri-apps/tauri/releases/tag/tauri-v1.0....
| FractalHQ wrote:
| Currently using this with Svelte to build a cross platform
| video editor and and my experience so far has been amazing..!
| Rodeoclash wrote:
| I'd be interested in learning a bit more about how you've
| integrated Tauri with video playback. I have a synchronised
| video player tool[1] that I've built in Electron for the
| e-sports community. When I was investigating technology to
| use to build it, I was really set on using GStreamer as I
| could share a clock between all of the videos to ensure the
| synchronisation was perfectly accurate.
|
| Electron hasn't been too bad, I've been able to construct a
| quick prototype which will prove if people are interested in
| what it does. I'd ultimately like to build a native app
| though.
|
| [1] https://github.com/Rodeoclash/vodon-pro
| OJFord wrote:
| Yep I also use it with Svelte for a couple of side project
| tinkerings. Great combination IMO, but I think it was an
| excellent choice to just have a vanilla JS (TS rather, I
| suppose) API on the client side and let people use whatever
| they want, without pushing any sort of suggestion or
| framework plugin.
| tentacleuno wrote:
| Thanks! I'll have a look. Looks promising :)
| uhhuhh wrote:
| Having used tauri for multiple projects I can say, it's
| absolutely worth paying attention too.
| armchairhacker wrote:
| honestly you can use Java or Kotlin. Java/Kotlin targets macOS,
| Windows, and Linux just like Electron. Even though you're
| substituting V8 for the JRE, JRE is much faster and smaller and
| should not eat up your RAM.
|
| The main downside is that you don't get to write your UI in HTML.
| IME, most Java applications look really ugly, but they run very
| fast and work well.
| pengo wrote:
| We use Object Pascal (via Lazarus) and compile the code for each
| target platform. The apps concerned are (only?) dev utilities,
| but they're fast and have a small footprint.
| sys_64738 wrote:
| Electron is the lazy way as there is no barrier to entry. But if
| I wanted to run a web app then I'll use a browser. I avoid all
| electron apps except Teams and Edge. When we have a text editor
| requiring electron then we've truly lost our way.
| jasode wrote:
| _> 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 wrote:
| 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 wrote:
| _> , 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 :
| 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 : 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 wrote:
| 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 wrote:
| _> 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 wrote:
| > 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.
| jasode wrote:
| _> 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.
| rathboma wrote:
| As the creator of a desktop app (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 wrote:
| The question is not why do you use electron. The question is
| why is that the only viable choice goven to you
| kijin wrote:
| > _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 wrote:
| 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 wrote:
| >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 wrote:
| _> 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.
| antihero wrote:
| I wonder if there would be some way of having a system wide
| electrond that hosts the rendering engine, that electron apps
| could check for the existence of and use, instead of having an
| instance for every app. Like a multi tenant electron. I'm aware
| that this is basically a browser, but it would be specialised and
| offer the same level of integration as normal electron unlike the
| tab-in-a-window that Chrome apps were.
| hitpointdrew wrote:
| I saw a project on here a while ago that used Godot to make a
| desktop app. Godot is a "game" engine, but the app posted to HN
| was a business application. I thought it was interesting to use a
| game engine to make a business app, it actually looked quite
| good. I wish I still had the link.
| farseer wrote:
| You know WebGL may replace HTML for user interfaces one day
| especially if coupled with a VR headset. But you would still
| need Chromium for a unified cross platform experience. It's not
| hard to imagine bloody minded developers running a business app
| on Godot, inside a WebGL canvas on Chromium all packaged in an
| electron framework :)
| lucraft wrote:
| This is related, and has a couple examples down the bottom
| https://medium.com/swlh/what-makes-godot-engine-great-for-ad...
| zozbot234 wrote:
| A "game" app like that sounds horrible for accessibility. How
| can this be appropriate to a business environment where any
| users might require special accommodation at some point.
| dartharva wrote:
| Sorry, I'm not very educated in this regard but how would it
| being developed in a game dev environment make it any less
| customisable for accessibility than an app developed in
| anything else?
| Aeolun wrote:
| A quick search gives me Godello:
| https://github.com/alfredbaudisch/Godello
| keithnz wrote:
| how much is discord using? on windows it seems to use very little
| (27MB of RAM).
| anaisbetts wrote:
| If you want to write Linux apps, Flutter is a compelling
| alternative - it's not JavaScript but apps start fast and don't
| use much memory, but you'll still have a fast, React-like dev
| experience. Writing Flutter apps on 4GB of RAM isn't gonna work
| though, as the IDE / Dart analyzer uses a *ton* of memory. Would
| recommend using CodeSpaces or something similar if you go that
| route.
| chakkepolja wrote:
| Anecdote: I have written flutter apps in 4GB of RAM, with both
| Vim+Dart LSP and IntelliJ (somewhat tuned for low memory, but
| it was fine for me).
| Aeolun wrote:
| I just started building with NeutralinoJS, and have previously
| built with NW.js.
|
| Both don't really solve the browser engine thing, but at least
| Neutralino is much smaller in terms of executable size.
|
| I like the idea you can use any language you want for the
| backend/system level stuff, though for me that just means more
| typescript :)
| dmarinus wrote:
| I wish any Electron app would also be available as browser/web
| app, so I could just run it in a browser tab (and save some
| resources/memory?). This is possible for Spotify and Slack but
| not for Signal.
| sys_64738 wrote:
| Can you point Edge at the Signal webpage address? Seems like it
| should work.
| starfleet_bop wrote:
| As a compromise are there any major downsides to instead
| deploying your app that hosts its own lite http server using a
| multi-platform library in Go or Python, which then uses the pre-
| existing web browser to render the UI?
| simion314 wrote:
| This would have been one of the things Mozilla should have been
| involved, have their Rust/Servo team focus on node/electron
| alternatives too, this way they could have gain the minds of
| developers but they would need to somehow be able to accept
| donations for this projects and not for their weird activities
| not related to dev.
| cxr wrote:
| Mozilla was shipping Electron-style runtimes before Electron
| even existed--when computers with 128MB of RAM were still being
| used. These apps worked. The powers that be, in their infinite
| wisdom, decided to kill it (because _obviously_ nobody wanted
| anything like that! the important thing is to do a phone!) That
| was going on ~10 years ago.
|
| The worst part is that the people who fucked that up refuse to
| acknowledge they were wrong. No amount of evidence is enough to
| penetrate their big dumb egos.
| mamcx wrote:
| Electron exist because multi-millon dollar companies and the BEST
| paying people on earth not care about users, at all.
|
| Only what is convenient and fast to do.
|
| ---
|
| Alternatives exist, since long time ago. But developers are LAZY.
| A LOT.
|
| That is why the worst tech that exploit laziness and reward
| instant gratification (php, js, node, mongo, electron...) survive
| and get poured millions on effort fighting them, instead of
| invest is what is better.
|
| Ironically, this kind of tech WASTE money and time like is not
| tomorrow, but that is for later, and the major effects are not on
| the laptops of the developers that made it...
| bsenftner wrote:
| Unpopular but a valid alternative is a wxWidgets application
| using the wxWebView component - very similar to Electron, in that
| it IS Chromium at the core, but it is in it's component pieces.
| One gets to pick and choose at a lower level what portions or the
| entire thing ya want. And being wxWidgets, it runs fine on the
| desktop OSes. But wxWidgets is unpopular, so be ready for
| assholes to tell you what you're doing is wrong.
| zozbot234 wrote:
| Lazarus is a very similar technology based on Pascal. The
| language is a bit unusual but you could use it to design a
| cross-platform frontend that would connect to a separate
| "server" process running your app code.
| heavyset_go wrote:
| Qt's QML is both declarative and reactive, and even lets you
| program in JavaScript or TypeScript. It also uses a tiny amount
| of memory and it's really fast. It's the closest thing to the
| React and Electron model while still being fast and efficient.
|
| There are some suggestions, on Mozilla's suggestion platform
| Mozilla Connect, for turning Gecko into something like
| Electron[1][2].
|
| In the past, Mozilla ran the Positron project, which was an
| Electron-like library on Gecko[3].
|
| [1] https://connect.mozilla.org/t5/ideas/create-an-
| alternative-t...
|
| [2] https://connect.mozilla.org/t5/ideas/ability-to-embed-
| gecko-...
|
| [3] https://github.com/mozilla/positron
| zagrebian wrote:
| Why isn't discord.com a PWA already? What are they waiting for?
| mccorrinall wrote:
| Have you tried using it on a phone? It's a horrible experience
| compared to the app.
| mort96 wrote:
| But this thread is discussing desktop software..?
| zagrebian wrote:
| Yes, if discord.com works great in a desktop browser, then
| there should be no reason why it couldn't be an installable
| PWA.
| speedgoose wrote:
| It's already a PWA app.
| zagrebian wrote:
| I checked in Chrome on macOS, and discord.com does not have a
| web app manifest nor a service worker.
| kevincox wrote:
| There are some tradeoffs on the browser version:
|
| - No "currently playing" detection.
|
| - No global hotkeys.
|
| - Reduced noice canceling and other audio cleanup.
|
| Maybe a few others that I can't think of off of the top if my
| head. But for me personally the browser version is way better.
| I don't want them snooping on what is running on my system, I
| have a global mute+unmute hotkey (that I trust and works for
| all apps) and I already have better processsing on my mic at
| the system level.
| 2muchcoffeeman wrote:
| Wikipedia says the first web browser was created in 1990. And it
| says electron is 8 years old.
|
| So it took 24 years to get a cross platform rendering engine that
| was feature rich enough for great desktop apps. Even if we take
| these learnings, how long till we get a new framework good
| enough?
| cxr wrote:
| Gecko-/XULRunner-based applications (like Firefox) predate
| Electron by many, many years.
| berryton wrote:
| You may be interested in Tauri: https://tauri.studio/
| farseer wrote:
| You can use JavaFX or QT (with c++ or python) but they are no
| match for the eye candy that is to be had with html5 and css3.
| It's your job to integrate with the platform style, you have the
| flexibility to do so.
|
| Resource usage is a problem but has become manageable over the
| years. See how pretty and efficient VSCode is. And honestly thank
| God we have electron, before that a truly cross platform
| ecosystem was limited to Java and that abomination Adobe AIR.
| tjpnz wrote:
| >Resource usage is a problem but has become manageable over the
| years.
|
| I'd add that when VSCode started to gain popularity it was
| common for a dev system to have only 8~16 GB of memory. In most
| cases that's now more than doubled.
| secondcoming wrote:
| That's great for devs, but what about the end-user? They're
| likely not all on the latest Macs with gigabit fibre.
| dkersten wrote:
| > In most cases that's now more than doubled.
|
| Really? I still find it difficult to get a laptop with more
| than 16 GB of memory.
|
| 13" MBP maxes out at 16 GB. 14" does have 32 for $500 more,
| which might be ok for a company but is certainly a lot for me
| to spend personally just so I can run Electron apps
| comfortably. Non Apple laptops are similar.
|
| If I'm buying a laptop instead of a Desktop, its for the
| ability to conveniently bring it with me when I'm not at
| home. For that, 13" is my preferred form factor. So at least
| Apple and Dell laptops, I have not seen one with more than 16
| GB. I feel its unreasonable to expect me to sacrifice
| physical comfort just so apps can be written to use Electron.
| sshine wrote:
| Buying a gaming laptop, you can easily get 32GB RAM without
| paying a premium.
|
| If you want a MacBook Pro M1 with 32GB RAM, the total cost
| is easily twice.
| ClumsyPilot wrote:
| 'Buying a gaming laptop, you can easily get 32GB RAM
| without paying a premium'
|
| I appreciate gaming laptops, but it cannot be a
| requirement to run some basic electron apps that very
| user needs day to day.
|
| Why should it take more RAM to run teams htat it does to
| edit 8K video?
| jokethrowaway wrote:
| QML or QWidgets + QSS let you style things as much as you can
| on the web. The DX is great, their IDE is world class and
| resource consumption is low.
|
| The only reason Electron is popular is that company who shoot
| at multiplying their revenue need to have web apps - which
| brought up the demand and salaries of web developers. Web
| developers being in such a high demand means that people will
| learn more of web stuff over native.
|
| At the beginning of my career I was equally doing as many Qt
| projects as web projects. Nowadays, when I'm targeting only the
| better paying clients, I do pretty much only web. The developer
| experience in Qt is significantly better than anything web
| related (even after QML got introduced).
|
| Jobs in C++ / Qt pay significantly less than what I'm getting.
| Same for most Haskell / Rust jobs.
|
| If the choice is dealing with the pile of crap that web
| development is and making less money, I'd go with the money.
|
| Things are changing in regards to Haskell / Rust, thanks mainly
| to cryptocurrency. The amount of money generated by the
| speculation in the crypto world and the fact that a few
| projects use Rust / Haskell means we're finally getting
| decently paid jobs using nice languages.
| paulryanrogers wrote:
| Using Qt now for a fairly simple app and it's got a lot of
| friction if you really want multiplatform. Updates are such a
| pain and Qt Creator can't seem to manage maintaining my
| settings for even the smallest patch version updates. (Thus
| requiring lots of fiddling each time or working around its
| wonky defaults.)
| BaseballPhysics wrote:
| > Resource usage is a problem but has become manageable over
| the years. See how pretty and efficient VSCode is.
|
| Has anyone else noticed that, in defense of Electron, everyone
| always trots out this one example, but... that's it? Like,
| where are all these other magnificently efficient Electron
| apps? If it's that easy, surely there must be others. And
| yet...
| rg111 wrote:
| Tangehtial comment: I do not use the Discord Electon app, but use
| it as a pinned tab on Firefox.
|
| I would not trust a full browser running on my machine on which I
| have no control and they can mine whatever telemetry data they
| want.
| hiimshort wrote:
| I haven't gotten around to trying Tauri, but I've meant to.
| Perhaps you'll find it interesting?
|
| https://tauri.studio/
|
| If memory serves, it reuses the OS default web view and any
| "backend" or system things are done in Rust.
| Octoth0rpe wrote:
| This saves on the download size of an app, but doesn't
| significantly reduce the resource usage or non-nativeness of
| the resulting app. Another pro is that as noted 'system things'
| are done in rust, but I'm not sure that's a big bonus since
| your frontend likely has significant bits of js _anyway_.
| You've effectively increased the language count in your app.
| Otek wrote:
| Electron is absolutely unbeatable when it comes to being cross-
| platform. Because its core is the same as Chromium, every time
| Chromium, the biggest browser engine without question, is updated
| to run better, more stable on every platform, and big companies
| pump millions of dollars into it, Electron gets it "for free".
| Very hard to compete with that. Additionally, writing Electron
| applications has a relatively low entry point because it
| resembles writing web pages to some extent.
| blorenz wrote:
| F117-DK wrote:
| why?
| blorenz wrote:
| Wow I didn't mean for that to be a controversial response.
| My apologies. The parent comment referred to Electron being
| "absolutely unbeatable". That is my belief of not being in
| the spirit of a hacker or have the willingness to disrupt
| the status quo. We have accepted Electron's glaring
| shortcomings as a whole and consistently complain about it.
| There are projects out there that try to satisfy these
| points in each of them has particular trade offs. I hope to
| see these contenders rise. One thing I do know from my time
| in tech is not to get too complacent with the single tech
| who monopolies a problem space. Innovations will prevail.
| avazhi wrote:
| "This is an absolutely horrendous answer and goes against the
| spirit of being a hacker."
|
| What a lazy, pathetic response - not just unreasonably
| abusive, but also a response that makes two pretty strong
| claims ('absolutely horrendous answer' and 'goes against the
| spirit of being a hacker') without offering a single shred of
| evidence or even just an explanation of why you hold this
| opinion.
| danlugo92 wrote:
| Just ignore em
| ostenning wrote:
| Your response seems even worse
| avazhi wrote:
| I expressed an opinion and then gave the reasons why I
| have it.
|
| Not sure you understood my initial comment.
| heavyset_go wrote:
| It goes against the HN guidelines.
| Ourgon wrote:
| Cut it out with the ad-hominems or move to Reddit.
| [deleted]
| 28304283409234 wrote:
| You used flamable wording.
| ostenning wrote:
| You edited every comment multiple times downplaying your
| abusive comments, no point arguing with a troll
| avazhi wrote:
| I edited two comments to give the original commenter the
| benefit of the doubt and to be less inflammatory.
| Interesting that you think that's trolling.
|
| Good day.
| dkersten wrote:
| I edit most of my comments multiple times, until I'm
| happy with their tone, content and grammar. I do proof
| read them before posting, but things still slip through
| often, especially when its a comment with a more
| combative tone. Sometimes it takes a little time to tone
| it down and bring it more inline with my intent,
| especially if I didn't realize how combative it was
| originally.
|
| I think that's pretty normal and reasonable and certainly
| not trolling.
| sshine wrote:
| This is getting meta, but I agree: I usually can't see
| what I'm writing before I have hit submit. It's as if the
| simulating-what-the-other-person-sees doesn't kick in
| until they actually have an opportunity to read it.
|
| It'd be trolling if the intent was to gaslight.
|
| Otherwise, toning down aggression is a virtue.
| blorenz wrote:
| You are right. I posted a follow up response under another
| comment here. Thank you for holding me accountable.
| avazhi wrote:
| Thanks for that, and I agree with you about something
| being considered 'unbeatable' and the industry becoming
| complacent about it. I think the original poster probably
| meant that it's only currently unbeatable, not unbeatable
| in perpetuity. At any rate, I definitely agree that the
| hacking mentality is inherently subversive and rebellious
| vis-a-vis monopolists (and just in general, for the
| intellectual challenge and bragging rights), and for
| whatever it's worth I hate Electron for the same reason
| as OP - it's slow and the battery life sucks (even on an
| M1 Pro).
| refactor_master wrote:
| I'd argue that's exactly what a hacker is. You're doing
| something that works and serves a purpose, even though it
| might not be pretty.
| karmakaze wrote:
| The person who made and first used Electron is a hacker.
| Everyone now is merely taking the path of least resistance,
| which is not what a hacker is.
| infinitezest wrote:
| It provides reasonable explanations for the question that was
| originally asked. Efficiency is being traded for portability.
| We may not like that but plenty of people are using app built
| an electron everyday and a lot of those people aren't even
| paying attention to how much RAM it uses.
| heavyset_go wrote:
| Users do notice things like "my computer heats up and the
| fans are loud when I use this app" and "my computer slows
| down if I open this app with other apps already open".
| greggsy wrote:
| Additionally, there's a point where the user's desired use
| case is just isn't reasonable. 4gb RAM is very little to
| work with, particularly in a world where 8gb is the norm.
| ClumsyPilot wrote:
| You do realise that sone people live in poorer countries
| and can't afford newest and latest?
| evocatus wrote:
| It's too late. The dilution of the hacker community has
| crossed a critical threshold.
| farseer wrote:
| This! An arrangement unlikely to change anytime soon.
| pschastain wrote:
| And what happens when Google decides to move in a different
| direction and drop development of Chromium? It's highly
| unlikely but Google does have a track record of dropping
| projects and products for the most obscure and obtuse of
| reasons.
| zozbot234 wrote:
| We'll just go back to KHTML.
| farseer wrote:
| Fork Chromium?
| krapp wrote:
| I've been assured by Hacker News that this is effectively
| impossible for any entity without Google's resources or
| budget.
| HWR_14 wrote:
| I mean, Microsoft tried to build a Chrome killer (Edge)
| put real money and talent behind it, and failed.
|
| So now Edge is a Chromium fork, which is sad.
| raydev wrote:
| > Microsoft tried [...] and failed.
|
| They didn't fail, they quit. You can't build something as
| enormous and complex as a modern and performant web
| browser that keeps up with modern standards for only 3.5
| years.
|
| They did the same with Windows Phone but worse, since
| they had to reset development twice or three times and
| there was a growing ecosystem of third party apps that
| got tossed around.
|
| That's not trying. Microsoft doesn't try, they make very
| brief attempts and then give up just as soon as people
| start paying attention to them.
| farseer wrote:
| True that. I think a large corp such as Microsoft would
| gladly sponsor Chromium were Google were to abandon it.
| It is also suicidal to fork the Linux kernel but you do
| it if the necessity arises such as Android.
| paulryanrogers wrote:
| Isn't Android striving to minimize its changes to Linux
| kernel?
| chakkepolja wrote:
| I think this answer does not emphasize the main point enough.
|
| It's not about the quality of chromium at all, only ubiquity.
|
| Web developers are cheap, its easy to port website's code and
| slap UI on it. That is the _main_ point.
|
| The manager for whom electron is an option is least bothered by
| chrome being technically solid foundation. His motive is using
| cheap webshits and ticking a box.
|
| Doesn't help other cross platform toolkits are either outdated,
| or immature, or in a weird position like Qt.
|
| Our industry always optimized for some sort of local maxima.
| From a purely engineering perspective, scripting languages, or
| hacky UNIX/C glue, or weak typing, would not have made sense at
| all. But they sticked, because they fulfilled immediate
| commercial needs.
|
| I don't know if this phenomenon is prevalent in other
| disciplines of engineering or there is a common name for it.
| gmueckl wrote:
| This means that software development is a failing discipline.
| All we can do is to come up with ever more ridiculous layers of
| complexity on top of mindboggling complexity, recursively. All
| of this is totally self-inflicted. The problem domains that our
| software needs to deal with are complex enough. But we keep
| piling on shit of our own making.
|
| If this is what software development has become, then there's
| no way it won't end in total and utter disaster when people
| start to recognize the already all too common piss poor
| products that barely manage to do the absolute minimum and
| rebel against them. It may not be marketing department of the
| Sirius Cybernetic Corporation who'll be lined up against the
| wall first, but software developers when the revolution comes.
|
| Crap. I'm now old enough to remember when computers were fast.
| :(
| porknubbins wrote:
| Using Visual Studio as a native app felt quick, as if could
| really believe the metaphor that I was interacting with a
| predictable mechanical device that worked the same every
| time. VS Code I am constantly aware that I am interacting
| with a bunch of layers of sofware, like it might take 1
| second or 10 seconds to do something.
| Arainach wrote:
| Really? VS Code has been the best example of what Electron
| could be that I've seen. In practice it's just as
| responsive as Sublime Text 3 for files under 25MB.
| eyelidlessness wrote:
| In my experience it depends how you use VSCode. For one
| project (and only a few well behaved extensions), even if
| it's quite large, it can perform very well. Working in
| multiple projects the proscribed way (workspaces) comes
| with a variety of caveats. Multiple windows can increase
| CPU and RAM load pretty fast.
| musicale wrote:
| VS Code is indeed one of the best Electron apps.
|
| And it's also unpleasantly clunky and heavyweight, with
| unpredictable unresponsiveness as GP notes.
| emerged wrote:
| It's been my daily IDE for a couple years and the only
| time it felt clunky or overweight is when I had installed
| a misbehaving extension. I remember feeling as you
| described, but after removing the bad extension it became
| snappy again.
|
| I think they actually have a tool for discovering which
| extension is the bottleneck?
| [deleted]
| elcomet wrote:
| Computers are still fast when they need to be fast (data
| processing or other stuff). But you don't need any note
| taking or food ordering app to be lightning fast so why care
| ?
| rektide wrote:
| > _This means that software development is a failing
| discipline. All we can do is to come up with ever more
| ridiculous layers of complexity on top of mindboggling
| complexity, recursively. All of this is totally self-
| inflicted. The problem domains that our software needs to
| deal with are complex enough. But we keep piling on shit of
| our own making._
|
| Awwhhh why so glum? This sounds so alarmed, so fraught &
| bleak!
|
| I don't see anyone as having a bead yet on what the final
| destination is, on what is right or perfect. I see change &
| innovation & exploration as necessary, ongoing, and this
| layering of platforms atop each other is part of that larger
| bigger quest for us all to learn what serves ourselves well,
| to figure out how we align.
|
| Overall these Adapter layers are quite performant, quite
| fast, and they isolate rather than leak complexity quite
| effectively. Electron's doesn't have to invent a ton of stuff
| to create this pleasant, familiar environment for developers
| or users- the operating system is simply not that relevant,
| is easily adapted, by a pretty boring regular programming
| language (Node.JS) and the world's most popular multimedia
| page/resource system (the browser).
|
| Right now, yes, we have the web platform as a layer above
| native in many cases, but I'm not sure that that is so
| alarming. Maybe it's transitional? The early smartphones were
| both enormously web first, decided to use something great
| rather than reinvent: the Palm Pre and original iPhone (which
| was webapps only). In modern times, there's ChromeOS, and
| Palm's webOS continues under new stewartship, mainly on TVs.
| If the complaint is layers of complexity, maybe we just need
| to get rid of proprietary & legacy platforms, & embrace the
| common, shared medium that all computing has. Or find new
| unifying better platforms!
|
| In general, I see these new platforms as being extremely
| liberating, as helping reduce the complexity developers have
| to mess with, by offering a set of well-defined standards &
| well known constraints & behaviors. Rather than a
| complicated, particular OS tied to some specific devices,
| with it's own quirks, with ever evolving platform
| capabilities & changing toolchain
|
| > _If this is what software development has become, then
| there 's no way it won't end in total and utter disaster when
| people start to recognize the already all too common piss
| poor products that barely manage to do the absolute minimum
| and rebel against them. It may not be marketing department of
| the Sirius Cybernetic Corporation who'll be lined up against
| the wall first, but software developers when the revolution
| comes._
|
| Again I think moderation is good council here, but I also
| agree in principle that there is some awareness software can
| be a bit of a disaster, and it's visible that sometimes
| updates & "improvements" serve external interests not the
| users.
|
| Where I differ is I see Electron as a fairly hopeful,
| possible open future for computing, that does embrace users,
| more so than most software. Most software is not malleable,
| not adaptable. Electron, on the other hand, offers the very
| slick, open ended DevTools Protocol for most every app, which
| allows users control & automation & expansion of software. We
| can write some userscript & change the behavior of
| webplatform & electron systems, which is hugely powerful, is
| a far fairer shake & far more liberty than most computing
| platforms, where apps are usually compiled down, fixed in
| form & nature.
|
| This second paragraph really brings me back to where we
| started: I don't think we have a bead yet, as a larger world.
| It feels like there's so much discovery, so much
| understanding to develop. What makes me hopeful is groups
| like https://wicg.io , which try to understand & consider how
| we might do better, which work to build open standards for
| the internet, for our shared multimedia platform, as a
| community, securely. There's so much further for all
| computing to go, so much we need to do to better serve users.
| I don't see anyone has having a strong lock on that, it feels
| like there's more to learn & become than there is that we've
| locked down, by far, so I am hopeful & excited & happy to see
| us staying malleable, working to unblock innovation at all
| levels, in all computing. Electron is a great & positive
| force here, albiet I look forward to other projects listed in
| the comments such as Tau providing similar-ideas with
| slightly-different execution.
| cyanydeez wrote:
| Yawn.
|
| What's important to the majority of computing tasks is
| boring, doesn't need super computer sppeds or IoT sized
| products This lament is really narrow sighted.
|
| Resources are cheap for the majority
| paulryanrogers wrote:
| This doesn't scale though. My mouse needs an always running
| Electron app. And the app suspends itself somehow everytime
| my computer is locked or the screen sleeps. This leads to a
| 30 second wait while it awakens when I get back.
|
| Now if every device and app is built on Electron with such
| minimal effort then I'm not sure even resurrecting Moore's
| Law could keep up.
| paxys wrote:
| So you bought and are using a mouse that takes 30 seconds
| to wake up from sleep, and are using that as the
| justification for why _Electron_ is bad?
| paulryanrogers wrote:
| The point is not one anecdote alone. It's the trend my
| example highlights. IME it's hard to buy a feature rich
| device without needing to run more and more electron
| apps. Or have a tech job without such apps. This cannot
| scale to everything even if physics weren't standing in
| the way of significant die shrinks.
|
| EDIT: Forgot to mention that if I configure the device to
| do 'hardware' assignment then it's not as bad a problem.
| (Yet at the cost of some flexibility.) So it suggests
| that the software level bindings are being loaded through
| this Electron abomination.
| paxys wrote:
| I don't see how you can call it a "trend" when I can't
| think of a single mainstream device with such a
| requirement.
| raydev wrote:
| What's a high quality programmable gaming mouse that
| doesn't require an app to manage it?
| paxys wrote:
| Core functionality for all these devices will work
| perfectly well without an app.
|
| For functionality that does need additional configuration
| (like extra buttons, RGB colors), you will have to
| install a companion app and use it _once_.
|
| There's no case where a peripheral will be non-functional
| unless a heavy electron app is permanently running
| alongside it, as the parent comment alleged. If there is,
| it is absolutely not the standard.
| throwaway986723 wrote:
| chestnuttrees wrote:
| I mean yeah you buy bad products and they'll be bad...
| They'd manage to fuck that up in native land as well.
| Seems orthogonal.
| ClumsyPilot wrote:
| Ah so 2008. Was not caused by rampant fraud in banking,
| its just that many people bought bad products. In fact
| that explains away any injustice that ever happened!
| paulryanrogers wrote:
| Getting harder to buy products that don't suffer from
| these kinds of problems as Electron enables producers to
| cheap out on software development at the cost of user
| time and energy.
| eternityforest wrote:
| My question is why Electron isn't a shared OS level thing.
|
| It seems like Chrome OS really had the right idea. Can't we have
| some cross platform app format that's just a ZIP file full of
| HTML, with some APIs that go beyond normal web features?
| ClumsyPilot wrote:
| Windows 10 apps can be written in javascript, have access to
| all system APIs and can be rendered in system webview based on
| chromium, but developers are still too lazy to learn it and use
| it
| eternityforest wrote:
| Now we just need Linux and Android to do the same, because
| that's amazing.
| The_rationalist wrote:
| Ionic/capacitor/cordova apps are all using the same shared
| webview instance, electron problem is a sad idiosyncrasie.
| In fact Ionic apps are smaller than native/flutter apps.
| yes_but_no wrote:
| At this point its hard to come up with interesting arguments. I
| don't like electron as much as the next guy, but if you ever
| tried to develop a desktop app you can easily appreciate Electron
| for what it is.
|
| Anyway heres some other choices might be viable these days: -
| Flutter desktop https://flutter.dev/multi-platform/desktop -
| Jetbrains Compose https://www.jetbrains.com/lp/compose-mpp/
|
| IMO immediate mode guis should be option as well, like imgui,
| egui. (But afaik you basically throw accessibility out of the
| window)
| krapp wrote:
| The Lagrange browser for Gemini[0] was built in C with and it's
| cross-platform thanks to SDL. It's still possible.
|
| [0]https://github.com/skyjake/lagrange
| [deleted]
| nickosmark wrote:
| Canonical is using Flutter for many apps in Ubuntu Desktop,
| including the installer.
|
| [0]https://github.com/orgs/canonical/repositories?q=&type=all&l
| ...
| occz wrote:
| Even though Compose Desktop is still Alpha, I think you can
| probably make something viable with it, after having tested it
| out a while.
| Octoth0rpe wrote:
| Worth noting that learning Flutter means learning the language
| Dart, which is good for pretty much exactly one thing: writing
| flutter apps. If a friend was seeking to achieve proficiency in
| either frontend web tooling for the purposes of writing an
| electron app versus learning Dart, I know which _I'd_ recommend
| to said friend given the long term marketability of each.
| raydev wrote:
| > learning Flutter means learning the language Dart
|
| I think any current experienced software developer can easily
| switch between 3 or 4 popular languages, and pick up Dart
| quickly too since it's not that different from everything
| else out there. Dart is not Brainfuck or Lisp.
| Barrin92 wrote:
| for what it's worth I recently tried Flutter out and despite
| having never used Dart I kind of.. could just write it. It
| feels like the most unopinionated Algol type language ever
| and I've you've ever written Java or C# or JS it's very
| natural to pick up.
|
| It bothered me so little that overall Flutter seemed way
| simpler to me than the web-tech stack because I had also very
| little experience with web apps.
| Octoth0rpe wrote:
| I'm mainly a js developer these days, and I'd agree with
| that. At a language level, sure, Dart is quite easy to pick
| up. For every language though, I find the much harder part
| of being proficient is learning the ecosystem/best
| practices.
| teg4n_ wrote:
| Everyone forgets about accessibility. Sure you can imagine just
| rendering various widgets to the screen but then coming up with
| a cross platform accessibility model that works with users'
| existing tech is always pushed to the far off future. The
| amount of work done on platform native ui kits is astounding
| and web is the only platform I'be used that can remotely come
| close.
| black3r wrote:
| Developers often work on high-specced laptops and it's hard for
| us to even remember how using 4GB of RAM feels like. My first
| laptop I used for professional work had 16GB of RAM and that was
| a 1000EUR laptop 9 years ago. That laptop still works and Discord
| is usable on it.
|
| On the other hand I did see a computer with 512MB of RAM in use
| at a high school in my country in 2018, so I understand that in
| some places people can't afford to upgrade their hardware.
|
| But if RAM is the only issue and most 15 years old hardware can
| be upgraded to 8GB or 16GB of RAM for 80EUR, I believe that most
| developers simply see problems on 4GB RAM systems as a non-issue.
| gwbas1c wrote:
| On Windows and Mac I make application shortcuts directly in
| Chrome. These use the same amount of resources as an ordinary
| tab, but appear just like a desktop application. I have
| dock/taskbar icons for Gmail, calendar, YouTube music, ect.
|
| I don't use Linux, but given that Edge also supports this, I
| suspect that you can do this with Chromium.
|
| I'm not on my computer, but the steps are to hit the hamburger
| menu, select create shortcut, and then select the checkbox. The
| words vary, but it's usually something like "run in separate
| window" or "run as application."
| moron4hire wrote:
| I do this for a lot of stuff (probably a dozen different apps,
| on Windows, Linux, macOS, and Android), but there are apps that
| wouldn't be able to rely on this. VSCode, for example, wouldn't
| have good enough system access to work.
|
| However, the are some apps that could do this, but have hidden
| some of their features in the Election version. E.g. it's
| frustrating that Slack can't have multiple groups in a single
| browser tab.
| kevincox wrote:
| The added benifit and drawback here is that you keep the app in
| the browser sandbox. For me that is what I want 95% of the time
| anyways. But for apps that really benifit from accessing native
| resources with no permission requests it is a downside.
___________________________________________________________________
(page generated 2022-03-26 23:02 UTC)