Live data from Hacker News

Show HN: DeskGap – Like Electron, but uses the system webview

deskgap.com

31–40 of 268 posts

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#31
post #28
post #7

Earlier quoted context omitted.

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.

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!…

> least efficient chat app ever

I dunno, Discord might be gunning for that prize.

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#32
post #5

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…

>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

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#33
post #5

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…

https://azul.rs/

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#34
post #5

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…

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]

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#36
post #5

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…

https://azul.rs/

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!

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#37

I find it amusing that the opening paragraph describes it as a "framework for building cross-platform desktop apps" and then shortly below that in the "Supported Platforms" section it lists one Mac OS and one very specific version of Windows. No Linux at all. Even native Windows apps are more cross-platform than that! (I have written a few which will work on any version of Windows starting at Win95...)

[deleted]

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#38
post #5

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…

https://azul.rs/

looks very promising

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#39
post #5

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…

>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

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.

Re: Show HN: DeskGap – Like Electron, but uses the system webview

#40
There was about a year and a half worth of security work done on Electron (particularly targeting the Node integration and how Node APIs were exposed). I worry that not a lot of people know just how insecure Electron apps used to be, and would generally worry that new Electron frameworks not designed specifically to be secure are going to recapitulate a lot of that.
Post reply on HN