The Grim GUI Landscape

The Grim GUI Landscape(jazzfool.github.io)

2 points by jazzfool 4 years ago | 5 comments

mimixco 4 years ago |

It doesn't really matter if Electron has code you won't use. So does your TV, your car, and your fuzzy logic rice cooker.

The OP dismisses with prejudice the only reason Electron exists or is so popular: it saves dev time and lets people build desktop apps with skills they already have. The same app will work as a website or SaaS with no code changes.

Putting Flutter or XAML up against the advantage of your whole team already knowing the platform (HTML/TS/JS/CSS) makes those newcomers non starters.

jazzfool 4 years ago | |

> It doesn't really matter if Electron has code you won't use.

It does matter very much when it negatively impacts your application's performance and user experience.

I definitely didn't dismiss the benefits Electron provides, in fact I completely acknowledge those benefits. The thing is, those benefits don't have to be exclusive to an unsuitable platform like Electron. What's stopping us from bringing that developer productivity to a desktop platform?

This post mostly focuses on app development for independent developers. However, these points are exaggerated even further for entire teams and companies where you actually have the time and resources to invest into the appropriate technologies instead of forcefully trying to reframe every development problem into a web problem (if all you have is a hammer...).

mimixco 4 years ago | | |

It couldn't be less of "everything is a hammer." We had native apps before Electron. It was developed and people choose it because it saves time and utilizes skills they already have. Like another poster, I smell management-style disdain for devs here.

The web won because worse is better. Is electron an "inappropriate tech" for Slack? Is (another web wrapper) wrong for Spotify? Those were conscious choices, made on purpose.

rektide 4 years ago |

this attitude the author uses, that tech is only valid if used for some scenarios but not others, is quite scary to me. adopting an anti-flexible, narrow view of prospective uses is against the free form, ingenuitous, creative spirit that I hope tech can embrace. these days though I feel like a really radically conservative outlook is on the rise, that doubt & mistrust & denial are selling strong. and, as usual, it's scary inuendo & dogpiling that makes the case, not numbers or specific contentions:

> Think of the thousands of security patches and workarounds, the intricate DOM optimizations, the multi-webpage inter-process resource sharing. None of that will benefit an Electron app and will only slow it down.

meh. I don't think there's much to worry about here author. I think there's more to gain by having a well tread, versatile, robustly optimized, secure platfo underfoot. and I don't believe your claim that this comes at some great speed cost.

> To put it shortly, you’re misusing the software.

nahhhhhhh. you just have weird hang ups dude. chill.

I do really appreciate them acknoding that devs like the development environment. the declarative model is really good (although react & many others murky this assertion).

react-native to me seems like a natural continuance of this idea, of giving the devs what they know and want. I'm unsure why it hasn't succeeded more, but it's so always felt like it was kind of sticky, that there were long cimixated fights with the many underlying is layers & that in general native platform boggery set in. electron continues to offer that great web native platform plus well known cross-os node platform, and trying to beat that is exceedingly hard.

krapp 4 years ago |

I'm waiting for SDL to get around to merging the PR that opens up a rendering API[0], which should make writing native cross-platform GUIs a lot easier. Currently something like Dear ImGUI does work with SDL but only if you use OpenGL. I can imagine (maybe even write, if I feel like a masochist) a lightweight GUI library that uses QML like syntax in Lua.

[0]https://github.com/libsdl-org/SDL/pull/4195