Electron considered harmful
71–80 of 256 posts
Re: Electron considered harmful
#72Re: Electron considered harmful
#73I can understand the author's frustration with popular tools being very simple and somewhat overkill underneath, but I almost take it as a sense of frustration with himself. Electron was built to ship products as soon as possible. Most of the time, no one gives a flying fuck if the tech stack is the "right" choice and as efficient as it can be. I'd be willing to bet my net worth your users don't care at all how you b…
> I'd be willing to bet my net worth your users don't care at all how you built it, just that it does what they want it to do. That's exactly right, except "what I want it to do" is not use up all my RAM.
Re: Electron considered harmful
#74Native is only an option if you want to rebuild your app UI from scratch a minimum of twice and never support Linux or other less common desktops.
UI development has always been in fragmentation hell.
Re: Electron considered harmful
#75See, I totally agree with this essay. But what are the alternatives? Getting started with Qt/GTK isn't nearly as easy, for example. Maybe someone should write an intro to native GUI programming for JS devs.
TTK. It's got bindings in pretty much every language (because it's TK), but unlike plain-old TK, it doesn't look like absolute garbage, and instead takes on a vaguely native appearance on each platform.
Re: Electron considered harmful
#76> For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU, you get a less capable GUI that saves you from having to type the -ss and -t flags yourself. Cool. I remember when Handbrake first came out, and 'make video go on iPod' went from some long winder research into ffmpeg flags to clicking a button that says 'output for iPod' [1]. This sounds similarly timesaving. [1]. ye…
That was, what, 9 years ago? I realize it's an eternity in the average JS framework lifecycle timeframe, but come on.
Re: Electron considered harmful
#77This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entire browser inside. But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. The fact is, for many types of applications,…
> It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. Using the date as an argument is also poor form. JS is a terrible programming language (I'm not denying that it is a programming language though) regardless of how popular it is (although I think I might be going against the grain here on HN, many people her…
[Citation needed]
Sorry, JavaScript may have gotten lucky being the lingua franca of the web, and it might not be perfect or even great, but it's "good enough" for most purposes these days.
If it were "terrible" you would expect at least one compile-to-JS [1] to have gained a non-trivial amount of traction by now. The supersets of JavaScript like Babel, TypeScript, and Flow are more popular than "not terrible" languages like ClojureScript, Elm, etc.
1. https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
Re: Electron considered harmful
#78Earlier quoted context omitted.
What are your problems with Qt? I was using PyQt, and I found it nice (Qt's integration is good).
I was using C++ Qt. Just found it really unintuitive and difficult to use compared to web technologies and native macOS development.
Re: Electron considered harmful
#79Earlier quoted context omitted.
> It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. Using the date as an argument is also poor form. JS is a terrible programming language (I'm not denying that it is a programming language though) regardless of how popular it is (although I think I might be going against the grain here on HN, many people her…
JS is a terrible programming language I can never see the point of comments like these. Not one person who reads that will have his mind changed. HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer. No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refus…
> I can never see the point of comments like these.
At minimum, I think the hope is that js-only programmers become aware that there are alternatives. And hear that the people who use those alternatives often find them better.
Re: Electron considered harmful
#80This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entire browser inside. But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. The fact is, for many types of applications,…
> It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. Using the date as an argument is also poor form. JS is a terrible programming language (I'm not denying that it is a programming language though) regardless of how popular it is (although I think I might be going against the grain here on HN, many people her…
The very same can be said about people looking down on Electron. Most of them can't write decent native apps to begin with.
I used all of win32, Qt, GTK, wx and Cocoa to name but a few. They all suck in one way or another. Suggesting people are poor native developers for refusing to learn these frameworks completely disregards the fact that most people using these frameworks are bad developers to begin with.
For the average application going native will easily triple your development time and costs for absolutely no noticeable performance difference.
> If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then?
What if the only difference between the web and desktop apps are that the desktop app can open local files while the web app downloads them? Are you going to write two apps in that case? This would be a mediocre economical choice at best as you're more than doubling the production costs for a difference nobody is going to care about.