29 ms·

Ask HN: Why aren't there any real alternatives to Electron?

119 points by tentacleuno 5y ago

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 https://github.com/nodegui/react-nodegui [1]: https://proton-native.js.org/ https://proton-native.js.org/ [2]: https://github.com/status-im/react-native-desktop-qt https://github.com/status-im/react-native-desktop-qt

zagrebian 5y ago
Why isn’t discord.com a PWA already? What are they waiting for?
- mccorrinall 5y ago
  Have you tried using it on a phone? It’s a horrible experience compared to the app.
  - mort96 5y ago
    But this thread is discussing desktop software..?
    - zagrebian 5y ago
      Yes, if discord.com works great in a desktop browser, then there should be no reason why it couldn’t be an installable PWA.
- kevincox 5y ago
  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.
- speedgoose 5y ago
  It’s already a PWA app.
  - zagrebian 5y ago
    I checked in Chrome on macOS, and discord.com does not have a web app manifest nor a service worker.
berryton 5y ago
You may be interested in Tauri: https://tauri.studio/ https://tauri.studio/
farseer 5y ago
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 5y ago
  >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 5y ago
    That's great for devs, but what about the end-user? They're likely not all on the latest Macs with gigabit fibre.
  - dkersten 5y ago
    > 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 5y ago
      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.
hiimshort 5y ago
I haven't gotten around to trying Tauri, but I've meant to. Perhaps you'll find it interesting? https://tauri.studio/ https://tauri.studio/ If memory serves, it reuses the OS default web view and any "backend" or system things are done in Rust.
- Octoth0rpe 5y ago
  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 5y ago
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 5y ago
  - F117-DK 5y ago
    why?
    - blorenz 5y ago
      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 5y ago
    - danlugo92 5y ago
      Just ignore em
    - ostenning 5y ago
yes_but_no 5y ago
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 https://flutter.dev/multi-platform/desktop - Jetbrains Compose https://www.jetbrains.com/lp/compose-mpp/ 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 5y ago
  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 https://github.com/skyjake/lagrange
- occz 5y ago
  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 5y ago
  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.
  - Barrin92 5y ago
    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.
gwbas1c 5y ago
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 5y ago
  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 5y ago
  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.
laurent123456 5y ago
> 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.
beowulfey 5y ago
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 https://github.com/c-smile/sciter-js-sdk [2] https://bellard.org/quickjs/ https://bellard.org/quickjs/ [3] https://news.ycombinator.com/item?id=24797423 https://news.ycombinator.com/item?id=24797423
- snarfy 5y ago
  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 5y ago
    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 5y ago
      > *third party code is a liability FTFY :)
- andrew_shay 5y ago
  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 5y ago
    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?
ronyfadel 5y ago
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 5y ago
> 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.
- jokethrowaway 5y ago
  You could use a webview shared at the system level, so you don't have in memory 4 different browser engines.
  - oceanswave 5y ago
    Browsers themselves don’t do this for security snd sandboxing reasons. Each tab is another instance.
    - kevincox 5y ago
      Each tab is a partial instance. There are still many resources that are shared globally for performance and memory use reasons.
    - gmueckl 5y ago
      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 5y ago
OJFord 5y ago
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.0-rc.4 https://github.com/tauri-apps/tauri/releases/tag/tauri-v1.0....
- FractalHQ 5y ago
  Currently using this with Svelte to build a cross platform video editor and and my experience so far has been amazing..!
  - OJFord 5y ago
    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.
  - Rodeoclash 5y ago
    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 https://github.com/Rodeoclash/vodon-pro
- tentacleuno 5y ago
  Thanks! I'll have a look. Looks promising :)
- uhhuhh 5y ago
  Having used tauri for multiple projects I can say, it's absolutely worth paying attention too.
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?
antihero 5y ago
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 5y ago
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 5y ago
  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 :)
  - hitpointdrew 5y ago
    I am no Godot expert. But from the documentation it seems like you can compile and cross compile for other platforms without the need for electron. The exception being for Mac/iOS, which requires Xcode to compile, so if you wanted to compile for all platforms you would need Mac.
- lucraft 5y ago
  This is related, and has a couple examples down the bottom https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b https://medium.com/swlh/what-makes-godot-engine-great-for-ad...
- zozbot234 5y ago
  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 5y ago
    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?
