11 ms·

These projects completely overlook _why_ people choose Electron over the system view. - Nobody wants to be testing against multiple browser/rendering engines i

These projects completely overlook _why_ people choose Electron over the system view. - Nobody wants to be testing against multiple browser/rendering engines in 2019. - Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. Edit: Since I can already see the litany of armchair-quarterback-desktop-app-authors, I'm just going to link to the comment from the guy who actually migrated Slack away from WKWebView. https://news.ycombinator.com/item?id=18763449 https://news.ycombinator.com/item?id=18763449 Blows my mind we're still debating this.

Octoth0rpe 8y ago
> Nobody wants to be testing against multiple browser/rendering engines in 2019. That's certainly _one_ reason why. I would posit that the main reason is that web developers would like to reuse their webapp skillset for building desktop apps. This seems like it accomplishes the goal. Re: testing against multiple browsers, frankly this is _mostly_ a solved problem. The big gaps between rendering engines is on the real fringe of css at this point, which most of us aren't bothering to use. Also, many people builting on top of electron (and presumably this platform) are using css toolkits like blueprint, and most of those take care of most of your cross browser issues anyway. So, largely not a concern.
- Klonoar 8y ago
  It is not a mostly solved problem. The people behind Slack, Spotify, and so on have actually commented on these threads explaining the exact line of reasoning. This stuff isn't limited to just CSS, and it makes total business sense to avoid it.
  - Octoth0rpe 8y ago
    Maybe I'm just spoiled having doing web dev back in the netscape 4 era when things were _really_ bad. These days it seems like a reset stylesheet and a couple polyfills and you're good to go. I don't doubt that certain problem spaces still run into major cross browser issues, but I guess I've been lucky enough to avoid those problems for the last couple of years.
    - Klonoar 8y ago
      I'm just gonna link the actual Slack author who's already commented on this before and exit the thread. https://news.ycombinator.com/item?id=18763449 https://news.ycombinator.com/item?id=18763449
    - ehnto 8y ago
      There are definitely areas of the browser API that are quite problematic, especially when it comes to things needed in a UI like Spotify and Slack use. A brief look into the drag and drop implementations in browsers should be illuminating enough. The desire to use new features as soon as possible is driver enough I feel. Imagine having to wait years for parity between 6 different operating systems before being able to use classes, a language feature introduced years ago and that still isn't fully supported today.
  - solarkraft 8y ago
    The apps you mention are available on the web, so they have to do these exact things anyway. What they really want to do is make that web app installable in the OS, no? I use WebPin to "install" websites (until this works natively in Firefox with PWAs) a lot of the time, even when they offer electron bundles (with the browser I already have, nodejs I already have ...).
  - kodablah 8y ago
    I'd consider slack/spotify to be the outliers and I don't think this is targeting them. For the rest of the webdevs that just want to make a web app, Electron is appealing to them too and we shouldn't pretend the only reason they pick it up is browser compat issues.
  - ploxiln 8y ago
    I don't consider Slack and Spotify to be good at making applications (despite their popularity). These are the least efficient chat app and least efficient music app ever, in a multi-decade history of chat and music apps, which didn't have the overflowing abundance of convenience and productivity offered by Electron. (This is like the obviously silly quote "we lose money on every sale, but we'll make it up in volume!" translated into "this rich environment and set of libraries enables such amazing developer productivity that we can create much better optimized user experiences!" while the laggyness and flakyness and huge memory use are just never optimized away with that productivity.)
    - zapzupnz 8y ago
      > least efficient chat app ever I dunno, Discord might be gunning for that prize.
    - hn_throwaway_99 8y ago
      > These are the least efficient chat app and least efficient music app ever Which 99% of users never care about. The idea that large memory usage is a negative business driver is almost laughable at this point, yet for some reason it is a huge pet peeve among lots of technologists.
      - hug 8y ago
        They care about it a lot more than you imply, they just don't know that it's something they care about. I partly manage a team of end-user support people, and the number of tickets they get with "my computer is slow!" is astonishing. The number of times it's found that they have Slack eating over half the RAM of their corporate-issued laptop (read: wimpy specs) is huge. The number of people who understand that Slack being an insane resource hog is a large part of what is making their daily computing business painful is the inverse.
      - Erlich_Bachman 8y ago
        Users absolutely care if their app runs slower. Even marginally slower in the order of 1/10 of a second. Even subconsciously users will choose the app that runs faster and smoother, this is why google.com first page is optimized and compressed saving individual bytes sometimes. This is why all big websites use servers all over the world to save 10ms in ping for users which are near them. The only debatable question is whether the exact memory overhead (of electron for example) on the specific user machines existing out there today will make a noticeable loading time or lag difference. For many users it seems it does, not everyone has the lastest hardware.
patr0nus 8y ago
> Nobody wants to be testing against multiple browser/rendering engines in 2019. That's why DeskGap uses EdgeHTML on Windows. With toolchains such as webpack and babel, building an app that runs on WebKit and EdgeHTML (which is going to be replaced by Chromium[0]) can't be that hard. > Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. DeskGap doesn't mean to be a complete replacement for Electron. But after a glance of Electron Apps[1], I suppose many simple apps do not require start-of-art features. [0] https://blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration/ https://blogs.windows.com/windowsexperience/2018/12/06/micro... [1] https://electronjs.org/apps https://electronjs.org/apps
- Klonoar 8y ago
  Mmmhmm. That's cool, although not original. As I noted in an above comment... https://news.ycombinator.com/item?id=18763449 https://news.ycombinator.com/item?id=18763449 Projects like DeskGap make this out to be a simpler problem than it actually is. ;P
- zamalek 8y ago
  > That's why DeskGap uses EdgeHTML on Windows Strangely, that would likely make it most conformant on Windows. I can't imagine that KHTML is up to date in terms of specifications (but I could easily be completely wrong about that) and Apple/Safari is taking tips from Microsoft during their IE days. It would seem that the platform differences would be quite large, but at least the JS engine would be consistent.
