Live data from Hacker News

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

deskgap.com

241–250 of 268 posts

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

#241
post #72
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…

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

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

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

#242
post #59
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…

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

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.

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

#243
post #134

Earlier quoted context omitted.

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.

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.

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.

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

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

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

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

#245
post #93

Earlier quoted context omitted.

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.

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.

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

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

#246
post #151
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…

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

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.

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

#247
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…

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

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

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

#248
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/

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

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

#249

Earlier quoted context omitted.

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.

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

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

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

#250

Earlier quoted context omitted.

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…

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

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.

Post reply on HN