keithnz 5y ago
how much is discord using? on windows it seems to use very little (27MB of RAM).
anaisbetts 5y ago
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 5y ago
  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 5y ago
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 5y ago
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 5y ago
  Can you point Edge at the Signal webpage address? Seems like it should work.
simion314 5y ago
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 5y ago
  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.
  - fomine3 5y ago
    Similarly(?) Firefox OS was killed before KaiOS become a big thing.
bsenftner 5y ago
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 5y ago
  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.
2muchcoffeeman 5y ago
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 5y ago
  Gecko-/XULRunner-based applications (like Firefox) predate Electron by many, many years.
- johnisgood 5y ago
  How old is Tcl/Tk?
eternityforest 5y ago
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 5y ago
  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 5y ago
    Now we just need Linux and Android to do the same, because that's amazing.
    - The_rationalist 5y ago
      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.
  - IshKebab 5y ago
    They're not too lazy to learn it. They want something that doesn't only work on Windows 10.
rhl314 5y ago
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 https://loadjitsu.com, I rewrote it using golang, couldnt be happier.
- zozbot234 5y ago
  > 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 5y ago
  > 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 5y ago
  > 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?
sys_64738 5y ago
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.
black3r 5y ago
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 1000€ 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 80€, I believe that most developers simply see problems on 4GB RAM systems as a non-issue.
kkfx 5y ago
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.
mikewarot 5y ago
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 https://wiki.freepascal.org/WebAssembly/Roadmap
mamcx 5y ago
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...
nunez 5y ago
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).
YATA0 5y ago
mherrmann 5y ago
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 https://fman.io 2: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ https://fman.io/blog/picking-technologies-for-a-desktop-app-... 3: https://build-system.fman.io/ https://build-system.fman.io/ 4: https://github.com/mherrmann/fbs-tutorial https://github.com/mherrmann/fbs-tutorial
- baxuz 5y ago
  Isn't QTs licence quite expensive for commercial products?
  - heavyset_go 5y ago
    As long as you adhere to the terms of the LGPL, you can use QML in commercial products for free. There are some add-ons that are distributed under the GPL 2 or 3, though. You can use this page[1] to navigate the licenses for Qt. [1] https://www.qt.io/product/features https://www.qt.io/product/features
rg111 5y ago
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.
starfleet_bop 5y ago
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?
armchairhacker 5y ago
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.
- Fire-Dragon-DoL 5y ago
  Do we run the same java apps? Every time i encounter a java app the ui is way less responsive than any electron app. Of course, this might be due to the ui framework, still point stands.
pengo 5y ago
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.
heavyset_go 5y ago
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-to-electron/idi-p/268 https://connect.mozilla.org/t5/ideas/create-an-alternative-t... [2] https://connect.mozilla.org/t5/ideas/ability-to-embed-gecko-as-an-alternative-to-chromium-embedding/idi-p/186 https://connect.mozilla.org/t5/ideas/ability-to-embed-gecko-... [3] https://github.com/mozilla/positron https://github.com/mozilla/positron
hpen 5y ago
As native tools get easier to use I believe they are the way to go
graderjs 5y ago
I'm working on an alternative. It's a slightly different take, but provides similar functionality of Node.js plus front end code in a packaged binary. Instead of using a weird custom fork of chrome and downloading that for every different binary we just use the system Chrome browser (or install it once for all apps). Eventually we can probably expand to use other Chrome browsers or even other web driver supported browsers which Firefox seems to be building that support out. I just like the idea of using something that's already on the system. Take a look at the wonderful GraderJS, heh :) https://github.com/crisdosyago/graderjs https://github.com/crisdosyago/graderjs
pipeline_peak 5y ago
> Is "just stick Chromium into all your apps" seriously the best we can do as an industry? Is there a layout engine that performs faster and more flexible?
- krapp 5y ago
  Literally every other layout engine in existence is faster and more flexible, even the ones that use native webviews. And what does "flexible" mean? With Electron you're limited by what HTML/CSS/JS allows you to do, that limitation doesn't exist in native. Do you really think hacking a document display model to simulate a GUI allows greater flexibility than everything else out there?
  - pipeline_peak 5y ago
    You mean Gecko and Webkit? Okay
mekster 5y ago
Why don't you open them in browser tabs, let notifications come through your phone when they're closed?

gmueckl 5y ago

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

cyanydeez 5y ago
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
- wtetzner 5y ago
  > Resources are cheap for the majority Sure, if you're OK with running only one or two applications at a time. Also, if applications were written with care toward performance/resources, imagine how much more those applications could do?