petecox 8y ago
That would be an argument for Microsoft switching to Chromium, albeit 'Edgium' might not entail the bleeding edge 6 week Chrome release cycle.
kalleboo 8y ago
The Slack dev you're quoting doesn't mention any of your points. His points were that the native extension API was clunky (DeskGap could improve upon this), that users of old OS versions are completely left out in the cold for updates (he mentions severe UI bugs, which is very different from "we need bleeding-edge Chrome features"), and that the difference would be negligible anyway since the poor RAM and CPU usage is from their own garbage JavaScript code anyway, not the browser engine.
- pmontra 8y ago
  A Slack written with DeskGap wouldn't run on Linux. I'm using Slack in the browser anyway but maybe not supporting Linux could make some software fail compared to a competitor supporting it.
iffycan 8y ago
Also, Electron provides things like single command building, automatic updates and menu bar support (which looks supported in DeskGap).
stonogo 8y ago
Then again, the Slack app segfaulted on launch for months because of a node.js incompatibility with newer glibc. So I guess what you've traded for is - Nobody bothers to be testing against multiple operating systems in 2019. - Everybody gets to wait for Slack to get around to it while the system webview gets the compatibility update almost immediately. Great for the authors, shit for the users. On the bright side, it was the straw that broke the camel's back, and my org doesn't pay Slack any more.
- ahartmetz 8y ago
  Nice. What did you switch to? I'm watching that space so i can recommend alternatives everywhere I work. Must be F/OSS. Top of the list currently are Rocket.chat and Matrix.
  - h1d 8y ago
    Try mattermost
    - ahartmetz 8y ago
      Nah, definitely not Mattermost. It's open core, which is kind of dubious, and not better than Rocket.chat - we switched away from it to Rocket.chat at a previous job.
  - stonogo 8y ago
    We switched to IRC. Most of the team uses irccloud, and a handful of us use pidgin or hexchat or the like.
tambourine_man 8y ago
>Nobody wants to be testing against multiple browser/rendering engines in 2019 Nobody does. CSS is pretty mature, a difference in rendering between modern engines is extremely rare
- onion2k 8y ago
  That just isn't true. You only need to browse caniuse.com for 5 minutes to see there are significant differences between browsers even for mature CSS features. If you want to use anything new it's a minefield.
  - lugg 8y ago
    Not sure why your ADHD fuelled shiny seeking is an excuse for the shitshow that is electron. Just don't use new stuff? I'm also unsure how it is even supposed to solve that specific issue considering my laptop is currently running at least two versions of electron for different apps, both of which render text as their primary directive.
    - arvinsim 8y ago
      The parent comment was stipulating that CSS is mature. The reply was that it isn't because there are lots of features that are not available to all browsers. A mature platform would be one where the features are consistent in whatever environment it is in. So in that regard, CSS is not mature. "Just don't use new stuff" is not an excuse.
      - lugg 8y ago
        I never said it was an excuse. I said it was a valid approach, so are polyfills. My issue isn't really with that my issue is that the issues with CSS and the valid workarounds are not painful enough to validate electron as a solution. If electron did what it promised I wouldn't have a problem.
    - kkarakk 8y ago
      just don't differentiate from your competition using new features, instead focus on features users don't value at all - like memory consumption and being browser agnostic
gameswithgo 8y ago
https://azul.rs/ https://azul.rs/
- cetra3 8y ago
  I think Azul is definitely promising, but it's still alpha level, when I first tried to run it on OSX Mojave I got a nice black screen: https://github.com/maps4print/azul/issues/35 https://github.com/maps4print/azul/issues/35 The next time I ran it, it worked on release mode, but panicked on debug mode. I've just tried again from master and it works, which is an improvement!
  - saagarjha 8y ago
    This probably has something to with layer backing (and changes in OpenGL, if they're using it).
  - gameswithgo 8y ago
    It was really pleasing to read about this steady progress!
- hjhome2000 8y ago
  looks very promising
- Klonoar 8y ago
  These projects are admirable, but people severely underestimate just how much work goes into building a true GUI solution. The insane amount of stuff required to wrap is bonkers-level crazy - you cannot easily match the millions of developer hours poured into the APIs used by MSFT/Apple/Linux, or the sheer complexity of a web browser. You hands-down could not build Slack, Spotify and so forth in a solution like this. You would end up refactoring it very quickly when users start walking away because you can't have a feature they want (playing video, gifs, etc).
eridius 8y ago
Slack migrating to Electron was by far the worst decision they’ve ever made for UX. That one migration introduced a ton of bugs and platform inconsistencies, most of which are still around. One I just complained about the other day is Electron apparently doesn’t handle font fallback properly, so if I type an emoji that Slack doesn’t support, such as [frozen face], it just renders as a placeholder square in desktop Slack even though it renders as the emoji on both the website and in the iOS app. Edit: Apparently HN strips the emoji from the comment [facepalm]
- laumars 8y ago
  Slack doesn’t pick up my system dictionies correctly so I keep getting American English suggestions for words correctly spelt in GB English. It’s very annoying and I have no idea how to fix it. Wouldn’t have this problem with a native app.
  - Klonoar 8y ago
    Having built this kind of thing natively, you actually might! macOS, for instance, has a few race conditions that can (easily) occur when using the built-in spell/grammar-checking functionality on text field/view instances. ...which is exactly the kind of thing that nobody wants to deal with when trying to ship a product. ;P This myth that you get these things for free with native apps is just that: a myth.
    - laumars 8y ago
      > Having built this kind of thing natively As have I :) > you actually might! macOS, for instance, has a few race conditions that can (easily) occur when using the built-in spell/grammar-checking functionality on text field/view instances. That forces it to load the wrong dictionary (one which differs from the system dic) and do so repeatedly each and every time you use the application? That doesn't sound much like a race condition to me... > This myth that you get these things for free with native apps is just that: a myth. Is that actually a myth though? Because I've never heard anyone suggest that - least of all uttered that nonsense myself.
