The main problem that everyone has with electron is the RAM consumption right?! If the webviews are anyway gonna increase the RAM to electron levels while being significantly hard to test and deploy then this will not work out ever. I'm only bothered about low RAM memory usage not the disk space.
Show HN: DeskGap – Like Electron, but uses the system webview
91–100 of 268 posts
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#92Earlier 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!…
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?
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#93These 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 Sl…
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.
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#94I've seen a day ago a recording of a presentation from last week FOSDEM where two other libraries, Lorca[0] (Go + HTML5) and Webview[1] (C++/C/Go), were described that are similar in scope to this one.
From the webview project page: It supports two-way JavaScript bindings (to call JavaScript from C/C++/Go and to call C/C++/Go from JavaScript). It uses Cocoa/WebKit on macOS, gtk-webkit2 on Linux and MSHTML (IE10/11) on Windows.
[0]https://github.com/zserge/lorca
[1]https://github.com/zserge/webview
edit: the link to the video https://video.fosdem.org/2019/UD2.120/godesktopapps.webm
and the presentation slides https://fosdem.org/2019/schedule/event/godesktopapps/attachm...
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#95Earlier quoted context omitted.
I mean, fuck the users. Will nobody think of the poor poor developers?
Never heard a non-programmer user complain about the Spotify or Slack desktop apps, but that’s just me.
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.
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#96The main problem that everyone has with electron is the RAM consumption right?! If the webviews are anyway gonna increase the RAM to electron levels while being significantly hard to test and deploy then this will not work out ever. I'm only bothered about low RAM memory usage not the disk space.
A simple hello world style app in electron and in my own project [1] show electron using ~100mb while the webview based project ~50mb, so there's that.
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#97These 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…
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.
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#98Earlier quoted context omitted.
I mean, fuck the users. Will nobody think of the poor poor developers?
Never heard a non-programmer user complain about the Spotify or Slack desktop apps, but that’s just me.
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.
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#99Earlier quoted context omitted.
> 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 a…
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 p…
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.
Re: Show HN: DeskGap – Like Electron, but uses the system webview
#100These 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…
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 tho…
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.