- paulryanrogers 5y ago
  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.
  - chestnuttrees 5y ago
    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.
    - paulryanrogers 5y ago
      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.
    - ClumsyPilot 5y ago
      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!
  - paxys 5y ago
    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 5y ago
      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 5y ago
        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 5y ago
        What's a high quality programmable gaming mouse that doesn't require an app to manage it?
        paxys 5y ago
        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 5y ago
      [flagged]
porknubbins 5y ago
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 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - musicale 5y ago
    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 5y ago
      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?
      - hansvm 5y ago
        Even something as basic as code search is nightmarishly slow. I frequently resort to CLI tools when VSCode doesn't respond quickly enough. Thankfully it usually handles cancellation requests well so that I don't have to continue waiting for whatever god-forsaken process is running after I've already found my answer via other means, but I'm not going to pretend it isn't slow.
elcomet 5y ago
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 ?
- wtetzner 5y ago
  Why should my note taking app or food ordering app be consuming resources that more important apps could be using?
rektide 5y ago
> 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 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.
ctvo 5y ago
> This means that software development is a failing discipline. Nah. It means many projects don't have strict performance requirements. Mediocre performance, high impact on battery life, slower startup times are OK for these folks. In return they gain cross platform support, quicker development cycles, etc.. There's nothing wrong with making these tradeoffs.
- wtetzner 5y ago
  > There's nothing wrong with making these tradeoffs. I would argue there's something wrong with giving customers a shitty experience.
Fire-Dragon-DoL 5y ago
One thing I learnt when programming long time ago was that having an abstraction for things fundamentally different wasn't a good idea. I was looking for an abstraction that would make tcp and udp look the same, but I wanted the benefit of udp on udp and tcp on tcp. If you think about ui in OSes, they are different, quite a bit. Still similar in some way, but different. Given that, one solution when you have similar things that are actually different (e. g. PS3 and PS5 are both consoles that run videogames, from the same company, but are incompatible),is to ship a vm. Make things run there and use it. Chromium is that VM.

chakkepolja 5y ago

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.

bsder 5y ago
> It's not about the quality of chromium at all, only ubiquity. Bingo. I don't understand why people keep failing to learn this lesson. Java became popular because Sun drove it to become default installed on lots of enterprise computers. Python later became popular because if you had a standalone computer you had "batteries included" so you had the same stuff always installed. And what people keep forgetting is that Electron is the low friction way of supporting Linux and macOS--whom most programmers would mostly like to ignore. If you write your app in Electron, you write on Windows, claim you support Linux and macOS and then ignore them.
- badpun 5y ago
  Java became popular on server side because alternatives were much worse (either lacking static typing like Perl or harder to develop like C++) AND Java was cross-platform. Back in those times, servers weren’t just x86+Linux boxes they are today, but had distinct os-es and CPU architectures.
wiggledrome 5y ago
Webshit? really dude. I started off as a desktop publisher, moved up to graphic designer in the creative hub of my country, doing 3d design and video editing, from there I moved to animation and then to user interface design. throwing around 'webshit' is elitist at best and derogatory at worst. As if lack mental ability to do your job? Can you do mine? You dont see any of us throwing around 'backend-bellend' when talking about fellow programmers. respect the field, we are all in it.
- chakkepolja 5y ago
  Doesnt change the fact that 70% of web developers are shit at their job.
  - wiggledrome 5y ago
    Instead of acknowledging that there are talented programmers in JS you doubled down and cite a number made up from your mind that says 7 out of 10 JS devs are shit. I dont think all backened devs are arrogant, but I know one is.
  - AnIdiotOnTheNet 5y ago
    70% of every field is shit at their jobs. We don't call it 'webshit' because the people are shit, we call it that because the product is shit. A pile of garbage abstractions built on other garbage abstractions all ultimately trying to make a document viewer into an application platform.
- deleted 5y ago
  [deleted]

tentacleuno 5y ago

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

dkersten 5y ago
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 5y ago
  > 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.
