20 ms·

Electron 2.0.0 beta

259 points by l2dy 9y ago

swiley 9y ago
Just a reminder to everyone who says there's no way to write cross platform apps: TCL/TK is still a thing and MacOSX still ships with wish, it even runs on android. The one platform you can't use it for is the iPhone.
- lmm 9y ago
  If you're willing to not support the iphone you have plenty of good options. Unfortunately for many people iphone is a requirement.
anticnstrctv 9y ago
Does anyone else feel that there's a huge hole in the UI world? I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place. I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. Maybe Python? It's got lots of competent developers in the market to support it. Maybe Rust or Go, if something lower-level was desired. Or language-agnostic, though sticking with one might be valuable.
- eropple 9y ago
  It sounds like you're just describing React Native (which, for example, has a UWP target, although it's still janky). React Native doesn't have a "web stack".
- _pdp_ 9y ago
  You will most likely come up with a sub-par rendering engine that is better implemented by Mozilla and Google. My hope is in Servo.
- pjmlp 9y ago
  No, XAML, QML, JavaFX, Android, Cocoa are much better, with guaranteed hardware acceleration, and offer RAD GUI designers that are much more powerful than hand-editing HTML/CSS. As funny anecdote, CSS Grid was originally proposed by XAML team. Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.
  - greenhouse_gas 9y ago
    The big problem is that out of the 5 technologies you mentioned,only two are cross-platform, and only one builds an exe (yet). Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.
    - realharo 9y ago
      >last time I tried C++ with mingw on Windows I had a horrible time installing libraries msys2 (http://www.msys2.org/ http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.
    - pjmlp 9y ago
      XAML, QML, JavaFX, Android (since version 5), Cocoa all build exes, so I don't know which single one you mean. QML and JavaFX are cross-platform, XAML is cross platform via Avalonia or Xamarin.Forms. Anyone using C++ on Windows for GUI development should use Visual C++, C++ Builder or the gcc toolchain integrated in the Qt installer.
      - oblio 9y ago
        JavaFX doesn't run on iOS. While your Electron app will be tweaked to make a Cordova app that runs on iOS. Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.
- realharo 9y ago
  I feel the same way. I even tried starting a library like that (in Kotlin JVM and Native), but never got past a very early stage (https://github.com/peterholak/mogul https://github.com/peterholak/mogul). Hopefully one day I'll have enough time to work on it.
- ZenoArrow 9y ago
  > "I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack." There are a number of existing UI frameworks that fit this description. As a starting point, I'd suggest checking out QML: https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML
- kodablah 9y ago
  Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), not native enough in my OS (GTK), carries a full browser (Electron, nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit and community always has people asking what's the best UI lib for language X. We all travel back to awesome-lang-X lists' GUI section every so often hoping someone will finally fix it. Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming. And no, I would rather not have an interpreted (or dynamic) language if I can help it. Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.
  - zerr 9y ago
    Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.
    - oblio 9y ago
      In many times bindings are: * incomplete * immature * not up to date and definitely out-of-tree, aka not maintained by the folks that make the original toolkit. Would you bet your company on those bindings?
      - akerro 9y ago
        Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.
- danieldk 9y ago
  But is HTML/CSS/JS really the best we can do for desktop and mobile applications? [...] I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. QML? Or if you want native applications, what is wrong with Cocoa, Qt, and XAML? A cross-platform toolkit will either be the lowest-common denominator between the platforms (this has been tried before, see e.g. AWT, SWT, wxWidgets) or something that is alien to each platform (Electron). Small independent development companies have done applications across multiple platforms by using their native toolkits for decades. And now suddenly, it is too expensive for GitHub, Slack, and others to develop applications with platform UI toolkits? They are just transferring the cost to the users. We get inconsistent shortcuts, widgets, etc. between programs. No automator support, etc. There is only a benefit to people who use multiple platforms and want to applications to look the same on every platform. But the vast majority of users just uses one platform, or two if we include tablets/phones (which have different input methods anyway).
  - greenhouse_gas 9y ago
    >Small independent development companies have done applications across multiple platforms by using their native toolkits for decades Really? How many programs supported Linux before electron?
    - danieldk 9y ago
      Usually these companies supported macOS and Windows. I am sure they would have also supported Linux if it had a desktop penetration of more than 1% and if the Linux community was less hostile to closed-source applications. Don’t take this the wrong way (I was a full time Linux/BSD desktop user from 1994 to 2007 and still have one Linux desktop machine at home), but do we really want to significantly degrade the experience of 99% of the users for 1% of the market?
- mhd 9y ago
  I'm not the biggest fan of this sed reinvention of PostScript we call the browser stack, but my main problem with Electron and the like isn't this, but their design target: Making desktop apps look and feel like web apps. We're throwing away all kinds of HIG achievements since 1984, for the sake of pretty colors and superfluous transitions. Not too long ago, a considerable effort was spent to make web apps behave like desktop apps, now the inverse is true. I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.
  - anticnstrctv 9y ago
    Making desktop apps look and feel like web apps. This is a good point. However, it does seem like web and mobile apps and their ilk are the future for the bulk of software the majority of people use (excluding, let's say, "Pro" apps like photoshop, excel, dev tools). I'm not a huge fan of this, but the times have changed. I'm not sure that traditional desktop apps are really what I'd use the hypothetical framework I described to build. Something like my business expense tracking app, though? If I wanted it to sync and be functionally identical to the app on my phone? I could see this framework being used for that.
  - y4mi 9y ago
    > I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure. you can't just drop a sentence like that and not elaborate on it - unless you want to offend somebody. Each resource hungry "DevOps" tool has its place and has its worth. They're just often misused. A small IT firm with <10 Hypervisors won't need openstack for example. Thats only worth its maintenance if you're working with tens or hundreds or hardware machines. And a webapp which consists of <10 services probably doesn't need service discovery and advanced de-/commissioning of containers/vms. Administering hundreds of microservices without that is borderline impossible however.
    - mhd 9y ago
      DevOps as a practice isn't wrong, of course. Sysadmins scripted and programmed since the dawn of the silicon Pleistocene. But if every small company hires someone with that specific job description, well, you have to spend your 80+ startup hours somewhere.
- kenhwang 9y ago
  Or maybe the other way around: what if a browser was modular down to the feature level? Don't use CSS/JS/HTML feature X/Y/Z? It's removed from the engine at compile time. That way you're only shipping what you're using, not a mini-OS. Or maybe the JVM approach, where there's one electron process on the system, and all the electron apps on the system are run in the same process. That way at least the rendering/JS engine can be shared. It'd be like Firefox before electrolysis. Though, having your chat client crash and also take down your music player and code editor seems like a terrible user experience.
  - accatyyc 9y ago
    One big problem with Electron apps today IMO is that different apps cannot share memory, even though 90% of them is the same (Chrome/V8 etc). That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO) It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.
    - realharo 9y ago
      I'm not sure you would save that much memory. It would be a similar situation to having Chrome open with a bunch of tabs (those are separate processes as well) - it's the tabs themselves that consume most of the memory, compared to "bare" Chrome.
      - accatyyc 9y ago
        On my computer, "bare" Chrome with 0 tabs open still uses ~100MB of memory. If Electron would just use 100MB for the base compared to 100 * number of open Electron apps, that's still a pretty big win in my book.
- dvfjsdhgfv 9y ago
  I very much hope Red finally takes off. Currently the GUI frontend works only on Windows and macOS, not on Linux yet. But once it does, we'll finally have a truly multiplatform tool for creating simple apps (such as the ones Electron is used for). As for more complex apps, this might well be possible as well, but I haven't seen anything really complex created in Red yet.
- daxfohl 9y ago
  I wouldn't get my hopes up. Javascript is the only runtime allowed on ios. Desktop is no longer worth innovating for. Meanwhile web ui frameworks are going gangbusters with innovation. That leaves a fairly slim line for any real ui innovation outside of the HTML css js triumvirate.
- benjaminl 9y ago
  It is amazing that React and friends work as well as they do, and for certain applications they make a lot of sense. But there is a fundamental disconnect using web technologies for native apps. The solution I am pursuing right now is Microsoft's Xamarin. The C#\XAML stack supports iOS, Android, MacOS and Android. The only thing it is missing is web. But with a couple serious projects working on compiling C# to WebAssembly perhaps that will happen.
  - tonyedgecombe 9y ago
    I thought it was just a poor winforms clone on macOS.
    - oblio 9y ago
      Correct me if I'm wrong, but I think Xamarin just wraps Cocoa.
    - benjaminl 9y ago
      Like the rest of Xamarin's platforms, you can use modern XAML with MVVM patterns or you can use XCode's Interface Builder to create your views. Xamarin.Forms has no relationship to WinForms.
  - pjmlp 9y ago
    Microsoft is serious on the WebAssembly part. https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/ https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...
- mateuszf 9y ago
  It's not that simple. You can go three routes: 1. Make the apps look pixel perfectly the same on all platforms - that's what the Java Swing did. Result - all the apps feel "alien" and not native for the users. 2. Make all the apps look and behave native and use UX patterns consistent to the given platform. Result - you will have to program them differently. 3. Somewhere in between - all you get is mediocre GUI with not very pleasant development model. So the problem is not with the GUI toolkits but with inconsistent UX paradigms between the platforms / different input models, interaction models, etc.
  - Numberwang 9y ago
    I have no problem with things feeling alien, so that would be my preference. For example I love the Telegram desktop app.
    - adolfojp 9y ago
      Telegram looks native on Windows 10 though. It was designed to look like a flat modern app and it excels at that, hamburger menu and all.
      - Numberwang 9y ago
        Hmm, the header bar doesnt look native to me (it looks amazing)
  - pas 9y ago
    Alien would be okay, were it not ugly. Swing is unusable and ugly. Just look at and try to use a Swing file picker. ... Anyway, I'd gladly program them differently for closer to native experience, if it were easy to program. Currently it's either Qt (C++) or GTK (C), or completely useless/out-of-date bindings. And thus any glorified WebView reigns supreme.
    - mateuszf 9y ago
      Yeah, I agree - C/C++ are the reasons why Qt is not popular.
- ergothus 9y ago
  Are the options the best they could be? Heck no, not even close. Html is semantic enough to be tedious but not enough yo be useful. Css makes the easy things hard and people have entire philosophies around minimizing the "cascading" part. Js is at best stuck with warts to try and maintain backwards compatibility. Meanwhile the tooling to deal with missing pieces or complications that are not missing is complex enough that both new and experienced devs complain. The less said about the security complexity the better. And I'm saying all of that as someone that uses these daily and enjoys it. BUT...is it the best that is practical for the time? Probably. There have been efforts to replace these options...theyve failed. Perhaps wasm will change things, but perhaps not. Until then though, I think it is interesting to ask "Why?" Why, if these other options are superior, do they not catch on? Linux, git, nginx, these are just a few examples of dramatic tech switches that had to overcome an existing base. It isnt just backwards compatibility either - Babel exists for es6+, but I've not seen a non js-like language that can compile to js achieve much success. I suspect there are one or two areas that the current offerings handle well that aren't being credited or understood. Computer UI is a young field, computer interactions with business and marketing over time are all poorly understood. We spend much of our time reinventing our spinning wheels and relearning lessons. Html in js is bad. No, it is good. Inline css is bad. No, it is good. This isn't all wasted time, there is a lot of learning time. So I doubt we even understand yet what would make a better toolset.
- ec109685 9y ago
  > I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place. React Native doesn't use HTML/CSS at all for rendering.
- hooluupog 9y ago
  Flutter has the potential once it ported to desktop and even web(with WASM).
  - gman83 9y ago
    I think it'll only be ported to desktop once Fuchsia comes closer to release (which could be several years). They really seem focused on mobile only at the moment. Agree it could be a great solution.
  - markdog12 9y ago
    Looks like it has started (MacOS for now) https://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding
- zwetan 9y ago
  You just described Adobe AIR eg. "something that has consistent, cross platform (desktop and mobile [...]), responsive ui, without the huge web stack"
- raquo 9y ago
  I really don't mind the HTML / CSS part with new developments such as CSS grid. If you're running it in a controlled environment (embedded browser), you could cut out a bunch of legacy crap, leaving a much leaner engine. Similar cleanup could be done on the DOM API, I guess.
  - cm2187 9y ago
    There is something to be said about html being too basic for developping apps efficiently. There is no menu control, contextual menu control, if you want to handle dragging and dropping UI items or creating an overlay modal window you need to do all sorts of hacks. On a desktop UI framework these are often a single line of code and it’s hard to get it wrong. I don’t think html/css is really comparable to the major native UI frameworks in term of productivity and correctness of apps produced. I see so many websites trying to implement their own UI behaviors and getting it wrong, not scrolling smoothly, showing a modal window partially off screen in certain scenarios, preventing you from zooming out on a smartphone while overflowing the text outside of the screen, menus that are either not touch or mouse friendly, etc. Giving UI developpers only html and css is like telling a graphic designer: all you need is microsoft paint, you see you can change the color of each pixel to whatever you want, total freedom! Yeah... No.
    - raquo 9y ago
      Being relatively low level is a feature. HTML / CSS / JS are languages, not frameworks. One liner modals are not a feature a language should have. If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice. Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.
      - cm2187 9y ago
        Why do you call html and css a language? To me it’s a UI framework very much like winform, wpf & al.
- gunn 9y ago
  Yes. I'd like to see a stripped down embeddable browser engine - https://news.ycombinator.com/item?id=9914925 https://news.ycombinator.com/item?id=9914925 Also there are existing projects like https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos
  - jbergens 9y ago
    Like Sciter? https://sciter.com/ https://sciter.com/ I think WPF/XAML could have worked also but there were not much work to port it to anything but Windows.
    - gunn 9y ago
      That's almost exactly what I was thinking of. There does look to be a big caveat with it though - instead of JS, it has an ECMAScript variant called TIScript. I'm sure this was a good choice when it was made, but javascript libraries and tooling are a lot to miss out on now.
  - deleted 9y ago
    [deleted]
- Sawamara 9y ago
  I am sorry, but I honestly do not think that PYTHON of all the things would be the solution to a "UI-problem". To have a good UI system, you need extensibility, you need testing, you need strong types (this one is debatable, but I truly believe this to be true after working with Typescript-based HTML UI-s for the past 6+ months now), and you need performance. I can understand that a lot of programmers got into the mindset of "no, I wont deal with HTML", and I frequently see devs mentioning that they prefer that apps look "native", which is something that has not been a standard in the mainstream dev world for quite a few years now, but the reality is that that "native" dream is gone. People all around the world interact with mobile apps MORE than their dessktop/mobile system'S native ui, so there is no baseline to go back to, there is no good old days to retrieve. We can only move forward with what we have learned, imho. And that might be or might not be HTML, but if something comes along, it better learn all the lessons that we collectively are learning with working through HTML-CSS-JS SPA's.
- zserge 9y ago
  I agree with you, and I tried my best to change things. A few years ago I made Anvil - a React-ish framework for Android for native UI (reactive, declarative, works best with Redux) and have been using it in many production apps as long as I was doing Android development. But it still is a niche product, most developers prefer visual UI editor and whatever is the official Google way to do Android apps. Still, I'm very proud of Anvil. https://github.com/zserge/anvil https://github.com/zserge/anvil Then, once I had to deal with desktop apps I figured out that HTML/CSS/JS seems to be the best option for custom (no native widgets) and modern (animations, shadows, nice fonts etc) UI. But Electron was a heavy beast, so I made a tiny wrapper over native browser engines (webviews). So far I'm very happy with it, it's much lighter and smaller than electron. And it's very convenient to use from C++ or Go. Some kind people added Rust and Nim support, I'm now working on Python and Node.js bindings. So yeah, it's pretty much language-agnostic, although it's still web UI. I really hope it can take it's niche for small desktop apps that don't need the full power of Electron, yet need to have a good look. https://github.com/zserge/webview https://github.com/zserge/webview
  - moosingin3space 9y ago
    Been enjoying your library webview for some small home projects. Thanks!
- swiley 9y ago
  TCL/TK runs on literally everything except the iPhone.
- rebolek 9y ago
  Sounds like what Red language http://www.red-lang.org/ http://www.red-lang.org/ is trying to achieve. It is still in Alpha, but already has cross platform GUI for Windows and OS X (with Androind arriving in next release). And without the web stack bloat, it's just single ~1 MB executable.
- pier25 9y ago
  I've been working in UI for almost 20 years. I've done flash, native desktop, games, web, mobile, etc, and I think HTML+CSS+JS is still the best abstraction for UI IMO. It's certainly not without it's problems though. JS sucks and native performance is way better, but no one can deny it's so much more flexible and powerful than any other thing out there. Here is a great article on this topic: https://medium.com/missive-app/our-dirty-little-secret-cross-platform-email-client-with-nothing-but-html-aa12fc33bb02 https://medium.com/missive-app/our-dirty-little-secret-cross...
- mamcx 9y ago
  I'm starting a project with a strong need of build the UI in multiple targets (iOS, Android mainly). I try first with html and the native webview. With iOS is totally fine, but Android is SUPER slow. I never imagine that android was this bad, but at least, it force me to do native :) ---- I think that is possible to do what you describe, and I'm working something like. The key is decouple some task (kinda separate "back-end" UI from "front-end" UI): We can do "partial" cross-platform UI, if we think that some stuff can actually cross cleanly: - Layout (the big one, IMHO) with something like https://yogalayout.com https://yogalayout.com - The ELM architecture (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction.html https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) because a big chunk of the logic is totally cross-platform and "only" need to adapt the render of controls. - Dispatching, events and similar stuff, that is not visual. Then finally, the rest can be fully native: - Controls - Drawing - Animations - Call to native libs ---- The big question is what to use for coding this. I'm using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with http://elementscompiler.com http://elementscompiler.com Wish to have a coding partner to do this :)
- glibgil 9y ago
  https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be&t=38s https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be...
- rms25 9y ago
  Look up QML (Qt Quick) on Qt, its the easiest UI building experience I've ever had Funny that QML looks alot like the JavaFX script that was abandoned
refulgentis 9y ago
What happened here? "macOS Changed a macOS thing. #123 Windows Changed a Windows thing. #123"
- Libturd 9y ago
  how about fucking clicking it and looking?
- palotasb 9y ago
  I guess that's the template text for releases and they forgot to remove it.
- dspillett 9y ago
  The #123 is a link. Click that for the ticket with more information. Though looking at it, the actual description is no longer than "changed an X thing".
  - davej 9y ago
    That issue was 4 years ago. #123 looks like placeholder text.
- deleted 9y ago
  [deleted]
- guessmyname 9y ago
  They linked to a GitHub issue explaining a feature request [1]: > We should use the icon of exe as window's icon, and we also need to add a default icon for atom-shell on Windows. [1] https://github.com/electron/electron/issues/123 https://github.com/electron/electron/issues/123
dvfjsdhgfv 9y ago
It's really sad that in spite of the main glaring problem of Electron apps they didn't as much as even mention any work done on performance optimization in 2.0.0. The changes mentioned are just make up when compared to the real problem.
- make3 9y ago
  this looks likes an internal dev oriented page, not a public announcement type of deal.
- ghostcluster 9y ago
  scanned the changelog for any mention of performance or memory footprint optimizations. nothing.
  - erulabs 9y ago
    Updated V8, Node, and Chrome? That's the performance gain...
- realharo 9y ago
  Is there anything they could even do in that area? (other than improving Chromium itself)
- bengotow 9y ago
  Electron’s performance is fairly tied to Chromium’s - the Electron changelog references a Chromium version bump and you’ll need to look there for perf improvements (which isn’t ideal - I wish they’d pulled in some highlights!) To be honest, people using Electron are doing it because of huge business / process wins and worse performance is a generally acceptable downside. Performance is improving as Chromium improves, but it isn’t a huge focus in the Electron community.
- nukeop 9y ago
  What do you find lacking in Electron's performance? Compared to all competing UI frameworks it isn't really any different, except it allows for faster and easier development and deployment.
paxys 9y ago
Nothing in this seems worthy of a major version bump to be honest.
- callumlocke 9y ago
  A major version bump is for introducing breaking API changes. That’s all it means.
- l2dy 9y ago
  See https://electronjs.org/blog/electron-2-semantic-boogaloo https://electronjs.org/blog/electron-2-semantic-boogaloo. As of version 2.0.0, Electron will strictly adhere to Semantic Versioning. Major Version Increments * Chromium version updates * Node.js major version updates * Electron breaking API changes
  - jbergens 9y ago
    Sounds a bit like angular and we might get electron 3 and 4 very soon if they feel a need to update Chromium or Node.
- AgentME 9y ago
  If they're following semantic versioning, then they bump the major version number whenever they make breaking changes.
0XAFFE 9y ago
I wonder why there is no runtime package for all your electron applications, so you only have to install the runtime once and every app can depend on this runtime. This would greatly reduce download sizes of individual applications.
- Drakim 9y ago
  I assume because it would defeat the intention of electron, since the entire point is to "magically" make your webapp into a standalone application with no dependencies. Just download and start it up, like any application. Whether this is wise is another question.
  - greglindahl 9y ago
    ... and with this sort of magic, I expect that all of the applications that I download are going to have completely different versions of all of the dependencies, so, ... there's no sharing anyway.
- callumlocke 9y ago
  Because the market-proven reality is most end users don’t care about 100MB download sizes, and they do care about simplicity.
  - nukeop 9y ago
    100 MB is nothing. My electron program is only 35 MB in size. Most people have multiple 1TB disks now.
    - imtringued 9y ago
      Or people have laptops and because they don't waste it on bloated crap like Windows and instead use linux a single 256NVMe SSD is enough. I use 50GB right now for the Linux installation with everything I could possibly need for work and another 50GB for two empty Windows VMs with nothing in them except a browser.
    - 9y ago
_o_ 9y ago
With all the GUI crap going on in software development, I am starting to miss MFC and BCG libraries, I know it is not feasable for most developers to code in c++ but at that time the GUI, even if run over RDP, was fast, responsive, now I having a feeling like 386 was faster than todays i7+. And to cirmuvent obvious incapability of RAD to provide decent user expirience, they are changing our UI percepction from trendy perspective, leveling everything to flat and extremly simple, like ncurses on graphical desktop. =/
greenhouse_gas 9y ago
What would be interacting is an electron like environment with a pared down JS/CSS engine which only let "modern JS/CSS" (maybe something like Servo). It can be optimized for that, and you don't really have to render electron apps from the 90s anyways. Another idea is that when wasm will be able to interface with DOM, you'd be able to write GUI code in any language which compiles to wasm. So you won't _need_ Rust (or Go, or Haskell, or D, or your up and coming toy language) bindings for win32, Qt, GTK, etc. Just waste a few hundred megs (only partially /s) and you've got a full ui.
- jbergens 9y ago
  MS seems to be on the way to support PWA directly in Win 10. If other systems would do this as well we won't have to ship a full runtime like Electron. https://blogs.windows.com/msedgedev/2018/02/06/welcoming-progressive-web-apps-edge-windows-10/ https://blogs.windows.com/msedgedev/2018/02/06/welcoming-pro...
dcgudeman 9y ago
Why not upgrade to the most recent version of chromium? (64 instead of 61)
- samwillis 9y ago
  Because it takes longer than the chromium release cycle to do an electron/chromium upgrade. I think they only tend to do the upgrade a few times a year. Chrome 61 will have been current when they started the upgrade process.
vbsteven 9y ago
I wonder if it would be possible to change the electron build process so it builds 2 outputs: 1 "big" package with full Chrome inside and 1 "light" package that just contains the application code. The light package could then be offered as an alternative download on the website to run on a specific "electron-runner" that can run multiple electron apps side by side. I know that I just described a regular browser with tabs or windows but hey, Electron is what we have right now and it is not going away soon. This might be a solution for people running multiple Electron apps side by side.
- hashhar 9y ago
  Reminds me of XULRunner from Mozilla.
- nukeop 9y ago
  If you don't need the APIs that interact with the local system, you can already build for Electron and for the browser easily. If you need those APIs, however, there's no other possibility because of the browser sandbox.
  - NoGravitas 9y ago
    It's possible to have a native (node?) app for the local side, which talks to a browser extension. This way you don't have to run multiple instances of the browser runtime. There's someone writing a full-featured, Patchwork-like SSB client in Firefox this way, but unfortunately I can't remember the name.
- kilian 9y ago
  A project with that idea is Electrino: https://github.com/pojala/electrino https://github.com/pojala/electrino It provides an electron-like API but uses the OS version of safari. It doesn't seem to be actively developed anymore though.
mherrmann 9y ago
People not satisfied with Electron's performance might be interested in fbs [1]. It makes it very easy to create desktop apps with Python and Qt. It was in the #1 spot here two weeks ago [2]. (I'm the author.) [1]: https://github.com/mherrmann/fbs https://github.com/mherrmann/fbs [2]: https://news.ycombinator.com/item?id=16318677 https://news.ycombinator.com/item?id=16318677
samwillis 9y ago
Does anyone know if there has been any work on bringing the work from “headless chrome” to electron? It would be awesome to be able to use the full node.js environment with a headless browser natively.(headless chrome with puppeteer is good but electron would be better)
eklavya 9y ago
You can use React and js to build native desktop apps without electron today. Use https://proton-native.js.org/ https://proton-native.js.org/ (based on libui).
- plopz 9y ago
  While that is certainly a promising library to watch for in the future, I wouldn't say its ready to go today. Its based on libui which is in alpha and was stagnant for quite awhile. The developer just recently (this week) started working on it again so there is potential.
thiht 9y ago
As much as HN hates Electron, it's probably one of the best things to happen on desktop, especially on linux desktop ironically. It works, it's beautiful, it's easy to use, and unlike many people here, I believe the HTML/CSS/TypeScript/React is rock solid and the closest thing to THE solution to the UI problem.
- factorialboy 9y ago
  I agree it works quite alright - not perfect, but nothing's perfect, right? Of course there are some poor implementations (Slack) and some really good one's (VSCode). Criticism of the platform for the deficiencies of an implementation feels a bit lazy.
- beojan 9y ago
  > one of the best things to happen on desktop, especially on linux desktop ironically Not by a long shot. It's one of the worst things to happen on the desktop, because people who would have built a proper desktop application just wrap their web app in Electron instead. It's particularly bad for the Linux desktop, where people are used to small binaries that use the system-wide Qt or GTK so they load fast, and use little RAM.
  - yoz-y 9y ago
    I think the idea is that most developers would not make a proper desktop app, and without electron there would just be not app at all. But I think that Electron is a short term good which will cause a lot of long term "bad".
    - beojan 9y ago
      > I think the idea is that most developers would not make a proper desktop app, and without electron there would just be not app at all. Precisely, people will just use something else. The proliferation of Electron apps splits the user base, so there's less incentive to develop a proper desktop application.
  - stelonix 9y ago
darklajid 9y ago
Waiting eagerly for VS Code to upgrade. As far as I understand, this fixes the "precision touchpad" bug on Windows..
mememaestro 9y ago
Can't wait to transfer my web apps to Electron and see how laggy it gets. Because fuck u assholes
kimjongman 9y ago
How many jiggabytes space it requires for an app?
nkkollaw 9y ago
One thing I don't understand about Electron is, why not share a single Chrome process (or if anything one per Chrome version if needed)
tradedash 9y ago
We have been using Electron for https://tradedash.io https://tradedash.io (our crypto currency trading platform) for some time now. There are some minor issues with the platform itself but there are a lot of good things too. The JS ecosystem as a whole needs to improve but as far as Electron goes, I must say that I am pleasantly surprised with how well it has been doing even though we are handling data from multiple exchanges at a rate that is not so trivial.
- disiplus 9y ago
  why is this a "native" app and not just a new tab in chrome ?
Aelius 9y ago
I agree with all the complaints about electron performance, but the thing that really gets me is how horribly developers fail at responsive design, with a toolset that is probably the most suited for responsive design since terminals. How the hell do slack, discord, and gitter STILL not collapse their sidebars when you resize the containing window to be tall and narrow? It makes them unusable in a tiling WM, and it's generally disrespectful of screen real estate in any WM. This is the price of easily accessible development. We're doomed to relive past mistakes in UI, as new developers are blissfully unaware of lessons learned by existing frameworks. Many people here are saying electron is popular because of a lack of sane, consistent toolkits across each OS. There's also security to think of too. Electron is likely very insecure relative to native software, but the responsibility is purely on the electron devs: freeing the app developer of that burdon. Electron rose in an environment with no competition in that regard. But now, Windows has UWP, and Mac has their own app platform. I sincerely hope we see these more universally leveraged, such that developers will stop abusing the web for app development. And I guess Linux will just have to make a WINE for UWP, I can't imagine the Linux community coming together to create something like that for themselves.
- kroltan 9y ago
  > And I guess Linux will just have to make a WINE for UWP I might be wrong, but isn't that literally Snap Packages? https://www.ubuntu.com/desktop/snappy https://www.ubuntu.com/desktop/snappy
FreezerburnV 9y ago
Since it’s something I’ve been paying attention to for a while: this (beta, sure, but soon to be full. Probably would work fine for doing some dev work) release of Electron finally bundles the version of Chrome that implemented SharedArrayBuffer support. This means that developers can now spawn web workers (real parallelism) and communicate with them much faster than previously with message passing. So there could be some big wins for things like developing games in Electron since you’ll be able to do some big number crunching off the UI “thread” and hand the results back to the UI with little performance penalty. (Especially if there are a lot of results, such as a theoretical fully-updated scene graph worth of matrices in an array) Hooray for less jank on the renderer!
- ihsw2 9y ago
  Notably, `SharedArrayBuffer` was disabled (starting Jan 5 2018) due to Spectre. Nevertheless, it is going to be re-enabled so it is worth reading up on shared memory in JavaScript -- more to the point, Atomics. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I know a lot of people scoff at the Node/browser runtimes, which is warranted and totally unrelated to the language known as JavaScript, but performance is improving.
  - FreezerburnV 9y ago
    Is it disabled in the version of Chrome shipping with Electron? Considering they’re usually some number of versions behind, and this is a tool to make a desktop app, it would seem to be desirable to have it enabled regardless of Spectre since a desktop app can own your computer anyway if it wants. (It does make sense to have it disabled in a general purpose browser until mitigation’s are in place)
- jpambrun 9y ago
  You can already experiment with SAB in electron 1.7.9 with flags.
  - FreezerburnV 9y ago
ed_blackburn 9y ago
How long before the Electron APIs are aped by OS extensions and managed more effectively than Blink?
ericfrederich 9y ago
Never really heard of Electron before I tried using KeyBase on Windows. It seems electron is the reason that it doesn't work on my machine. Ran into this last night. https://github.com/keybase/keybase-issues/issues/2813 https://github.com/keybase/keybase-issues/issues/2813
pier25 9y ago
Sadly the biggest problems with Electron are not yet solved: 1) There is no way to separate the Electron engine from your app, so you have to bundle Chrome and Node with each app. 2) Electron has an autoUpdater API, but since Electron doesn't solve the installation/updates problem e2e (packager + installer + updates server) it's really a half baked solution. This is specially bad in Windows since Squirrel for Windows is in my experience a disaster. I have a number of Electron apps in production, internally and for our customers, and for our next desktop project we won't be using Electron. The idea of using web technologies for the UI is still very valid IMO, but considering the 2 previous problems it's way less of a headache to just make our own native wrapper in C# and Swift (sorry Linux) and finally distribute the app via the official stores. At least for our use case.
- solarkraft 9y ago
  Or release it as a web application and let the user use chrome's "add do desktop" ... I don't like that you're dropping Linux compatibility, but understand the the reasoning.
  - pier25 9y ago
    We've done that on mobile, but most of users don't even know that feature exists and another big chunk still don't trust a website vs an app. I've never seen this feature in desktop. Closes thing I know are these "hosted web app" in Windows 10. https://docs.microsoft.com/en-us/windows/uwp/porting/hwa-create-windows#step-1-pick-a-website-url https://docs.microsoft.com/en-us/windows/uwp/porting/hwa-cre...
    - jamesgeck0 9y ago
      The feature is only available in the Windows and Linux versions of Chrome. https://www.lifewire.com/create-shortcuts-in-google-chrome-for-windows-4103617 https://www.lifewire.com/create-shortcuts-in-google-chrome-f...
