Live data from Hacker News

Electron considered harmful

drewdevault.com

231–240 of 256 posts

Re: Electron considered harmful

#231
post #108

Earlier quoted context omitted.

The arrogance in it, though, is that because people who like JS are "obviously" wrong, the reason must be that they don't know (enough) other programming languages or don't know them well enough. I have used a number of different programming languages before JS, a couple of them more extensively and for a longer time than JS. I like JS. I understand its flaws. I also understand that all programming languages are terr…

First, X-only programmers are obviously wrong, whatever is the value of X. That said, yes, somebody ought to love JS in a not blind way. Big numbers work that way. If that's you, I don't think those comments are for you. All languages have different flaws, every flaw relevance varies by context, and contexts are incredibly subjective. Yet, some contexts are much more common than others, and many people preach in supp…

You'd be surprised how many people I've met that enjoy JavaScript. Nearly everyone I've met that hates JavaScript either didn't bother to learn it ("It's just a scripting language") or is just upset that they can't use their favourite programming language all the time (this is how we ended up with CoffeeScript, Sass and Haml and why everything in the Java world is eventually wrapped in XML).

I've seen enough different use cases and teams and programming languages to understand there's no point in being arrogant about language choice: if a team already knows a given language, it is most likely the right tool for the task, unless the benefits of replacing it are worth the overhead of properly switching to and gaining competence in another language.

Re: Electron considered harmful

#232

Earlier quoted context omitted.

But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.

> Yes - electron apps are slower and eat more ram - but someone else is paying for that. I hope you're being facetious here. If you develop any kind of desktop application and truly believe this, honestly this is disappointing to read.

Doing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours. If people are willing to pay for those extra P hours then I'd be more than happy to do things the 'right' way. However almost nobody is.

I've spent a lot of time on team web-apps-suck, and in many ways I'm still a casual fan. But the truth is I can go from zero to good enough much faster with web apps than anything else, and unfortunately most people only want to pay for good enough.

Re: Electron considered harmful

#233

Earlier quoted context omitted.

Downvoted; this question can easily be answered via a search engine.

Downvoted. It's generally considered rude to expend more effort being snarky than answering a simple question. To the parent: Electron is a framework for building cross-platform desktop apps with HTML CSS and JavaScript in an embedded chrome browsers/node.js environment. More info here: http://electron.atom.io

How would I say my message without being snarky?

Re: Electron considered harmful

#234
post #214

Earlier quoted context omitted.

> I can't see how Cocoa failed at anything. Will my Cocoa app run on Windows, Linux and the web? (A well-designed web app built with Electron will). Why should any company that wants their product to be widely available invest in Cocoa developers?

Why should it? It focuses on its platform and does it well. I prefer native Mac apps to cross-platform ones. Serious companies should build native apps and keep UX guidelines of each platform in mind.

Building an app once for each platform is not economically viable for a lot of teams, 'serious' or otherwise.

Re: Electron considered harmful

#236
post #214

Earlier quoted context omitted.

Why should it? It focuses on its platform and does it well. I prefer native Mac apps to cross-platform ones. Serious companies should build native apps and keep UX guidelines of each platform in mind.

Building an app once for each platform is not economically viable for a lot of teams, 'serious' or otherwise.

Yes, but it's not Cocoa's problem.

Re: Electron considered harmful

#237

Earlier quoted context omitted.

>VSCode takes about 100Mb of ram with a project opened right now. I call bullshit on that one.

I currently have VS Code running with 7 files open, and it's using 83Mb. Like a browser, I imagine the RAM goes up with each tab, so it all depends on how many files you have open.

Well I just closed all files, disabled all extensions, restarted it and it's consuming 508MB.

Re: Electron considered harmful

#238

Earlier quoted context omitted.

Downvoted. It's generally considered rude to expend more effort being snarky than answering a simple question. To the parent: Electron is a framework for building cross-platform desktop apps with HTML CSS and JavaScript in an embedded chrome browsers/node.js environment. More info here: http://electron.atom.io

How would I say my message without being snarky?

If all I can add to a discussion is "Just google it", I just won't respond. For better or for worse, people aren't going to respond by saying 'By golly, you're right! I'm so lazy, but from now on, I will google stuff first instead of asking questions." They're just going to say basically "What an asshole, fuck this guy.

Maybe he wants an answer that is curated and summarized by a human, not a litany of links where you don't know what to focus on. For example, when I asked what dependency injection is, some kind stranger responded "It's a million dollar term for a 5 cent concept. Pass objects as arguments to functions instead of instantiating them inside." Of course, this is a limited definition, but it was put into layman's terms and it answered my question. From that answer, I was able to really learn what it was instead of being stuck on phase 1 of understanding.

When you're online, it's much easier to come off as a dick than it is in person so what I try to do is imagine someone coming up to me earnestly and genuinely asking the same question and respond thusly. Accordingly, when I know I'm asking a simple question, I add self-deprecation to the beginning. Example: "I have the technical and programming acumen of a bag of rocks, so excuse my elementary question, but..."

Re: Electron considered harmful

#239

Earlier quoted context omitted.

But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.

> Yes - electron apps are slower and eat more ram - but someone else is paying for that. Not that there aren't a lot of posts here defending Electron that basically say the same thing but don't you feel embarrassed in the slightest for saying that? Yes, there's a lot of things we, as coders, can do to make our lives more convenient by treating bandwidth, RAM, and CPU wastage as an externality that can be shoved off o…

I'm playing devils advocate here. It doesn't mean this is my way of thinking.

Re: Electron considered harmful

#240

Earlier quoted context omitted.

http://softwareengineering.stackexchange.com/questions/22161... The answer doesn't really end up being static vs dynamic, but rather how dynamic languages often lack the other facilities that make programming in the large easier, and Eric Lippert uses js as an example. Companies with a lot of money at stake have spent a lot of money and effort on things that transpile to js. The people making these decisions are almo…

Sooo... people don't like JS because 1) it's dynamically typed, and 2) they don't like JS? >They don't care if first class functions are sexy. It's not about being sexy (and believe me: first class functions aren't): it's about getting a very useful feature right, something many languages seem to have trouble with, despite the fact that Lisp (and ALGOL, IIRC) got it right in the 50s.

Algol (1960s) had no garbage collection (that I know of), so any "closure-like" data captured by a function/procedure reference had to still be on the call stack.

Otherwise, you certainly had first class functions, just not always with any external state captured.

https://en.wikipedia.org/wiki/Man_or_boy_test

I suspect TurboPascal was in the "boy" camp, in that a reference to a function (or procedure) would not have any external state bound to it.

Post reply on HN