dbbk 5y ago
I'm not even sure that laptops are still sold with 4GB of RAM? You have a very niche usecase.
- Beltalowda 5y ago
  It lists 37 here [1]. Pretty sure people are still buying them. https://www.mediamarkt.nl/nl/category/_windows-laptops-641067.html?searchParams=%2FSearch.ff%3FfilterTabbedCategory%3Donlineshop%26filterCategoriesROOT%3DComputer%25C2%25A7MediaNLnlc482710%26filterCategoriesROOT%252FComputer%25C2%25A7MediaNLnlc482710%3DLaptops%25C2%25A7MediaNLnlc482723%26filterCategoriesROOT%252FComputer%25C2%25A7MediaNLnlc482710%252FLaptops%25C2%25A7MediaNLnlc482723%3DWindows-laptops%25C2%25A7MediaNLnlc641067%26filteravailability%3D1%26filterWerkgeheugen%3D4%2BGB%26channel%3Dmmnlnl%26followSearch%3D9412%26disableTabbedCategory%3Dtrue%26navigation%3Dtrue&sort=&view=&page= https://www.mediamarkt.nl/nl/category/_windows-laptops-64106...
  - skydhash 5y ago
    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 5y ago
  I wish I wasn't poor. Hoping to get a laptop with a bit more later on.
- tored 5y ago
  How is 4GB RAM installed a niche use case? If this is the route software development is intended to take where every app is going to consume +4GB RAM good luck running multiple apps at the same time or running it on a smaller form factor. It is truly bizarre that we are moving away from the desktop PC to smaller form factor but at the same time pushing technology that requires a desktop PC.
bavell 5y ago
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 5y ago
  I'll take anything under 300/500MB as a win, though I admit under the circumstances that's going to be very tight.

foxhill 5y ago

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

qorrect 5y ago
> 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.
- nurettin 5y ago
  vector is like an angle and a magnitude, perhaps you mean attack surface, which is the integral of known attack vectors.
- otterley 5y ago
  Vector is being used here in the epidemiological sense, not the mathematical sense.
klabb3 5y ago
> 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.
- foxhill 5y ago
  > 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". i can’t help but feel your catastrophising a bit here. in any case, you have options that would greatly ease pains of this sort, wx, QT, SDL, etc. there are many. the point is that the problem with electron isn’t UI abstraction in general, just this particular implementation of it. > [it’s safer to assume] most users have enough ram to run a chrome+node instance. so in an effort to avoid saying that you “couldn’t afford some feature”, you’re presuming that users can afford the resources for another multi-gigabyte ram hog, which is most likely, for all intents and purposes, a pretty wrapper around JSON getters and setters? > 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. strong disagree here. i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI. sorry if that’s come across as inflammatory, it’s not intentional. i guess i get a bit irrationally upset when i see i can trigger a full page refresh of what should be a native application when i hit CTRL+shift+R.
  - porcoda 5y ago
    > i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI. Bingo. We have a glut of developers who only really know web tech, and when they decide they want to do something for the desktop they just go with what they know instead of learning something different. The argument about portability that people make in support of Electron-based stuff doesn't hold up when you see that there exist cross-platform tools for other languages. At the end of the day, the tech world is crawling with JS developers who appear to be unmotivated to learn something other than JS (or one of its transpiled cousins).
    - klabb3 5y ago
      > they decide they want to do something for the desktop they just go with what they know instead of learning something different Shouldn't the burden of proof be reversed? If the stack works, why relearn in a different stack? The HN crowd loves to shit on web developers for not being good enough even at their own domain, yet at the same time encourage them to learn new tech. Proficiency takes time. As for the environment itself, web has the best inspect/debugging experience by far, an extremely capable and flexible layout engine and accessibility built in. It's also not controlled by a company, and has ubiquitous platform support. Obviously there's a network effect, which to a large extent led to this situation. But it also makes sense to learn today. If I was advising a junior it'd be criminally myopic to suggest learning Qt instead of web.
zarzavat 5y ago
> 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.
- foxhill 5y ago
  > This means you’ll be limited to the intersection of features of each platform native rendering engine. > On the other hand [...] we already live in this world. electron utilises the same APIs you would use. it doesn’t have a back way around these, and is subject to the same bugs and issues from the windowing system would be. it might be tempting to suggest here that electron devs can mitigate issues themselves and remove the need for that work on your part, but now you need to update your app: shared libraries aren’t exactly in fashion right now, so every electron based app needs updated. that in itself has a bunch of issues/consequences. if nothing else, it’s incredibly wasteful.
easrng 5y ago
> 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 5y ago
  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.

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.
    - jasode 5y ago
      >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.

Smeevy 5y ago