aylmao 8y ago
> Nobody This is like claiming nobody wants to write C because no one wants to manage their own memory in 2019, or miss out on all the cool new packages in the JS ecosystem. Evidently _some people_ do. I can assure you there's at least number _n > 1_ of people who care more about app size than either of your points. I personally wrote a side project in system web-view, because I don't want my macOS-only system-tray application to weigh 115+MB to make sure I have APIs I don't need in platforms I don't support.
- toper-centage 8y ago
  I mean, fuck the users. Will nobody think of the poor poor developers?
  - arcturus17 8y ago
    Never heard a non-programmer user complain about the Spotify or Slack desktop apps, but that’s just me.
    - elcomet 8y ago
      That's because programmers know that it could be much faster if done with native technologies. Non-programmers assume this is normal and now they are used to slow apps. Also, they don't know that the reason their whole system is very slow is slack.
    - chipotle_coyote 8y ago
      I have absolutely heard non-programmer users complain about the Slack desktop app. They may not be able to diagnose why it is being slow or unresponsive, but they can still tell when it's being slow and unresponsive. And while the term "power user" has fallen out of favor, there are still users who aren't programmers, per se, who nonetheless understand concepts like memory and CPU usage.
    - middleload 8y ago
      Maybe you don't listen. "Apps" like Slack are on my hate list even above desktop Java apps. Seriously, I can't understand how come it's acceptable to use >1GB of RAM to display 10 lines of text.
mch82 8y ago
> Nobody wants to be testing against multiple browser/rendering engines in 2019 Yes, lots of projects want multiple, competitive rendering engines. It used to be that Windows was the only viable target OS for commercial software. Firefox and Safari gave IE competition and gave developers who wanted to target Mac and Linux a way to get a foot in the door. That kicked off the whole generation of web apps we’ve just lived through. If developers give up on Gecko and WebKit, then they allow a monopoly again. And since Electron is made by GitHub and is now owned by Microsoft, Microsoft will again have the monopoly (with the caveat that Google has primary influence over Blink). Render engine competition keeps web standards relevant, which keeps the web open. Take away competition & we’ll be back in a world where people build to IE6 for a decade instead of targeting standard HTML/CSS/JS.
- EGreg 8y ago
  I’m going to disagree. Over the two decades I have been programming I have come to appreciate the benefit of Open Source Collaboration vs competition. Competition between platforms is good, but it’s not the best. Because those who produce content waste millions of hours collectively trying to address every little quirky difference between the platforms. And the standards only help so much, whether it’s POSIX or WHATWG. The real reason MS and IE were not so good is because they were a closed source monopoly! And moreover the copyright was enforced by the government. Now even M$ switched over to WebKit / Blink. Collaboration beats competition in the end. Wikipedia beat Britannica quite handily. And it beat Encarta, too. Open source beat closed source over time. The Web beat AOL and Compuserve. Science beat secret cults and alchemy. Today Pharma is using patents and competition. People are prevented from building on each other’s work in microbiology but not in other sciences. Isn’t that wild? I would rather have lots of people adding to one snowball platform, than having competing platforms. AS LONG AS that platform is open source and anyone can use it for any purpose. If your commits don’t make it into the core, just market them until they get popular enough. Compatibility is the goal, though.
  - gpvos 8y ago
    Chrome/Blink may be open source, but it's controlled by Google after Blink forked from WebKit. It's hardly collaborative.
finchisko 8y ago
I want small app package. By not bundling webview, deskgap looks perfect to me.
EGreg 8y ago
I wonder how all those commenters from HN who always say “we should have more competition in the brower engines” feel about your sentiment.
pjmlp 8y ago
Right on, this generation has no right to complain about IE only web sites. /s
- Klonoar 8y ago
  IE only websites was an issue when the engines were closed source and intentionally held back. We're well past that point with modern browser engines.
  - pjmlp 8y ago
    Yeah right, Chromium is not the same thing as Chrome.
CyberDildonics 8y ago
Doesn't anyone who makes a webpage need to test it in different browsers?
- Klonoar 8y ago
  This is a thing that's really specific to web-design, though. People writing desktop apps want it to "just work", which is why Electron is a godsend (in this regard).
  - CyberDildonics 8y ago
    Why do people not think that cross platform GUIs don't 'just work'? The effort to get something that already works to another platform really isn't much. Also electron doesn't 'just work'. A simple program being 300MB with a laggy sluggish interface is not 'just working'.
maaaats 8y ago
> Blows my mind we're still debating this. Maybe you should consider that a sign that it's not as black&white as you tout it to be? I mean, what a way to just dismiss everything..
- ionised 8y ago
  Should we consider the anti-vax movment as a sign that all is not black and white with vaccines? Of course not. Just because people are still having the conversation it doesn't mean the conversation is worthwhile.
- Klonoar 8y ago
  I'm dismissing it because the collective energy wasted on people complaining about Electron's rise is getting really old. Until a native environment offers feature-parity with Electron, the discussion won't change, and the sooner people start paying attention to that the better. So yeah, it's pretty black and white. ;P
microcolonel 8y ago
> Nobody wants to be testing against multiple browser/rendering engines in 2019. Soon they'll all be WebKit or Chromium.
- h1d 8y ago
  And where does Firefox go?
  - pawelmurias 8y ago
    graveyard