- gilrain 9y ago
  I've been using the Sciter bindings for Rust, lately. It might be worth a look if you want a more performant option for a HTML/CSS GUI. The documentation is pretty rough, though. https://sciter.com/ https://sciter.com/ https://github.com/sciter-sdk/rust-sciter https://github.com/sciter-sdk/rust-sciter
billfruit 9y ago
I have only a very cursory look at Electron, but I find two things problematic: Lack of support for legacy systems, and the complicated build process of apps built with Electron, most can't successfully build unless you download a ton of stuff from npm. The kind of place where I am with many many older machines, never connected to the internet, Electron hardly makes any sense.
twtw 9y ago
Is Electron still single threaded like Node?
ohthehugemanate 9y ago
Can anyone explain for me: WHY is electron such a resource hog? Is it just because chrome is a resource hog? Could it be trivially re-engineered to wrap quantum instead?
wodenokoto 9y ago
What is the stack behind RStudio? It isn't electron, but it is an HTML app, run by a browser (safari on my macbook pro, wonder if it is IE on windows) It doesn't feel as heavy as electron apps.

259 points by l2dy 9y ago

Just a reminder to everyone who says there's no way to write cross platform apps: TCL/TK is still a thing and MacOSX still ships with wish, it even runs on android. The one platform you can't use it for is the iPhone.

