[Klonoar]

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

Blows my mind we're still debating this.

[aylmao]

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

[fermienrico]

No need to go too far to find an example: Sublime Text and Sublime Merge.

While this route is probably not for quick app deployment, but boy can it kick ass when properly done in C++ with custom GUI framework.

I love Sublime Text and Sublime Merge. I love their philosophy towards software design. I love how they value user experience above everything else.

There are very few pieces of software that give you so much pleasure and joy in using them on a day to day basis.

[jayflux]

Yet so many still migrate to VSCode which is electron based. So maybe the difference you value isn’t valued enough to be worth it for most authors.

I get the point you’re making, but you might be in the minority here.

[pofjer]

Citation needed. How many exactly?

[Kovah]

You are comparing apples with pears. Sublime can't be compared to VS Code because the former is basically an advanced editor while the latter is an IDE (like PhpStorm or Atom).

And I highly doubt that many users switching from Sublime to VS Code. They use one or the other for a specific reason, like a blazing fast and distraction free editing experience in Sublime - something you do not have in VS Code or any other IDE, imo.

[wilsonnb3]

The line between advanced text editor and lightweight IDE is basically non existent.

Plenty of former sublime users are on VS code now.

[GordonS]

I use VSCode for programming (Typescript), but it's also become a great replacement for my usual native text editor (Notepad2). I love how performant yet, feature-packed and extensible it is, and since I keep my notes in Markdown format, the `yzhang.markdown-all-in-one` extension is really useful.

[pofjer]

So? Plenty of former VScode users are on Sublime, Vim or Emacs now.

I really don't get your point.

[horse-cuddler]

This is a bit of a surprising thing for me to hear, because I found Sublime Text's user experience to be rather poor, and certainly inferior to its Electron-based competitor VS Code.

[macleginn]

I would never say “poor”, although I found myself moving from Sublime Text to VS Code for most of my projects. However, ST is undeniably so much faster. If I need to edit large files or do something quickly, I am happy that I can use it.

[O_H_E]

Have you tried searching commands with the "command Palette". It makes everything discoverable for me. I personally LOVE the UX

[O_H_E]

Sublime feels like a marriage between TUI & GUI. * Everything is controllable by keyboard * Mouse based menus for one-time usage * Command Palette is awesome and very useful * FAST * Scriptable

Really hope they can keep being profitable.

[Fnoord]

fman (fman.io) for a dual pane file manager. Utilizing Qt, proprietary, cross platform, and follows the design philosophy of Sublime Text.

[toper-centage]

I mean, fuck the users. Will nobody think of the poor poor developers?

[arcturus17]

Never heard a non-programmer user complain about the Spotify or Slack desktop apps, but that’s just me.

[chipotle_coyote]

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.

[jcelerier]

non-programmer users don't complain because they don't know how bad they are fucked.

A few weeks ago my non-technical neighbours told me that their computer was "a bit slow" and if I could "install a new antivirus". Here's what "a bit slow" meant :

- windows took 7 minutes to boot

- IE took more than a minute to open

And of course it wasn't always like that, but the proverbial frog was boiled long enough that it took a lot of time for them to be pissed enough to look for help (the poor guys had 4 antivirus programs running concurrently - on a machine with 2 gigs of ram).

In contrast, if my browser takes more than 3 or so seconds to open I start looking for what's wrong.

[O_H_E]

Horror. 4 antivirus programs in 2G RAM

That makes me think of what school and uni digital illiteracy should look like.

[jcelerier]

given that the aforementioned neighbors are more than 60 years old I don't think you can really blame school and university

[elcomet]

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.

[middleload]

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.

[cotelletta]

It's easy. The text is marked up, mixed in with images, video and other miscellaneous rich content, and includes remote resources and third party embeds.

There is no native UI toolkit that can do this properly, nor is there a cross platform way for 3rd parties to integrate even if there was. So web it is, with a runtime designed for being able to rapidly page in/out the entire UI from one screen to the next, even if that is entirely unnecessary for a single app.

Grouches have been shitting on the web, not entirely for bad reasons, but it's made them miss the fact that web has been stealing their lunch for a reason. If you live inside a terminal, your needs have diverged from the majority, and you're likely relying on crutches that are considered impossibly clunky by most.

The only ray of hope here is what FB has done with React and React Native, but I imagine it will take another 10 years before the unix geeks will want to admit there is something in that "webshit" worth looking at.

[stephenr]

macOS Messages (aka iMessage) has been rendering text chat using HTML views for years, and it doesn't use gobs of memory.

The problem isn't that the text part is rendered using HTML. That actually makes sense - multiple desktop applications that compose/render user generated rich content rely on HTML (or something converted to HTML) and a web view of some description to render that content: mail, chat, etc.

The problem is rendering the entire application's chrome using Web technologies, and then running all of that inside a web view from a browser that is known to have the resource usage of a porcine creature with an eating disorder.