laumars 8y ago
I get that writing tests often isn’t fun but it’s as much a part of responsible development as writing useful error messages and not using experimental features on production builds. What really blows my mind is that we’ve reached a point in computing where the developers laziness now outranks the customers needs. > Since I can already see the litany of armchair-quarterback-desktop-app-authors I think you’ll find those who are offering counter arguments aren’t just armchair critics. Eg I’ve been writing software since the 80s. This includes a considerable amount of desktop software. So I’d like to think my opinion is just as valid as your own. ;)
- Klonoar 8y ago
  I'm actually wading back into the comments here for this specific comment, because it's ridiculous. It's not developer laziness. This is 100% a business decision, and if you've been doing this since the 80s, I'd expect you to know this by now. Do you really think Slack & co chose Electron because it's making developers lives easier? Companies and people choose it because it. just. works. across platforms. This has a direct translation to money, no matter how much you stick your head in the sand about it. Less resources, less platform-specific wizardry, more focus on core features with faster turnaround time. _That_ is all that matters here at the end of the day, because programming is not - nor has been, for the majority of roles, for some time - been about coding and tinkering with bits. It's about increasing revenue for the company/product/whatever. When you (the general you, not you specifically) rant about reimplementing everything Electron gives you on three platforms, you gloss over the wealth of shit a web browser provides for free. I have actually implemented some of this stuff outside of a browser, and I wouldn't do it again if you were paying me. _Furthermore_, very rarely does anyone compare implementing something via Electron to native... but native is a landmine-filled problem area of it's own. macOS alone is horrendously undocumented these days for a good portion of stuff, and you'll end up with a litany of platform specific hacks for the most basic things. Hell, the easiest response to this comment is this: neither of our opinions needs to be valid, because the market's opinion is that Electron is the better choice.
  - laumars 8y ago
    I do get that point of view but there are as many exceptions to that rule as there are examples. Take mobile app development: half the products that run on Electron on the desktop will still have native apps on mobiles. And even those that don’t would still have to use the native renderer on iOS and Windows Phone thus you’d be testing your common code base across multiple rendering engines anyway (which was the argument against the tool in this discussion).... and I’ve not even meantioned the slew of cross-platform applications that exist which have successfully avoided using Electron. There are quite a few cross platform frameworks out there these days and different languages that can leverage them, however the next point I think is the real crux of the problem: I will grant you that Electron does lower the barrier for entry (which is ironic because I personally find the web stack more awkward to develop in than native widgets - but each to their own). And maybe that’s where the biggest cost saving comes for the business; you can hire cheaper engineers to build and support your desktop software? In any case, I’m not blind to the appeal of Electron; I just don’t agree with how important it is in the same way as the GP does.
zaarn 8y ago
These two "nobody" reasons is why we are tettering on the edge of a browser monopoly, which will likely hurt desktop apps too if they use electron.
- Klonoar 8y ago
  Monopoly = IE6, closed source, controlling the web. Monopoly != multiple large vendors contributing to Chrome/Webkit/etc.
  - zaarn 8y ago
    Chromium is still only a single engine under majority control by Google. Almost noone else contributing to Chromium does enough that they could maintain the engine as a fork indefinitely.
blauditore 8y ago
> Nobody wants to be testing against multiple browser/rendering engines in 2019 You mean like when building websites?
- boffinism 8y ago
  I build websites, and I don't want to be testing against multiple browser/rendering engines. I do it cos I have to, not for the hell of it.
  - hawski 8y ago
    I and most people work, because to not starve we have to, not for the hell of it. So the original statement is truism. Nobody wants to do the hard work in 2019.
    - Klonoar 8y ago
      It's not "hard work", it's monotonous and not worth the time. When even Microsoft realizes that, there's possibly some truth to it.
atoav 8y ago
As somebody who deals with HTML and CSS often I like the idea to be able to use these layout skills in a desktop GUI. But size and speed matter (you don’t see much elektron based games..). We as a humanity can’t just always build faster and more powerful computers and then let developers throw these gains away by building more elaborate Rube-Goldberg-machines, that take 100 times the space they need, running more things taking the same old time we are used to wait, with dependencies no single human ever checked at once. Many of same people who waste tremendous amounts of energy and collective human time writing ineffective applications might end up to be really pro-environmentalists outside their job, but when it comes to computers suddenly we don’t care. As long as it is acceptable on a new machine, who cares, right? It would be entirely possible to write perfectly fast and efficient GUI applications using HTML and CSS as layout engines without dragging whole browsers into this. Using system webview might not be the solution. But maybe something that doesn’t feel like it has been taped together with duct tape would help. A fully fleged browser engine for a desktop app is overkill in most common usecases and while I understand why one decides for Elektron, I’d rather see a really thought out solution than one that has been duct taped together.
- arvinsim 8y ago
  > Many of same people who waste tremendous amounts of energy and collective human time writing ineffective applications might end up to be really pro-environmentalists outside their job, but when it comes to computers suddenly we don’t care. As long as it is acceptable on a new machine, who cares, right? This is such a privileged thing to say. I would guess there are far more important environmental problems to worry about. There are also more things that can be done that have more impact. > It would be entirely possible to write perfectly fast and efficient GUI applications using HTML and CSS as layout engines without dragging whole browsers into this. Using system webview might not be the solution. But maybe something that doesn’t feel like it has been taped together with duct tape would help. A fully fleged browser engine for a desktop app is overkill in most common usecases and while I understand why one decides for Elektron, I’d rather see a really thought out solution than one that has been duct taped together. Convince platform owners to agree on a common spec for GUI that's implemented consistently. Otherwise, what you want will ever remain a pipe dream.
darkblackcorner 8y ago
> Nobody wants to be testing against multiple browser/rendering engines in 2019 If you don't want to test multiple (browsers) ANYTHING, you shouldn't be a (web) developer. Seriously, this is why we still have sites that only work in IE.
_pmf_ 8y ago
> Since I can already see the litany of armchair-quarterback-desktop-app-authors I'm so very sorry our 20 years of experience that causes us to reject the subpar monstrosities you like to call "dektop apps" rubs you the wrong way.
- Klonoar 8y ago
  20 years of dev experience, yet people stick their head in the sand when the topic switches to why Electron is so successful. ;P So yeah, it does rub me the wrong way. The people who argue against Electron are the programmer's programmer: they like tinkering, they care about the code, and so on. Most businesses don't. Users never see the code. If you want better, you need to beat Electron and stop ignoring or decrying why people opt for it.