lmm 9y ago
If you're willing to not support the iphone you have plenty of good options. Unfortunately for many people iphone is a requirement.

anticnstrctv 9y ago

Does anyone else feel that there's a huge hole in the UI world? I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place. I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. Maybe Python? It's got lots of competent developers in the market to support it. Maybe Rust or Go, if something lower-level was desired. Or language-agnostic, though sticking with one might be valuable.

eropple 9y ago
It sounds like you're just describing React Native (which, for example, has a UWP target, although it's still janky). React Native doesn't have a "web stack".
_pdp_ 9y ago
You will most likely come up with a sub-par rendering engine that is better implemented by Mozilla and Google. My hope is in Servo.
pjmlp 9y ago
No, XAML, QML, JavaFX, Android, Cocoa are much better, with guaranteed hardware acceleration, and offer RAD GUI designers that are much more powerful than hand-editing HTML/CSS. As funny anecdote, CSS Grid was originally proposed by XAML team. Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.
- greenhouse_gas 9y ago
  The big problem is that out of the 5 technologies you mentioned,only two are cross-platform, and only one builds an exe (yet). Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.
  - realharo 9y ago
    >last time I tried C++ with mingw on Windows I had a horrible time installing libraries msys2 (http://www.msys2.org/ http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.
  - pjmlp 9y ago
    XAML, QML, JavaFX, Android (since version 5), Cocoa all build exes, so I don't know which single one you mean. QML and JavaFX are cross-platform, XAML is cross platform via Avalonia or Xamarin.Forms. Anyone using C++ on Windows for GUI development should use Visual C++, C++ Builder or the gcc toolchain integrated in the Qt installer.
    - oblio 9y ago
      JavaFX doesn't run on iOS. While your Electron app will be tweaked to make a Cordova app that runs on iOS. Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.
realharo 9y ago
I feel the same way. I even tried starting a library like that (in Kotlin JVM and Native), but never got past a very early stage (https://github.com/peterholak/mogul https://github.com/peterholak/mogul). Hopefully one day I'll have enough time to work on it.
ZenoArrow 9y ago
> "I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack." There are a number of existing UI frameworks that fit this description. As a starting point, I'd suggest checking out QML: https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML
kodablah 9y ago
Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), not native enough in my OS (GTK), carries a full browser (Electron, nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit and community always has people asking what's the best UI lib for language X. We all travel back to awesome-lang-X lists' GUI section every so often hoping someone will finally fix it. Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming. And no, I would rather not have an interpreted (or dynamic) language if I can help it. Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.
- zerr 9y ago
  Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.
  - oblio 9y ago
    In many times bindings are: * incomplete * immature * not up to date and definitely out-of-tree, aka not maintained by the folks that make the original toolkit. Would you bet your company on those bindings?
    - akerro 9y ago
      Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.
danieldk 9y ago
But is HTML/CSS/JS really the best we can do for desktop and mobile applications? [...] I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. QML? Or if you want native applications, what is wrong with Cocoa, Qt, and XAML? A cross-platform toolkit will either be the lowest-common denominator between the platforms (this has been tried before, see e.g. AWT, SWT, wxWidgets) or something that is alien to each platform (Electron). Small independent development companies have done applications across multiple platforms by using their native toolkits for decades. And now suddenly, it is too expensive for GitHub, Slack, and others to develop applications with platform UI toolkits? They are just transferring the cost to the users. We get inconsistent shortcuts, widgets, etc. between programs. No automator support, etc. There is only a benefit to people who use multiple platforms and want to applications to look the same on every platform. But the vast majority of users just uses one platform, or two if we include tablets/phones (which have different input methods anyway).
- greenhouse_gas 9y ago
  >Small independent development companies have done applications across multiple platforms by using their native toolkits for decades Really? How many programs supported Linux before electron?
  - danieldk 9y ago
    Usually these companies supported macOS and Windows. I am sure they would have also supported Linux if it had a desktop penetration of more than 1% and if the Linux community was less hostile to closed-source applications. Don’t take this the wrong way (I was a full time Linux/BSD desktop user from 1994 to 2007 and still have one Linux desktop machine at home), but do we really want to significantly degrade the experience of 99% of the users for 1% of the market?
mhd 9y ago
I'm not the biggest fan of this sed reinvention of PostScript we call the browser stack, but my main problem with Electron and the like isn't this, but their design target: Making desktop apps look and feel like web apps. We're throwing away all kinds of HIG achievements since 1984, for the sake of pretty colors and superfluous transitions. Not too long ago, a considerable effort was spent to make web apps behave like desktop apps, now the inverse is true. I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.
- anticnstrctv 9y ago
  Making desktop apps look and feel like web apps. This is a good point. However, it does seem like web and mobile apps and their ilk are the future for the bulk of software the majority of people use (excluding, let's say, "Pro" apps like photoshop, excel, dev tools). I'm not a huge fan of this, but the times have changed. I'm not sure that traditional desktop apps are really what I'd use the hypothetical framework I described to build. Something like my business expense tracking app, though? If I wanted it to sync and be functionally identical to the app on my phone? I could see this framework being used for that.
- y4mi 9y ago
  > I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure. you can't just drop a sentence like that and not elaborate on it - unless you want to offend somebody. Each resource hungry "DevOps" tool has its place and has its worth. They're just often misused. A small IT firm with <10 Hypervisors won't need openstack for example. Thats only worth its maintenance if you're working with tens or hundreds or hardware machines. And a webapp which consists of <10 services probably doesn't need service discovery and advanced de-/commissioning of containers/vms. Administering hundreds of microservices without that is borderline impossible however.
  - mhd 9y ago
    DevOps as a practice isn't wrong, of course. Sysadmins scripted and programmed since the dawn of the silicon Pleistocene. But if every small company hires someone with that specific job description, well, you have to spend your 80+ startup hours somewhere.
kenhwang 9y ago
Or maybe the other way around: what if a browser was modular down to the feature level? Don't use CSS/JS/HTML feature X/Y/Z? It's removed from the engine at compile time. That way you're only shipping what you're using, not a mini-OS. Or maybe the JVM approach, where there's one electron process on the system, and all the electron apps on the system are run in the same process. That way at least the rendering/JS engine can be shared. It'd be like Firefox before electrolysis. Though, having your chat client crash and also take down your music player and code editor seems like a terrible user experience.
- accatyyc 9y ago
  One big problem with Electron apps today IMO is that different apps cannot share memory, even though 90% of them is the same (Chrome/V8 etc). That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO) It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.
  - realharo 9y ago
    I'm not sure you would save that much memory. It would be a similar situation to having Chrome open with a bunch of tabs (those are separate processes as well) - it's the tabs themselves that consume most of the memory, compared to "bare" Chrome.
    - accatyyc 9y ago
      On my computer, "bare" Chrome with 0 tabs open still uses ~100MB of memory. If Electron would just use 100MB for the base compared to 100 * number of open Electron apps, that's still a pretty big win in my book.
dvfjsdhgfv 9y ago
I very much hope Red finally takes off. Currently the GUI frontend works only on Windows and macOS, not on Linux yet. But once it does, we'll finally have a truly multiplatform tool for creating simple apps (such as the ones Electron is used for). As for more complex apps, this might well be possible as well, but I haven't seen anything really complex created in Red yet.
daxfohl 9y ago
I wouldn't get my hopes up. Javascript is the only runtime allowed on ios. Desktop is no longer worth innovating for. Meanwhile web ui frameworks are going gangbusters with innovation. That leaves a fairly slim line for any real ui innovation outside of the HTML css js triumvirate.
benjaminl 9y ago
It is amazing that React and friends work as well as they do, and for certain applications they make a lot of sense. But there is a fundamental disconnect using web technologies for native apps. The solution I am pursuing right now is Microsoft's Xamarin. The C#\XAML stack supports iOS, Android, MacOS and Android. The only thing it is missing is web. But with a couple serious projects working on compiling C# to WebAssembly perhaps that will happen.
- tonyedgecombe 9y ago
  I thought it was just a poor winforms clone on macOS.
  - oblio 9y ago
    Correct me if I'm wrong, but I think Xamarin just wraps Cocoa.
  - benjaminl 9y ago
    Like the rest of Xamarin's platforms, you can use modern XAML with MVVM patterns or you can use XCode's Interface Builder to create your views. Xamarin.Forms has no relationship to WinForms.
- pjmlp 9y ago
  Microsoft is serious on the WebAssembly part. https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/ https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...
mateuszf 9y ago
It's not that simple. You can go three routes: 1. Make the apps look pixel perfectly the same on all platforms - that's what the Java Swing did. Result - all the apps feel "alien" and not native for the users. 2. Make all the apps look and behave native and use UX patterns consistent to the given platform. Result - you will have to program them differently. 3. Somewhere in between - all you get is mediocre GUI with not very pleasant development model. So the problem is not with the GUI toolkits but with inconsistent UX paradigms between the platforms / different input models, interaction models, etc.
- Numberwang 9y ago
  I have no problem with things feeling alien, so that would be my preference. For example I love the Telegram desktop app.
  - adolfojp 9y ago
    Telegram looks native on Windows 10 though. It was designed to look like a flat modern app and it excels at that, hamburger menu and all.
    - Numberwang 9y ago
      Hmm, the header bar doesnt look native to me (it looks amazing)
- pas 9y ago
  Alien would be okay, were it not ugly. Swing is unusable and ugly. Just look at and try to use a Swing file picker. ... Anyway, I'd gladly program them differently for closer to native experience, if it were easy to program. Currently it's either Qt (C++) or GTK (C), or completely useless/out-of-date bindings. And thus any glorified WebView reigns supreme.
  - mateuszf 9y ago
    Yeah, I agree - C/C++ are the reasons why Qt is not popular.
ergothus 9y ago
Are the options the best they could be? Heck no, not even close. Html is semantic enough to be tedious but not enough yo be useful. Css makes the easy things hard and people have entire philosophies around minimizing the "cascading" part. Js is at best stuck with warts to try and maintain backwards compatibility. Meanwhile the tooling to deal with missing pieces or complications that are not missing is complex enough that both new and experienced devs complain. The less said about the security complexity the better. And I'm saying all of that as someone that uses these daily and enjoys it. BUT...is it the best that is practical for the time? Probably. There have been efforts to replace these options...theyve failed. Perhaps wasm will change things, but perhaps not. Until then though, I think it is interesting to ask "Why?" Why, if these other options are superior, do they not catch on? Linux, git, nginx, these are just a few examples of dramatic tech switches that had to overcome an existing base. It isnt just backwards compatibility either - Babel exists for es6+, but I've not seen a non js-like language that can compile to js achieve much success. I suspect there are one or two areas that the current offerings handle well that aren't being credited or understood. Computer UI is a young field, computer interactions with business and marketing over time are all poorly understood. We spend much of our time reinventing our spinning wheels and relearning lessons. Html in js is bad. No, it is good. Inline css is bad. No, it is good. This isn't all wasted time, there is a lot of learning time. So I doubt we even understand yet what would make a better toolset.
ec109685 9y ago
> I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place. React Native doesn't use HTML/CSS at all for rendering.
hooluupog 9y ago
Flutter has the potential once it ported to desktop and even web(with WASM).
- gman83 9y ago
  I think it'll only be ported to desktop once Fuchsia comes closer to release (which could be several years). They really seem focused on mobile only at the moment. Agree it could be a great solution.
- markdog12 9y ago
  Looks like it has started (MacOS for now) https://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding
zwetan 9y ago
You just described Adobe AIR eg. "something that has consistent, cross platform (desktop and mobile [...]), responsive ui, without the huge web stack"
raquo 9y ago
I really don't mind the HTML / CSS part with new developments such as CSS grid. If you're running it in a controlled environment (embedded browser), you could cut out a bunch of legacy crap, leaving a much leaner engine. Similar cleanup could be done on the DOM API, I guess.
- cm2187 9y ago
  There is something to be said about html being too basic for developping apps efficiently. There is no menu control, contextual menu control, if you want to handle dragging and dropping UI items or creating an overlay modal window you need to do all sorts of hacks. On a desktop UI framework these are often a single line of code and it’s hard to get it wrong. I don’t think html/css is really comparable to the major native UI frameworks in term of productivity and correctness of apps produced. I see so many websites trying to implement their own UI behaviors and getting it wrong, not scrolling smoothly, showing a modal window partially off screen in certain scenarios, preventing you from zooming out on a smartphone while overflowing the text outside of the screen, menus that are either not touch or mouse friendly, etc. Giving UI developpers only html and css is like telling a graphic designer: all you need is microsoft paint, you see you can change the color of each pixel to whatever you want, total freedom! Yeah... No.
  - raquo 9y ago
    Being relatively low level is a feature. HTML / CSS / JS are languages, not frameworks. One liner modals are not a feature a language should have. If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice. Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.
    - cm2187 9y ago
      Why do you call html and css a language? To me it’s a UI framework very much like winform, wpf & al.
gunn 9y ago
Yes. I'd like to see a stripped down embeddable browser engine - https://news.ycombinator.com/item?id=9914925 https://news.ycombinator.com/item?id=9914925 Also there are existing projects like https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos
- jbergens 9y ago
  Like Sciter? https://sciter.com/ https://sciter.com/ I think WPF/XAML could have worked also but there were not much work to port it to anything but Windows.
  - gunn 9y ago
    That's almost exactly what I was thinking of. There does look to be a big caveat with it though - instead of JS, it has an ECMAScript variant called TIScript. I'm sure this was a good choice when it was made, but javascript libraries and tooling are a lot to miss out on now.
- deleted 9y ago
  [deleted]
Sawamara 9y ago
I am sorry, but I honestly do not think that PYTHON of all the things would be the solution to a "UI-problem". To have a good UI system, you need extensibility, you need testing, you need strong types (this one is debatable, but I truly believe this to be true after working with Typescript-based HTML UI-s for the past 6+ months now), and you need performance. I can understand that a lot of programmers got into the mindset of "no, I wont deal with HTML", and I frequently see devs mentioning that they prefer that apps look "native", which is something that has not been a standard in the mainstream dev world for quite a few years now, but the reality is that that "native" dream is gone. People all around the world interact with mobile apps MORE than their dessktop/mobile system'S native ui, so there is no baseline to go back to, there is no good old days to retrieve. We can only move forward with what we have learned, imho. And that might be or might not be HTML, but if something comes along, it better learn all the lessons that we collectively are learning with working through HTML-CSS-JS SPA's.
zserge 9y ago
I agree with you, and I tried my best to change things. A few years ago I made Anvil - a React-ish framework for Android for native UI (reactive, declarative, works best with Redux) and have been using it in many production apps as long as I was doing Android development. But it still is a niche product, most developers prefer visual UI editor and whatever is the official Google way to do Android apps. Still, I'm very proud of Anvil. https://github.com/zserge/anvil https://github.com/zserge/anvil Then, once I had to deal with desktop apps I figured out that HTML/CSS/JS seems to be the best option for custom (no native widgets) and modern (animations, shadows, nice fonts etc) UI. But Electron was a heavy beast, so I made a tiny wrapper over native browser engines (webviews). So far I'm very happy with it, it's much lighter and smaller than electron. And it's very convenient to use from C++ or Go. Some kind people added Rust and Nim support, I'm now working on Python and Node.js bindings. So yeah, it's pretty much language-agnostic, although it's still web UI. I really hope it can take it's niche for small desktop apps that don't need the full power of Electron, yet need to have a good look. https://github.com/zserge/webview https://github.com/zserge/webview
- moosingin3space 9y ago
  Been enjoying your library webview for some small home projects. Thanks!
swiley 9y ago
TCL/TK runs on literally everything except the iPhone.
rebolek 9y ago
Sounds like what Red language http://www.red-lang.org/ http://www.red-lang.org/ is trying to achieve. It is still in Alpha, but already has cross platform GUI for Windows and OS X (with Androind arriving in next release). And without the web stack bloat, it's just single ~1 MB executable.
pier25 9y ago
I've been working in UI for almost 20 years. I've done flash, native desktop, games, web, mobile, etc, and I think HTML+CSS+JS is still the best abstraction for UI IMO. It's certainly not without it's problems though. JS sucks and native performance is way better, but no one can deny it's so much more flexible and powerful than any other thing out there. Here is a great article on this topic: https://medium.com/missive-app/our-dirty-little-secret-cross-platform-email-client-with-nothing-but-html-aa12fc33bb02 https://medium.com/missive-app/our-dirty-little-secret-cross...
mamcx 9y ago
I'm starting a project with a strong need of build the UI in multiple targets (iOS, Android mainly). I try first with html and the native webview. With iOS is totally fine, but Android is SUPER slow. I never imagine that android was this bad, but at least, it force me to do native :) ---- I think that is possible to do what you describe, and I'm working something like. The key is decouple some task (kinda separate "back-end" UI from "front-end" UI): We can do "partial" cross-platform UI, if we think that some stuff can actually cross cleanly: - Layout (the big one, IMHO) with something like https://yogalayout.com https://yogalayout.com - The ELM architecture (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction.html https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) because a big chunk of the logic is totally cross-platform and "only" need to adapt the render of controls. - Dispatching, events and similar stuff, that is not visual. Then finally, the rest can be fully native: - Controls - Drawing - Animations - Call to native libs ---- The big question is what to use for coding this. I'm using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with http://elementscompiler.com http://elementscompiler.com Wish to have a coding partner to do this :)
glibgil 9y ago
https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be&t=38s https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be...
rms25 9y ago
Look up QML (Qt Quick) on Qt, its the easiest UI building experience I've ever had Funny that QML looks alot like the JavaFX script that was abandoned

refulgentis 9y ago

What happened here? "macOS Changed a macOS thing. #123 Windows Changed a Windows thing. #123"

Libturd 9y ago
how about fucking clicking it and looking?
palotasb 9y ago
I guess that's the template text for releases and they forgot to remove it.
dspillett 9y ago
The #123 is a link. Click that for the ticket with more information. Though looking at it, the actual description is no longer than "changed an X thing".
- davej 9y ago
  That issue was 4 years ago. #123 looks like placeholder text.
deleted 9y ago
[deleted]
guessmyname 9y ago
They linked to a GitHub issue explaining a feature request [1]: > We should use the icon of exe as window's icon, and we also need to add a default icon for atom-shell on Windows. [1] https://github.com/electron/electron/issues/123 https://github.com/electron/electron/issues/123

dvfjsdhgfv 9y ago

It's really sad that in spite of the main glaring problem of Electron apps they didn't as much as even mention any work done on performance optimization in 2.0.0. The changes mentioned are just make up when compared to the real problem.

make3 9y ago
this looks likes an internal dev oriented page, not a public announcement type of deal.
ghostcluster 9y ago
scanned the changelog for any mention of performance or memory footprint optimizations. nothing.
- erulabs 9y ago
  Updated V8, Node, and Chrome? That's the performance gain...
realharo 9y ago
Is there anything they could even do in that area? (other than improving Chromium itself)
bengotow 9y ago
Electron’s performance is fairly tied to Chromium’s - the Electron changelog references a Chromium version bump and you’ll need to look there for perf improvements (which isn’t ideal - I wish they’d pulled in some highlights!) To be honest, people using Electron are doing it because of huge business / process wins and worse performance is a generally acceptable downside. Performance is improving as Chromium improves, but it isn’t a huge focus in the Electron community.
nukeop 9y ago
What do you find lacking in Electron's performance? Compared to all competing UI frameworks it isn't really any different, except it allows for faster and easier development and deployment.

paxys 9y ago

Nothing in this seems worthy of a major version bump to be honest.

callumlocke 9y ago
A major version bump is for introducing breaking API changes. That’s all it means.
l2dy 9y ago
See https://electronjs.org/blog/electron-2-semantic-boogaloo https://electronjs.org/blog/electron-2-semantic-boogaloo. As of version 2.0.0, Electron will strictly adhere to Semantic Versioning. Major Version Increments * Chromium version updates * Node.js major version updates * Electron breaking API changes
- jbergens 9y ago
  Sounds a bit like angular and we might get electron 3 and 4 very soon if they feel a need to update Chromium or Node.
AgentME 9y ago
If they're following semantic versioning, then they bump the major version number whenever they make breaking changes.

0XAFFE 9y ago

I wonder why there is no runtime package for all your electron applications, so you only have to install the runtime once and every app can depend on this runtime. This would greatly reduce download sizes of individual applications.

Drakim 9y ago
I assume because it would defeat the intention of electron, since the entire point is to "magically" make your webapp into a standalone application with no dependencies. Just download and start it up, like any application. Whether this is wise is another question.
- greglindahl 9y ago
  ... and with this sort of magic, I expect that all of the applications that I download are going to have completely different versions of all of the dependencies, so, ... there's no sharing anyway.
callumlocke 9y ago
Because the market-proven reality is most end users don’t care about 100MB download sizes, and they do care about simplicity.
- nukeop 9y ago
  100 MB is nothing. My electron program is only 35 MB in size. Most people have multiple 1TB disks now.
  - imtringued 9y ago
    Or people have laptops and because they don't waste it on bloated crap like Windows and instead use linux a single 256NVMe SSD is enough. I use 50GB right now for the Linux installation with everything I could possibly need for work and another 50GB for two empty Windows VMs with nothing in them except a browser.
  - 9y ago

_o_ 9y ago

With all the GUI crap going on in software development, I am starting to miss MFC and BCG libraries, I know it is not feasable for most developers to code in c++ but at that time the GUI, even if run over RDP, was fast, responsive, now I having a feeling like 386 was faster than todays i7+. And to cirmuvent obvious incapability of RAD to provide decent user expirience, they are changing our UI percepction from trendy perspective, leveling everything to flat and extremly simple, like ncurses on graphical desktop. =/

greenhouse_gas 9y ago

What would be interacting is an electron like environment with a pared down JS/CSS engine which only let "modern JS/CSS" (maybe something like Servo). It can be optimized for that, and you don't really have to render electron apps from the 90s anyways. Another idea is that when wasm will be able to interface with DOM, you'd be able to write GUI code in any language which compiles to wasm. So you won't _need_ Rust (or Go, or Haskell, or D, or your up and coming toy language) bindings for win32, Qt, GTK, etc. Just waste a few hundred megs (only partially /s) and you've got a full ui.

jbergens 9y ago
MS seems to be on the way to support PWA directly in Win 10. If other systems would do this as well we won't have to ship a full runtime like Electron. https://blogs.windows.com/msedgedev/2018/02/06/welcoming-progressive-web-apps-edge-windows-10/ https://blogs.windows.com/msedgedev/2018/02/06/welcoming-pro...

dcgudeman 9y ago

Why not upgrade to the most recent version of chromium? (64 instead of 61)

samwillis 9y ago
Because it takes longer than the chromium release cycle to do an electron/chromium upgrade. I think they only tend to do the upgrade a few times a year. Chrome 61 will have been current when they started the upgrade process.

vbsteven 9y ago

I wonder if it would be possible to change the electron build process so it builds 2 outputs: 1 "big" package with full Chrome inside and 1 "light" package that just contains the application code. The light package could then be offered as an alternative download on the website to run on a specific "electron-runner" that can run multiple electron apps side by side. I know that I just described a regular browser with tabs or windows but hey, Electron is what we have right now and it is not going away soon. This might be a solution for people running multiple Electron apps side by side.

hashhar 9y ago
Reminds me of XULRunner from Mozilla.
nukeop 9y ago
If you don't need the APIs that interact with the local system, you can already build for Electron and for the browser easily. If you need those APIs, however, there's no other possibility because of the browser sandbox.
- NoGravitas 9y ago
  It's possible to have a native (node?) app for the local side, which talks to a browser extension. This way you don't have to run multiple instances of the browser runtime. There's someone writing a full-featured, Patchwork-like SSB client in Firefox this way, but unfortunately I can't remember the name.
kilian 9y ago
A project with that idea is Electrino: https://github.com/pojala/electrino https://github.com/pojala/electrino It provides an electron-like API but uses the OS version of safari. It doesn't seem to be actively developed anymore though.

mherrmann 9y ago

People not satisfied with Electron's performance might be interested in fbs [1]. It makes it very easy to create desktop apps with Python and Qt. It was in the #1 spot here two weeks ago [2]. (I'm the author.) [1]: https://github.com/mherrmann/fbs https://github.com/mherrmann/fbs [2]: https://news.ycombinator.com/item?id=16318677 https://news.ycombinator.com/item?id=16318677

samwillis 9y ago

Does anyone know if there has been any work on bringing the work from “headless chrome” to electron? It would be awesome to be able to use the full node.js environment with a headless browser natively.(headless chrome with puppeteer is good but electron would be better)

eklavya 9y ago

You can use React and js to build native desktop apps without electron today. Use https://proton-native.js.org/ https://proton-native.js.org/ (based on libui).

plopz 9y ago
While that is certainly a promising library to watch for in the future, I wouldn't say its ready to go today. Its based on libui which is in alpha and was stagnant for quite awhile. The developer just recently (this week) started working on it again so there is potential.

thiht 9y ago

As much as HN hates Electron, it's probably one of the best things to happen on desktop, especially on linux desktop ironically. It works, it's beautiful, it's easy to use, and unlike many people here, I believe the HTML/CSS/TypeScript/React is rock solid and the closest thing to THE solution to the UI problem.

factorialboy 9y ago
I agree it works quite alright - not perfect, but nothing's perfect, right? Of course there are some poor implementations (Slack) and some really good one's (VSCode). Criticism of the platform for the deficiencies of an implementation feels a bit lazy.
beojan 9y ago
> one of the best things to happen on desktop, especially on linux desktop ironically Not by a long shot. It's one of the worst things to happen on the desktop, because people who would have built a proper desktop application just wrap their web app in Electron instead. It's particularly bad for the Linux desktop, where people are used to small binaries that use the system-wide Qt or GTK so they load fast, and use little RAM.
- yoz-y 9y ago
  I think the idea is that most developers would not make a proper desktop app, and without electron there would just be not app at all. But I think that Electron is a short term good which will cause a lot of long term "bad".
  - beojan 9y ago
    > I think the idea is that most developers would not make a proper desktop app, and without electron there would just be not app at all. Precisely, people will just use something else. The proliferation of Electron apps splits the user base, so there's less incentive to develop a proper desktop application.
- stelonix 9y ago

darklajid 9y ago

Waiting eagerly for VS Code to upgrade. As far as I understand, this fixes the "precision touchpad" bug on Windows..

mememaestro 9y ago

Can't wait to transfer my web apps to Electron and see how laggy it gets. Because fuck u assholes

kimjongman 9y ago

How many jiggabytes space it requires for an app?

nkkollaw 9y ago

One thing I don't understand about Electron is, why not share a single Chrome process (or if anything one per Chrome version if needed)

tradedash 9y ago

We have been using Electron for https://tradedash.io https://tradedash.io (our crypto currency trading platform) for some time now. There are some minor issues with the platform itself but there are a lot of good things too. The JS ecosystem as a whole needs to improve but as far as Electron goes, I must say that I am pleasantly surprised with how well it has been doing even though we are handling data from multiple exchanges at a rate that is not so trivial.

disiplus 9y ago
why is this a "native" app and not just a new tab in chrome ?

Aelius 9y ago

I agree with all the complaints about electron performance, but the thing that really gets me is how horribly developers fail at responsive design, with a toolset that is probably the most suited for responsive design since terminals. How the hell do slack, discord, and gitter STILL not collapse their sidebars when you resize the containing window to be tall and narrow? It makes them unusable in a tiling WM, and it's generally disrespectful of screen real estate in any WM. This is the price of easily accessible development. We're doomed to relive past mistakes in UI, as new developers are blissfully unaware of lessons learned by existing frameworks. Many people here are saying electron is popular because of a lack of sane, consistent toolkits across each OS. There's also security to think of too. Electron is likely very insecure relative to native software, but the responsibility is purely on the electron devs: freeing the app developer of that burdon. Electron rose in an environment with no competition in that regard. But now, Windows has UWP, and Mac has their own app platform. I sincerely hope we see these more universally leveraged, such that developers will stop abusing the web for app development. And I guess Linux will just have to make a WINE for UWP, I can't imagine the Linux community coming together to create something like that for themselves.

kroltan 9y ago
> And I guess Linux will just have to make a WINE for UWP I might be wrong, but isn't that literally Snap Packages? https://www.ubuntu.com/desktop/snappy https://www.ubuntu.com/desktop/snappy

FreezerburnV 9y ago

Since it’s something I’ve been paying attention to for a while: this (beta, sure, but soon to be full. Probably would work fine for doing some dev work) release of Electron finally bundles the version of Chrome that implemented SharedArrayBuffer support. This means that developers can now spawn web workers (real parallelism) and communicate with them much faster than previously with message passing. So there could be some big wins for things like developing games in Electron since you’ll be able to do some big number crunching off the UI “thread” and hand the results back to the UI with little performance penalty. (Especially if there are a lot of results, such as a theoretical fully-updated scene graph worth of matrices in an array) Hooray for less jank on the renderer!

ihsw2 9y ago
Notably, `SharedArrayBuffer` was disabled (starting Jan 5 2018) due to Spectre. Nevertheless, it is going to be re-enabled so it is worth reading up on shared memory in JavaScript -- more to the point, Atomics. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I know a lot of people scoff at the Node/browser runtimes, which is warranted and totally unrelated to the language known as JavaScript, but performance is improving.
- FreezerburnV 9y ago
  Is it disabled in the version of Chrome shipping with Electron? Considering they’re usually some number of versions behind, and this is a tool to make a desktop app, it would seem to be desirable to have it enabled regardless of Spectre since a desktop app can own your computer anyway if it wants. (It does make sense to have it disabled in a general purpose browser until mitigation’s are in place)
jpambrun 9y ago
You can already experiment with SAB in electron 1.7.9 with flags.
- FreezerburnV 9y ago

ed_blackburn 9y ago

How long before the Electron APIs are aped by OS extensions and managed more effectively than Blink?

ericfrederich 9y ago

Never really heard of Electron before I tried using KeyBase on Windows. It seems electron is the reason that it doesn't work on my machine. Ran into this last night. https://github.com/keybase/keybase-issues/issues/2813 https://github.com/keybase/keybase-issues/issues/2813

pier25 9y ago

Sadly the biggest problems with Electron are not yet solved: 1) There is no way to separate the Electron engine from your app, so you have to bundle Chrome and Node with each app. 2) Electron has an autoUpdater API, but since Electron doesn't solve the installation/updates problem e2e (packager + installer + updates server) it's really a half baked solution. This is specially bad in Windows since Squirrel for Windows is in my experience a disaster. I have a number of Electron apps in production, internally and for our customers, and for our next desktop project we won't be using Electron. The idea of using web technologies for the UI is still very valid IMO, but considering the 2 previous problems it's way less of a headache to just make our own native wrapper in C# and Swift (sorry Linux) and finally distribute the app via the official stores. At least for our use case.