> The only ray of hope here is what FB has done with React and React Native

No. The ray of hope is that people realise web technologies are not the best choice, and the way they're used in Electron is fucking atrocious.

[stephenr]

Exactly.

I refuse to use Electron apps - they clearly work in JS so the web version will work fine, and I get to keep the sandbox protections, content blocking etc of Safari.

And I use IDEA Ultimate almost daily. Yes, it uses a ton of RAM - but it uses a ton of RAM and is powerful.

I've not yet seen another IDE with the same capabilities (i.e. built in static analysis of dynamic languages like PHP, with refactoring support, etc).

I have oodles of memory (64GB) so I could of course run Slack and not "run out". But the key thing here is that Slack doesn't just use memory, it wastes it.

IDEA uses memory to make me more productive

[ahartmetz]

Why would you even use the slack "app"? I don't like Slack but I have to use it, so I open it in a browser tab. Same crap, less memory use.

[sagartewari01]

What do you think about intellij platform?

[tomc1985]

Spotify I can understand but Slack's client is hot garbage. Discord has more features and crashes less...

[ionised]

Which is a shame, because they are both awful.

[hitekker]

It is unfortunate that this unsaid sentiment has pervaded all the engineering organizations I've worked for... except the one that made software for developers. Funny that.

[icelancer]

It's not that difficult. You ship products to specific usergroups and don't need to exceed their tolerances. That 5% of users really hate Electron - or even know what it is - simply just doesn't matter to Slack.

And besides, of that 5% of people who hate it, a large percentage of them use it anyway because they have to.

Overengineered products for the minority don't do well unless you charge a huge premium for it, something my field unfortunately does a lot of and I have to deal with.

[Mikhail_Edoshin]

Developers are users too.

[mch82]

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

[vedantroy]

The point is that developers don't want to be testing against multiple browser/rendering engines--hence why Electron was built.

Maybe having multiple engines is good (although maybe the benefits are overstated since nowadays most engines align with the spec instead of implementing non-standard extensions like ActiveX), but it's not good for people for who want to quickly, and with low effort, develop desktop applications.

The point of the parent comment was that developers chose Electron over other frameworks for reasons such as speed of development, and DeskGap does not align with those reasons.

[kijin]

What developers want is important, but what users want is even more important. If a lightweight app is what users want, that's a good enough reason for at least some companies to consider DeskGap over Electron.

I'm sick of sluggish "native" apps on my i7 PC with fast SSDs and 32GB of RAM. I don't even want to imagine how those apps perform on low-end devices.

[icelancer]

> but what users want is even more important

Only developers and very tech-savvy people bitch about Slack. Your average person working in Sales, HR, or operations cares not for the memory footprint of Slack.

It's also not nearly as bad as people make it out to be. Yeah, it's slower than mIRC, fair enough. But IRC is dead to almost everyone and Slack took over, so it is what it is.

[saagarjha]

They do, but they misdiagnose it as "my computer is slow" or normalize it because that's all they're used to.

[arvinsim]

Anecdata but I never heard of that complaint for people I know that use Slack.

Maybe the circle I am in simply has great computers. But who knows.

[dmitriid]

Users don’t want a “lightweight app”. Users want an app with <a list of features>.

[arvinsim]

Exactly. If users are held at gunpoint and have to choose between a fast app and a feature rich app, I would bet they will choose the latter.

[userbinator]

Given what counts as "feature rich" these days (and it seems some developers are constantly removing things that users used to use), I doubt that.

Software used to be both fast and "feature rich" (relatively speaking), designed so users could "grow" and learn increasingly more of it. Now almost everything seems to have idiotically dumbed-down "flat" UIs that look simpler yet still manage to consume more resources than before.

The new Skype is a great example. Compare to something like this: https://www.microsip.org/ Yes, I know they're different protocols, but the point is that IM and audio/video call functionality doesn't need to take as much resources as Skype does.

[jhgg]

The cost savings here is in download/package size, and not runtime performance. Chances are latest chromium is faster than the system web-browser.

[kijin]

Startup time matters. Chances are the system web browser is already cached in memory, whereas every Electron app wants to load its own Chromium runtime.

[EGreg]

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]

Chrome/Blink may be open source, but it's controlled by Google after Blink forked from WebKit. It's hardly collaborative.

[aaronbrethorst]

“M$”? Really? This isn’t slashdot.

[arvinsim]

It's good that you are advocating for render engine competition. But I think you think you are getting off tangent.

It has nothing to do with the point that trying to make your code work in multiple browsers/rendering engines is painful.

Wanting a project to work with multiple rendering engines just because is an idealogical decision.

[gpvos]

All software is political, so ideology is relevant.

[kkarakk]

The political ideology in play for the majority of software development is capitalism so we loop back to "if i can't get it done asap using this tool, i'm not going to use this tool"

[ahartmetz]

Externalities matter even in capitalism.

[kalleboo]

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]

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.