josteink 8y ago
> Nobody wants to be testing against multiple browser/rendering engines in 2019. Speak for yourself. I hate to break it to you, but in the real world there are multiple browsers. Not testing in more than one is lazy, standards ignorant and an insult to your users. Let’s not repeat the MSIE-fiasco again. We know better. We can do better.
- Klonoar 8y ago
  >Not testing in more than one is lazy, standards ignorant and an insult to your users. Slack et al are more successful with users, and have delivered more value to them, than 99% of the work people who post here are doing. Pretty sure this isn't insulting them. And for the last time, this isn't the MSIE-fiasco all over again. The primary engines used today are all open sourced, it's not vendor lock in on the level it used to be.

Octoth0rpe 8y ago

> Nobody wants to be testing against multiple browser/rendering engines in 2019. That's certainly _one_ reason why. I would posit that the main reason is that web developers would like to reuse their webapp skillset for building desktop apps. This seems like it accomplishes the goal. Re: testing against multiple browsers, frankly this is _mostly_ a solved problem. The big gaps between rendering engines is on the real fringe of css at this point, which most of us aren't bothering to use. Also, many people builting on top of electron (and presumably this platform) are using css toolkits like blueprint, and most of those take care of most of your cross browser issues anyway. So, largely not a concern.

Klonoar 8y ago
It is not a mostly solved problem. The people behind Slack, Spotify, and so on have actually commented on these threads explaining the exact line of reasoning. This stuff isn't limited to just CSS, and it makes total business sense to avoid it.
- Octoth0rpe 8y ago
  Maybe I'm just spoiled having doing web dev back in the netscape 4 era when things were _really_ bad. These days it seems like a reset stylesheet and a couple polyfills and you're good to go. I don't doubt that certain problem spaces still run into major cross browser issues, but I guess I've been lucky enough to avoid those problems for the last couple of years.
  - Klonoar 8y ago
    I'm just gonna link the actual Slack author who's already commented on this before and exit the thread. https://news.ycombinator.com/item?id=18763449 https://news.ycombinator.com/item?id=18763449
  - ehnto 8y ago
    There are definitely areas of the browser API that are quite problematic, especially when it comes to things needed in a UI like Spotify and Slack use. A brief look into the drag and drop implementations in browsers should be illuminating enough. The desire to use new features as soon as possible is driver enough I feel. Imagine having to wait years for parity between 6 different operating systems before being able to use classes, a language feature introduced years ago and that still isn't fully supported today.
- solarkraft 8y ago
  The apps you mention are available on the web, so they have to do these exact things anyway. What they really want to do is make that web app installable in the OS, no? I use WebPin to "install" websites (until this works natively in Firefox with PWAs) a lot of the time, even when they offer electron bundles (with the browser I already have, nodejs I already have ...).
- kodablah 8y ago
  I'd consider slack/spotify to be the outliers and I don't think this is targeting them. For the rest of the webdevs that just want to make a web app, Electron is appealing to them too and we shouldn't pretend the only reason they pick it up is browser compat issues.
- ploxiln 8y ago
  I don't consider Slack and Spotify to be good at making applications (despite their popularity). These are the least efficient chat app and least efficient music app ever, in a multi-decade history of chat and music apps, which didn't have the overflowing abundance of convenience and productivity offered by Electron. (This is like the obviously silly quote "we lose money on every sale, but we'll make it up in volume!" translated into "this rich environment and set of libraries enables such amazing developer productivity that we can create much better optimized user experiences!" while the laggyness and flakyness and huge memory use are just never optimized away with that productivity.)
  - zapzupnz 8y ago
    > least efficient chat app ever I dunno, Discord might be gunning for that prize.
  - hn_throwaway_99 8y ago
    > These are the least efficient chat app and least efficient music app ever Which 99% of users never care about. The idea that large memory usage is a negative business driver is almost laughable at this point, yet for some reason it is a huge pet peeve among lots of technologists.
    - hug 8y ago
      They care about it a lot more than you imply, they just don't know that it's something they care about. I partly manage a team of end-user support people, and the number of tickets they get with "my computer is slow!" is astonishing. The number of times it's found that they have Slack eating over half the RAM of their corporate-issued laptop (read: wimpy specs) is huge. The number of people who understand that Slack being an insane resource hog is a large part of what is making their daily computing business painful is the inverse.
    - Erlich_Bachman 8y ago
      Users absolutely care if their app runs slower. Even marginally slower in the order of 1/10 of a second. Even subconsciously users will choose the app that runs faster and smoother, this is why google.com first page is optimized and compressed saving individual bytes sometimes. This is why all big websites use servers all over the world to save 10ms in ping for users which are near them. The only debatable question is whether the exact memory overhead (of electron for example) on the specific user machines existing out there today will make a noticeable loading time or lag difference. For many users it seems it does, not everyone has the lastest hardware.

patr0nus 8y ago

> Nobody wants to be testing against multiple browser/rendering engines in 2019. That's why DeskGap uses EdgeHTML on Windows. With toolchains such as webpack and babel, building an app that runs on WebKit and EdgeHTML (which is going to be replaced by Chromium[0]) can't be that hard. > Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. DeskGap doesn't mean to be a complete replacement for Electron. But after a glance of Electron Apps[1], I suppose many simple apps do not require start-of-art features. [0] https://blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration/ https://blogs.windows.com/windowsexperience/2018/12/06/micro... [1] https://electronjs.org/apps https://electronjs.org/apps

Klonoar 8y ago
Mmmhmm. That's cool, although not original. As I noted in an above comment... https://news.ycombinator.com/item?id=18763449 https://news.ycombinator.com/item?id=18763449 Projects like DeskGap make this out to be a simpler problem than it actually is. ;P
zamalek 8y ago
> That's why DeskGap uses EdgeHTML on Windows Strangely, that would likely make it most conformant on Windows. I can't imagine that KHTML is up to date in terms of specifications (but I could easily be completely wrong about that) and Apple/Safari is taking tips from Microsoft during their IE days. It would seem that the platform differences would be quite large, but at least the JS engine would be consistent.

petecox 8y ago

That would be an argument for Microsoft switching to Chromium, albeit 'Edgium' might not entail the bleeding edge 6 week Chrome release cycle.

kalleboo 8y ago