solarkraft 9y ago
Or release it as a web application and let the user use chrome's "add do desktop" ... I don't like that you're dropping Linux compatibility, but understand the the reasoning.
- pier25 9y ago
  We've done that on mobile, but most of users don't even know that feature exists and another big chunk still don't trust a website vs an app. I've never seen this feature in desktop. Closes thing I know are these "hosted web app" in Windows 10. https://docs.microsoft.com/en-us/windows/uwp/porting/hwa-create-windows#step-1-pick-a-website-url https://docs.microsoft.com/en-us/windows/uwp/porting/hwa-cre...
  - jamesgeck0 9y ago
    The feature is only available in the Windows and Linux versions of Chrome. https://www.lifewire.com/create-shortcuts-in-google-chrome-for-windows-4103617 https://www.lifewire.com/create-shortcuts-in-google-chrome-f...
gilrain 9y ago
I've been using the Sciter bindings for Rust, lately. It might be worth a look if you want a more performant option for a HTML/CSS GUI. The documentation is pretty rough, though. https://sciter.com/ https://sciter.com/ https://github.com/sciter-sdk/rust-sciter https://github.com/sciter-sdk/rust-sciter

billfruit 9y ago

I have only a very cursory look at Electron, but I find two things problematic: Lack of support for legacy systems, and the complicated build process of apps built with Electron, most can't successfully build unless you download a ton of stuff from npm. The kind of place where I am with many many older machines, never connected to the internet, Electron hardly makes any sense.

twtw 9y ago

Is Electron still single threaded like Node?

ohthehugemanate 9y ago

Can anyone explain for me: WHY is electron such a resource hog? Is it just because chrome is a resource hog? Could it be trivially re-engineered to wrap quantum instead?

wodenokoto 9y ago

What is the stack behind RStudio? It isn't electron, but it is an HTML app, run by a browser (safari on my macbook pro, wonder if it is IE on windows) It doesn't feel as heavy as electron apps.