[Octoth0rpe]

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

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.

[ploxiln]

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]

> least efficient chat app ever

I dunno, Discord might be gunning for that prize.

[icelancer]

Do you find it weird that you think these are the least efficient apps in their domain and yet they are both extremely popular with the majority of users out there?

[saagarjha]

Music and chat apps have an extremely high barrier to entry, which makes it quite difficult for others to compete.

[hn_throwaway_99]

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

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.

[ubercow13]

Have you never had a non-technical person ask you to help because their PC is slow? Non-technical people care, they just don't know how much better it could be for them. They understand that their PCs are slow, and they understand how to close apps they aren't using to stop the computer slowing down. This habit even transferred over to phones where developers had to teach people that it's not necessary to habitually swipe background apps closed any more, because they were so used to doing it.

[Erlich_Bachman]

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.

[intertextuality]

This is a completely arrogant view of users.

People quite obviously care about speed and latency issues, but they might not be able to pinpoint slack or discord, etc as the root cause.

[CyberDildonics]

People care about latency and sluggish interfaces on their brand new PC.

[Octoth0rpe]

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.

[ehnto]

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.

[Klonoar]

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

[solarkraft]

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]

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.

[stonogo]

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]

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.

[stonogo]

We switched to IRC. Most of the team uses irccloud, and a handful of us use pidgin or hexchat or the like.

[h1d]

Try mattermost

[ahartmetz]

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.

[atoav]

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]

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

[patr0nus]

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

[1] https://electronjs.org/apps

[zamalek]

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

[Klonoar]

Mmmhmm. That's cool, although not original.

As I noted in an above comment...

https://news.ycombinator.com/item?id=18763449

Projects like DeskGap make this out to be a simpler problem than it actually is. ;P

[laumars]

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]

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]

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.

[Klonoar]

Eh, no - nowadays most Electron-based apps would opt for a React Native app on iOS, so they can reuse most of the JS logic from their web counterparts. The big players (Slack, Spotify, etc) will introduce native things because it makes sense to, but there's no reason the small players will do this.

Multiple rendering engines in this case also makes sense because the form factor you're designing for is inherently different. As a result, the usability factor comes into play... you're never writing one UI at that point anyway. The point of Electron is that you turn building and testing 3 rendering engines into testing 1.

[saagarjha]

> Less resources, less platform-specific wizardry, more focus on core features with faster turnaround time.

Where can I request the "core features" of performance and usability?

[Klonoar]

You and I have done this specific dance many times, in case you haven't realized. You've failed to convince me that native wins on this for most devs... we've gone pretty in-depth on this before re: macOS, too. ;P

[eridius]

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]

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]

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]

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

[Klonoar]

I've had it load the wrong dictionary, surprisingly, yeah (I keep en-us and en-jp handy). It's a classic case of Apple abandoning macOS like they have for multiple releases now. ;P

There are bugs for NSSpellChecker going back as far as 2009 regarding automatic language detection (they're, however, now annoying as piss to link to... because all the old mailing lists/archives have been seemingly nuked. Thanks, Cocoa community!). This in turn hits Electron apps, since they're just passing back to the native API anyway.

https://github.com/electron-userland/electron-spellchecker/i...

[laumars]

Fair enough.

For reference I was referring to Linux where Chromium and my DE all have their dictionaries set up correctly. I only ever seem to have this problem with Electron apps too. It's very annoying though.

[zaarn]

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]

Monopoly = IE6, closed source, controlling the web.

Monopoly != multiple large vendors contributing to Chrome/Webkit/etc.

[zaarn]

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.

[gameswithgo]

https://azul.rs/

[cetra3]

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

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]

This probably has something to with layer backing (and changes in OpenGL, if they're using it).

[gameswithgo]

It was really pleasing to read about this steady progress!

[Klonoar]

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

[hjhome2000]

looks very promising

[maaaats]

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

[Klonoar]

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

[_khau]

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.

[iffycan]

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

[pjmlp]

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

[Klonoar]

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]

Yeah right, Chromium is not the same thing as Chrome.

[blauditore]

> Nobody wants to be testing against multiple browser/rendering engines in 2019

You mean like when building websites?

[boffinism]

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]

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]

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.

[josteink]

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

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

[_pmf_]

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

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.

[finchisko]

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

[petecox]

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

[microcolonel]

> Nobody wants to be testing against multiple browser/rendering engines in 2019.

Soon they'll all be WebKit or Chromium.

[h1d]

And where does Firefox go?

[pawelmurias]

graveyard

[CyberDildonics]

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

[Klonoar]

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]

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

[EGreg]

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

[tambourine_man]

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

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.

[tambourine_man]

>If you want to use anything new it's a minefield.

That’s true with any platform. But if you stick with tried and true stuff, it’s hassle free.

I don’t remember the last time I had a layout rendering issue and I write this stuff everyday all day.

[lugg]

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]

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]

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]

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