The Slack dev you're quoting doesn't mention any of your points. His points were that the native extension API was clunky (DeskGap could improve upon this), that users of old OS versions are completely left out in the cold for updates (he mentions severe UI bugs, which is very different from "we need bleeding-edge Chrome features"), and that the difference would be negligible anyway since the poor RAM and CPU usage is from their own garbage JavaScript code anyway, not the browser engine.

pmontra 8y ago
A Slack written with DeskGap wouldn't run on Linux. I'm using Slack in the browser anyway but maybe not supporting Linux could make some software fail compared to a competitor supporting it.

iffycan 8y ago

Also, Electron provides things like single command building, automatic updates and menu bar support (which looks supported in DeskGap).

stonogo 8y ago

Then again, the Slack app segfaulted on launch for months because of a node.js incompatibility with newer glibc. So I guess what you've traded for is - Nobody bothers to be testing against multiple operating systems in 2019. - Everybody gets to wait for Slack to get around to it while the system webview gets the compatibility update almost immediately. Great for the authors, shit for the users. On the bright side, it was the straw that broke the camel's back, and my org doesn't pay Slack any more.

ahartmetz 8y ago
Nice. What did you switch to? I'm watching that space so i can recommend alternatives everywhere I work. Must be F/OSS. Top of the list currently are Rocket.chat and Matrix.
- h1d 8y ago
  Try mattermost
  - ahartmetz 8y ago
    Nah, definitely not Mattermost. It's open core, which is kind of dubious, and not better than Rocket.chat - we switched away from it to Rocket.chat at a previous job.
- stonogo 8y ago
  We switched to IRC. Most of the team uses irccloud, and a handful of us use pidgin or hexchat or the like.

tambourine_man 8y ago

>Nobody wants to be testing against multiple browser/rendering engines in 2019 Nobody does. CSS is pretty mature, a difference in rendering between modern engines is extremely rare

onion2k 8y ago
That just isn't true. You only need to browse caniuse.com for 5 minutes to see there are significant differences between browsers even for mature CSS features. If you want to use anything new it's a minefield.
- lugg 8y ago
  Not sure why your ADHD fuelled shiny seeking is an excuse for the shitshow that is electron. Just don't use new stuff? I'm also unsure how it is even supposed to solve that specific issue considering my laptop is currently running at least two versions of electron for different apps, both of which render text as their primary directive.
  - arvinsim 8y ago
    The parent comment was stipulating that CSS is mature. The reply was that it isn't because there are lots of features that are not available to all browsers. A mature platform would be one where the features are consistent in whatever environment it is in. So in that regard, CSS is not mature. "Just don't use new stuff" is not an excuse.
    - lugg 8y ago
      I never said it was an excuse. I said it was a valid approach, so are polyfills. My issue isn't really with that my issue is that the issues with CSS and the valid workarounds are not painful enough to validate electron as a solution. If electron did what it promised I wouldn't have a problem.
  - kkarakk 8y ago
    just don't differentiate from your competition using new features, instead focus on features users don't value at all - like memory consumption and being browser agnostic

gameswithgo 8y ago

https://azul.rs/ https://azul.rs/

cetra3 8y ago
I think Azul is definitely promising, but it's still alpha level, when I first tried to run it on OSX Mojave I got a nice black screen: https://github.com/maps4print/azul/issues/35 https://github.com/maps4print/azul/issues/35 The next time I ran it, it worked on release mode, but panicked on debug mode. I've just tried again from master and it works, which is an improvement!
- saagarjha 8y ago
  This probably has something to with layer backing (and changes in OpenGL, if they're using it).
- gameswithgo 8y ago
  It was really pleasing to read about this steady progress!
hjhome2000 8y ago
looks very promising
Klonoar 8y ago
These projects are admirable, but people severely underestimate just how much work goes into building a true GUI solution. The insane amount of stuff required to wrap is bonkers-level crazy - you cannot easily match the millions of developer hours poured into the APIs used by MSFT/Apple/Linux, or the sheer complexity of a web browser. You hands-down could not build Slack, Spotify and so forth in a solution like this. You would end up refactoring it very quickly when users start walking away because you can't have a feature they want (playing video, gifs, etc).

eridius 8y ago

Slack migrating to Electron was by far the worst decision they’ve ever made for UX. That one migration introduced a ton of bugs and platform inconsistencies, most of which are still around. One I just complained about the other day is Electron apparently doesn’t handle font fallback properly, so if I type an emoji that Slack doesn’t support, such as [frozen face], it just renders as a placeholder square in desktop Slack even though it renders as the emoji on both the website and in the iOS app. Edit: Apparently HN strips the emoji from the comment [facepalm]

laumars 8y ago
Slack doesn’t pick up my system dictionies correctly so I keep getting American English suggestions for words correctly spelt in GB English. It’s very annoying and I have no idea how to fix it. Wouldn’t have this problem with a native app.
- Klonoar 8y ago
  Having built this kind of thing natively, you actually might! macOS, for instance, has a few race conditions that can (easily) occur when using the built-in spell/grammar-checking functionality on text field/view instances. ...which is exactly the kind of thing that nobody wants to deal with when trying to ship a product. ;P This myth that you get these things for free with native apps is just that: a myth.
  - laumars 8y ago
    > Having built this kind of thing natively As have I :) > you actually might! macOS, for instance, has a few race conditions that can (easily) occur when using the built-in spell/grammar-checking functionality on text field/view instances. That forces it to load the wrong dictionary (one which differs from the system dic) and do so repeatedly each and every time you use the application? That doesn't sound much like a race condition to me... > This myth that you get these things for free with native apps is just that: a myth. Is that actually a myth though? Because I've never heard anyone suggest that - least of all uttered that nonsense myself.

aylmao 8y ago

> Nobody This is like claiming nobody wants to write C because no one wants to manage their own memory in 2019, or miss out on all the cool new packages in the JS ecosystem. Evidently _some people_ do. I can assure you there's at least number _n > 1_ of people who care more about app size than either of your points. I personally wrote a side project in system web-view, because I don't want my macOS-only system-tray application to weigh 115+MB to make sure I have APIs I don't need in platforms I don't support.