Maybe I'm just pining for the old days, but Visual Studio 6 is still my favorite IDE of all time. Intellisense was fairly new and it only activated if you pressed Ctrl-Space. I didn't have little pop-ups and type-aheads trying to steal my attention and all I did was think about the C++ code I was writing. This was around 1997, mind you. The build from the IDE still took almost 2 hours to complete. As it stands now, I still use IDEs. I try to disable every "convenient distraction" feature they have, but I've had had to settle for the fact that I can't make them work the way I want.

codalan 5y ago
It's not just VS, either. Every app has to have some attention-stealing, display obstruction mouseover. And it just seems to get worse and worse every year. So much noise for almost zero value. IIRC, in one of more recent versions of VS, hovering over a method param will show the type of the param. The same info that's already declared to the left of the param. How is this helpful at all? Even worse: There doesn't seem to be a way to even fine tune this. I don't need prompts in my face 100ms after I hover over something. They might be useful after 2000ms. But it seems to be all or nothing. I've been using Mads Kristensen's Disable Tooltips extension to preserve my sanity. If you want to see ugly, open the Azure portal sometime. Hovering too long (e.g. 200ms) over an element may open up a bigger dialog, and if you hover even longer, you get an even bigger dialog that blocks out other things that I might want to look at. It also has a nasty habit of clickjacking my intended target because of this. I think a lot of this garbage comes from this idea that you need to keep the user engaged for whatever metrics. The problem is that although this is fine for adverts and social media sites, this is exactly what you don't want for productivity. Unfortunately, it seems like these people change jobs/teams and end up bringing this mentality with them.
- Smeevy 5y ago
  Thanks for the tip about the Disable Tooltips extension. I'm using Visual Studio for a couple of projects and you've just removed one minor annoyance from my life and I appreciate it very much. We use MyEclipse for a lot of our Java development and I found something in their latest release that gave me chills: selecting multiple lines of text in an editor will bring up a control to start a "CodeTogether" session. That can be disabled, but I really have to wonder about why selecting some code in my editor means that I need to "phone a friend." The Azure Portal is absolutely spiteful. I've been using that as an object example of poor UI design for my junior developers. All of that work they've put in to make it responsive and I still have to hit F5 to see if my VM really started...
  - codalan 5y ago
    The Azure Portal is the next level of hell for users who need a responsive, out-of-the-way interface to do their work. There is a trend to make UIs more and more noisy every release, to the point where you have to be engaged on everything. Example #1: When I quit a Teams meeting, I randomly get asked to rate the meeting (unwanted behavior), instead of going back to the last application I have open (desired behavior) Example #2: When I edit an Azure DevOps wiki page and paste a link into the text editor, I expect no other behavior than the typical paste behavior. Instead, I get a vestigial popup which steals focus and prevents me from typing or moving the cursor with the up/down keys until I hit Escape. Imagine if you have to link to multiple pages to this wiki. It completely kills my productivity by over 50%. Example #3: When I use the mobile version of the Vivaldi browser, closing a tab should just bring me back to the last tab. It does that, but then has a pop-down dialog telling me I closed the tab, blocking the bottom of the browser. Dumb. Example #4: Screenshots in Android. Instead of just flashing the screen once to indicate the screenshot was taken, it now adds more context-related garbage to the bottom left corner of the screen, sometimes blocking controls. Really dumb. Example #5: Opening a Teams meeting. I click on the Outlook reminder to open the calendar invite, then click on Join Teams Meeting that brings Teams to the foreground, then opens the meeting window. It takes multiple clicks and open windows to just join a simple meeting, as well as multiple clicks to close all the open windows I don't need. I guess the idea of one click, one windows is too hard to figure out. I wouldn't be so angry about this if there was a way to just disable some of these anti-features. And it's never just one thing. It when you use multiple applications during the day and you can never get into any kind of flow. It's just interruption after interruption, with zero regard to cohesiveness. It's unfortunate that some UI/UX designers really do believe that the stuff that the FAANGs are doing is good design, because they end up perpetuating it through other software with little regard to the user or context. The MongoDBCompass client comes to mind. It's a gigantic beast of an Electron application that takes almost 30 seconds to load up on first start. Simple things like CTRL-A will not select all the text in a textbox, but the entire rendered webpage instead. Or double-clicking some value in a document will shift the interface around and put it into editing mode, when all you want to do is just copy a value.
    - jd_mongodb 5y ago