toper-centage 8y ago
I mean, fuck the users. Will nobody think of the poor poor developers?
- arcturus17 8y ago
  Never heard a non-programmer user complain about the Spotify or Slack desktop apps, but that’s just me.
  - elcomet 8y ago
    That's because programmers know that it could be much faster if done with native technologies. Non-programmers assume this is normal and now they are used to slow apps. Also, they don't know that the reason their whole system is very slow is slack.
  - chipotle_coyote 8y ago
    I have absolutely heard non-programmer users complain about the Slack desktop app. They may not be able to diagnose why it is being slow or unresponsive, but they can still tell when it's being slow and unresponsive. And while the term "power user" has fallen out of favor, there are still users who aren't programmers, per se, who nonetheless understand concepts like memory and CPU usage.
  - middleload 8y ago
    Maybe you don't listen. "Apps" like Slack are on my hate list even above desktop Java apps. Seriously, I can't understand how come it's acceptable to use >1GB of RAM to display 10 lines of text.

mch82 8y ago

> Nobody wants to be testing against multiple browser/rendering engines in 2019 Yes, lots of projects want multiple, competitive rendering engines. It used to be that Windows was the only viable target OS for commercial software. Firefox and Safari gave IE competition and gave developers who wanted to target Mac and Linux a way to get a foot in the door. That kicked off the whole generation of web apps we’ve just lived through. If developers give up on Gecko and WebKit, then they allow a monopoly again. And since Electron is made by GitHub and is now owned by Microsoft, Microsoft will again have the monopoly (with the caveat that Google has primary influence over Blink). Render engine competition keeps web standards relevant, which keeps the web open. Take away competition & we’ll be back in a world where people build to IE6 for a decade instead of targeting standard HTML/CSS/JS.

EGreg 8y ago
I’m going to disagree. Over the two decades I have been programming I have come to appreciate the benefit of Open Source Collaboration vs competition. Competition between platforms is good, but it’s not the best. Because those who produce content waste millions of hours collectively trying to address every little quirky difference between the platforms. And the standards only help so much, whether it’s POSIX or WHATWG. The real reason MS and IE were not so good is because they were a closed source monopoly! And moreover the copyright was enforced by the government. Now even M$ switched over to WebKit / Blink. Collaboration beats competition in the end. Wikipedia beat Britannica quite handily. And it beat Encarta, too. Open source beat closed source over time. The Web beat AOL and Compuserve. Science beat secret cults and alchemy. Today Pharma is using patents and competition. People are prevented from building on each other’s work in microbiology but not in other sciences. Isn’t that wild? I would rather have lots of people adding to one snowball platform, than having competing platforms. AS LONG AS that platform is open source and anyone can use it for any purpose. If your commits don’t make it into the core, just market them until they get popular enough. Compatibility is the goal, though.
- gpvos 8y ago
  Chrome/Blink may be open source, but it's controlled by Google after Blink forked from WebKit. It's hardly collaborative.

finchisko 8y ago

I want small app package. By not bundling webview, deskgap looks perfect to me.

EGreg 8y ago

I wonder how all those commenters from HN who always say “we should have more competition in the brower engines” feel about your sentiment.

pjmlp 8y ago

Right on, this generation has no right to complain about IE only web sites. /s

Klonoar 8y ago
IE only websites was an issue when the engines were closed source and intentionally held back. We're well past that point with modern browser engines.
- pjmlp 8y ago
  Yeah right, Chromium is not the same thing as Chrome.

CyberDildonics 8y ago

Doesn't anyone who makes a webpage need to test it in different browsers?

Klonoar 8y ago
This is a thing that's really specific to web-design, though. People writing desktop apps want it to "just work", which is why Electron is a godsend (in this regard).
- CyberDildonics 8y ago
  Why do people not think that cross platform GUIs don't 'just work'? The effort to get something that already works to another platform really isn't much. Also electron doesn't 'just work'. A simple program being 300MB with a laggy sluggish interface is not 'just working'.

maaaats 8y ago

> Blows my mind we're still debating this. Maybe you should consider that a sign that it's not as black&white as you tout it to be? I mean, what a way to just dismiss everything..

ionised 8y ago
Should we consider the anti-vax movment as a sign that all is not black and white with vaccines? Of course not. Just because people are still having the conversation it doesn't mean the conversation is worthwhile.
Klonoar 8y ago
I'm dismissing it because the collective energy wasted on people complaining about Electron's rise is getting really old. Until a native environment offers feature-parity with Electron, the discussion won't change, and the sooner people start paying attention to that the better. So yeah, it's pretty black and white. ;P

microcolonel 8y ago

> Nobody wants to be testing against multiple browser/rendering engines in 2019. Soon they'll all be WebKit or Chromium.

h1d 8y ago
And where does Firefox go?
- pawelmurias 8y ago
  graveyard

laumars 8y ago

I get that writing tests often isn’t fun but it’s as much a part of responsible development as writing useful error messages and not using experimental features on production builds. What really blows my mind is that we’ve reached a point in computing where the developers laziness now outranks the customers needs. > Since I can already see the litany of armchair-quarterback-desktop-app-authors I think you’ll find those who are offering counter arguments aren’t just armchair critics. Eg I’ve been writing software since the 80s. This includes a considerable amount of desktop software. So I’d like to think my opinion is just as valid as your own. ;)

Klonoar 8y ago
I'm actually wading back into the comments here for this specific comment, because it's ridiculous. It's not developer laziness. This is 100% a business decision, and if you've been doing this since the 80s, I'd expect you to know this by now. Do you really think Slack & co chose Electron because it's making developers lives easier? Companies and people choose it because it. just. works. across platforms. This has a direct translation to money, no matter how much you stick your head in the sand about it. Less resources, less platform-specific wizardry, more focus on core features with faster turnaround time. _That_ is all that matters here at the end of the day, because programming is not - nor has been, for the majority of roles, for some time - been about coding and tinkering with bits. It's about increasing revenue for the company/product/whatever. When you (the general you, not you specifically) rant about reimplementing everything Electron gives you on three platforms, you gloss over the wealth of shit a web browser provides for free. I have actually implemented some of this stuff outside of a browser, and I wouldn't do it again if you were paying me. _Furthermore_, very rarely does anyone compare implementing something via Electron to native... but native is a landmine-filled problem area of it's own. macOS alone is horrendously undocumented these days for a good portion of stuff, and you'll end up with a litany of platform specific hacks for the most basic things. Hell, the easiest response to this comment is this: neither of our opinions needs to be valid, because the market's opinion is that Electron is the better choice.
- laumars 8y ago
  I do get that point of view but there are as many exceptions to that rule as there are examples. Take mobile app development: half the products that run on Electron on the desktop will still have native apps on mobiles. And even those that don’t would still have to use the native renderer on iOS and Windows Phone thus you’d be testing your common code base across multiple rendering engines anyway (which was the argument against the tool in this discussion).... and I’ve not even meantioned the slew of cross-platform applications that exist which have successfully avoided using Electron. There are quite a few cross platform frameworks out there these days and different languages that can leverage them, however the next point I think is the real crux of the problem: I will grant you that Electron does lower the barrier for entry (which is ironic because I personally find the web stack more awkward to develop in than native widgets - but each to their own). And maybe that’s where the biggest cost saving comes for the business; you can hire cheaper engineers to build and support your desktop software? In any case, I’m not blind to the appeal of Electron; I just don’t agree with how important it is in the same way as the GP does.

zaarn 8y ago

These two "nobody" reasons is why we are tettering on the edge of a browser monopoly, which will likely hurt desktop apps too if they use electron.

Klonoar 8y ago
Monopoly = IE6, closed source, controlling the web. Monopoly != multiple large vendors contributing to Chrome/Webkit/etc.
- zaarn 8y ago
  Chromium is still only a single engine under majority control by Google. Almost noone else contributing to Chromium does enough that they could maintain the engine as a fork indefinitely.

blauditore 8y ago

> Nobody wants to be testing against multiple browser/rendering engines in 2019 You mean like when building websites?

boffinism 8y ago
I build websites, and I don't want to be testing against multiple browser/rendering engines. I do it cos I have to, not for the hell of it.
- hawski 8y ago
  I and most people work, because to not starve we have to, not for the hell of it. So the original statement is truism. Nobody wants to do the hard work in 2019.
  - Klonoar 8y ago
    It's not "hard work", it's monotonous and not worth the time. When even Microsoft realizes that, there's possibly some truth to it.

atoav 8y ago

As somebody who deals with HTML and CSS often I like the idea to be able to use these layout skills in a desktop GUI. But size and speed matter (you don’t see much elektron based games..). We as a humanity can’t just always build faster and more powerful computers and then let developers throw these gains away by building more elaborate Rube-Goldberg-machines, that take 100 times the space they need, running more things taking the same old time we are used to wait, with dependencies no single human ever checked at once. Many of same people who waste tremendous amounts of energy and collective human time writing ineffective applications might end up to be really pro-environmentalists outside their job, but when it comes to computers suddenly we don’t care. As long as it is acceptable on a new machine, who cares, right? It would be entirely possible to write perfectly fast and efficient GUI applications using HTML and CSS as layout engines without dragging whole browsers into this. Using system webview might not be the solution. But maybe something that doesn’t feel like it has been taped together with duct tape would help. A fully fleged browser engine for a desktop app is overkill in most common usecases and while I understand why one decides for Elektron, I’d rather see a really thought out solution than one that has been duct taped together.

arvinsim 8y ago
> Many of same people who waste tremendous amounts of energy and collective human time writing ineffective applications might end up to be really pro-environmentalists outside their job, but when it comes to computers suddenly we don’t care. As long as it is acceptable on a new machine, who cares, right? This is such a privileged thing to say. I would guess there are far more important environmental problems to worry about. There are also more things that can be done that have more impact. > It would be entirely possible to write perfectly fast and efficient GUI applications using HTML and CSS as layout engines without dragging whole browsers into this. Using system webview might not be the solution. But maybe something that doesn’t feel like it has been taped together with duct tape would help. A fully fleged browser engine for a desktop app is overkill in most common usecases and while I understand why one decides for Elektron, I’d rather see a really thought out solution than one that has been duct taped together. Convince platform owners to agree on a common spec for GUI that's implemented consistently. Otherwise, what you want will ever remain a pipe dream.

darkblackcorner 8y ago

> Nobody wants to be testing against multiple browser/rendering engines in 2019 If you don't want to test multiple (browsers) ANYTHING, you shouldn't be a (web) developer. Seriously, this is why we still have sites that only work in IE.

_pmf_ 8y ago

> Since I can already see the litany of armchair-quarterback-desktop-app-authors I'm so very sorry our 20 years of experience that causes us to reject the subpar monstrosities you like to call "dektop apps" rubs you the wrong way.

Klonoar 8y ago
20 years of dev experience, yet people stick their head in the sand when the topic switches to why Electron is so successful. ;P So yeah, it does rub me the wrong way. The people who argue against Electron are the programmer's programmer: they like tinkering, they care about the code, and so on. Most businesses don't. Users never see the code. If you want better, you need to beat Electron and stop ignoring or decrying why people opt for it.

josteink 8y ago

> Nobody wants to be testing against multiple browser/rendering engines in 2019. Speak for yourself. I hate to break it to you, but in the real world there are multiple browsers. Not testing in more than one is lazy, standards ignorant and an insult to your users. Let’s not repeat the MSIE-fiasco again. We know better. We can do better.

Klonoar 8y ago
>Not testing in more than one is lazy, standards ignorant and an insult to your users. Slack et al are more successful with users, and have delivered more value to them, than 99% of the work people who post here are doing. Pretty sure this isn't insulting them. And for the last time, this isn't the MSIE-fiasco all over again. The primary engines used today are all open sourced, it's not vendor lock in on the level it used to be.