Electron is flash for the desktop (2016) • Hacker News Board

Re: Electron is flash for the desktop (2016)

#801

Post by pdabbadabba » Tue, Apr 11, 2017, 11:08 PM UTC

pharrington wrote: post #662

pdabbadabba wrote: post #625

Earlier quoted context omitted.

It sounds like we agree. To the extent we're just talking about electricity costs, then it's true that easily written, but inefficient code may indeed externalize these costs to the extent that users are unaware of the added power consumption, or that the user herself does not pay the full cost of that electricity. But these electricity costs struck me as only a small part of the broader point I was responding to, wh…

I contend that squandering the work and infrastructure involved in converting natural resources into electricity is the main problem with modern consumer software development. Any user's (lack of) perception of waste is irrelevant. The scope of the problem is not any individual literally paying a couple dollars more on their electric bill, but rather it's that gigawatt hours are literally being burned away because so…

Again. I think we agree. You're just making a different point than the one I was making. I was making a technical but hopefully still constructive point about what is an externality and what is not.

You seem more focused on making a case against shipping inefficient code. And you're point is a good one. It's just a little difficult to suss that out since you're framing it as standing in opposition to my related, but very different, observation about externalities.

Re: Electron is flash for the desktop (2016)

#802

Post by b1naryth1ef » Tue, Apr 11, 2017, 11:10 PM UTC

WildGreenLeave wrote: post #522

falcolas wrote: post #173

Earlier quoted context omitted.

> You know what the alternative to all of these Electron apps coming out is? A single page web app? That's all most of these are. Particularly the Slack/Hipchat/Discords of the world. > People are excited about the Desktop again If by desktop, you mean "need to be connected to mains power to run for more than 10 minutes", yeah, people are excited for desktops again. Electron only really makes Javascript developers ha…

Discord isn't an Electron app, its React native. And as a frequent user on my Macbook and my Android, it isn't resource intensive at all.

Discord desktop is electron. Only our iOS app is react native. We spend quite a lot of time and effort optimizing performance however, something thats required given the number of large servers with many thousands of concurrent users.

Re: Electron is flash for the desktop (2016)

#803

Post by josephg » Tue, Apr 11, 2017, 11:13 PM UTC

fenomas wrote: post #471

josephg wrote: post #80

Earlier quoted context omitted.

I'm consistently blown away that stuff like this gets past testing. Personally I think every software engineer should have a CPU meter of some for running on their machine while developing. Its an essential element of seeing what you're doing. How can you write decent software without having even that much visibility over what your computer is up to while your code runs? These huge CPU sinks making it through to rele…

> These huge CPU sinks making it through to release required nobody to even glance at a CPU graph. Every bug looks egregious in hindsight; just because an app has one is no reason to assume the engineers who made it don't bother to test anything. Also: that particular issue only hurt idle CPU usage, and the usage was something like 13% CPU usage IIRC. It wasn't exactly the kind of thing that sets off klaxons.

> Every bug looks egregious in hindsight

Most bugs are of the form "do X then Y then it doesn't work". These idle CPU bugs are reproduced simply by opening the application.

I accept that 13% idle usage is invisible for most developers - but that's a bit disappointing. I notice stuff like this just by idly glancing at my CPU meter from time to time. An app that's sitting on high idle usage sets off klaxons for me.

Re: Electron is flash for the desktop (2016)

#804

Post by overgard » Tue, Apr 11, 2017, 11:14 PM UTC

cr0sh wrote: post #570

overgard wrote: post #377

Earlier quoted context omitted.

C is not that hard! If you're a programmer, and you don't know C, you're not good at your craft. I realize that sounds incredibly harsh but it's true: your job is to make a computer do a task efficiently. If you can't even read the language that makes that possible, you don't know what you're doing.

I could re-write your argument by replacing "C" with "x86 assembler" - but I won't. However, the argument could still stand, but I'd hesitate at saying it's a wholly valid argument. My own prejudice aside - I honestly do think that if you don't have an understanding of how a CPU works at this very low level - maybe even lower - you don't know what you're doing; that, and I have done hand-assembled x86, 6502, and 6809…

I get that everyone has their specialty -- Im not trying to imply that someone that writes javascript for a living is a lesser coder or everything should be native. My point is that there are fundamentals to this craft, and all these web developers acting like C is exotic knowledge baffles me. With regard to your first point though, I actually do think knowing some form of assembly is also super useful. I just tend to focus on C since as is well known, its basically portable assembly.

Re: Electron is flash for the desktop (2016)

#805

Post by belovedeagle » Tue, Apr 11, 2017, 11:14 PM UTC

discreditable wrote: post #125

Would it make more sense to distribute electron as a dependency and allow apps to use it? That way, instead of 10 apps requiring 10 different electrons we have 10 apps that can use a pre-installed electron.

No, because history has shown that shared libraries on any and all platforms inevitably become bundled into applications themselves (leaving one wondering WhyTF someone would choose something as unnecessarily complex as Docker over, you know, static linking).

Those who do not know history are doomed to reinvent it, poorly. Or something like that.

Re: Electron is flash for the desktop (2016)

#806

Post by belovedeagle » Tue, Apr 11, 2017, 11:17 PM UTC

bengotow wrote: post #637

mydigitalself wrote: post #618

Btw, I can tell you exactly what the "Preventing Sleep" is all about. I'm 100% positive there's a bug in Chrome's WebRTC stack that causes that to happen. Fire up Chrome, doesn't happen. Go on a Hangout, yip "Preventing Sleep".

But... isn't this correct? I wouldn't want my machine falling asleep while on a conference call, so preventing sleep is a good thing?

I'm pretty sure GP is talking about CPU low-power state like OP did, not OS sleep. They're entirely different things.

Re: Electron is flash for the desktop (2016)

#807

Post by frogfuzion » Tue, Apr 11, 2017, 11:18 PM UTC

Very late to the conversation!

I'm not going to offer an opinion, but just anecdotal evidence. We don't use Slack, but since we have Office 365 I was tasked with evaluating if Microsoft Teams was something we should start using instead of Skype, etc.

I have advised to wait. I was seeing similar metrics to what OP is describing where the Teams Client was using 200+ Mb of RAM (many times more than VISUAL STUDIO).

Also the UI seemed laggy. I'm not 100% sure it is Electron, but the installer and interface seemed as much.

Re: Electron is flash for the desktop (2016)

#808

Post by iends » Tue, Apr 11, 2017, 11:24 PM UTC

bartl wrote: post #644

sametmax wrote: post #182

People complaining about electron are the same type than the ones that used to say : - why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly. - why are people writing this stuff in Java. It's so slow and you don't have as much control on memory. Write it in C. - why are people writing this stuff in Python. It's so slow and you don't have as much contro…

I love Javascript. But 160MB for a chat app? That's insane.

Do you think they are optimizing for file size? Do you think their customers really care?

(The answer to both is no.)

Re: Electron is flash for the desktop (2016)

#809

Post by 4D1 » Tue, Apr 11, 2017, 11:28 PM UTC

smokeyj wrote: post #741

4D1 wrote: post #716

Earlier quoted context omitted.

One problem, you cant optimize at all with electron, you are stuck with shoving a complete web browser solution into your program to make a GUI. You are stuck with a massive amount of dependencies (html/css parser, javascript VM...) to various massive projects for what, easy cross platform support? Sure cross platform GUI's have been a problem, but any developer can agree that dependency to this level within professi…

Your solution to memory leaks is using a lower-level language? I should probably stop reading there.. How do you make SSL connections? How do you parse JSON api's? How do you play audio, integrate with platform features (menu bars, dock dropping etc)? How do you create P2P WebRTC connections that capture camera and mic inputs? Let me guess, you have libraries for that. People keep bringing this up because they're ins…

> Your solution to memory leaks is using a lower-level language? I should probably stop reading there..

Lower level than sandboxing into a js VM? yes. Writing everything in assembly, or in an unmanaged language? no. Adding unnecessary complexity to a program increases possibilities of bugs, which in this case, will be outside of your control. And this is a perfect example of unnecessary complexity.

> How do you make SSL connections? How do you parse JSON api's? How do you play audio, integrate with platform features (menu bars, dock dropping etc)? How do you create P2P WebRTC connections that capture camera and mic inputs? Let me guess, you have libraries for that.

Simple libraries that intend on doing the job and getting out of your way, yes. I wasn't aware you needed to embed a web browser to parse a json string, or to establish an SSL connection? There is a large difference between what a library is, and what electron aims to be... There will always be system apis that you will have to interface with, these are apples and oranges.

> People keep bringing this up because they're insecure about their role as programmers in a world where creating useful functionality is becoming easier and more accessable. People keep bringing this up because they don't comprehend what business requirements actually are and the cost of rolling your own technology and battle testing it.

Thank you for reminding me what the phrase "argumentum ad-hominem" means.

> I promise you. We're not all stupid. That's all I'm asking of people to consider before they start solving all the world's problems.

I can't speak for anyone else but I don't believe anyone who finds electron appealing is stupid. I am sure these people are more than capable programmers, and electron is a very appealing way for a web-based product to be able to quickly produce and distribute a desktop client. Most just desire for people to understand that most large-scale projects will dig their own graves in the promises of cross platform support and a fast production cycle, which has been a growing trend in software development for quite a few years now.

Re: Electron is flash for the desktop (2016)

#810

Post by TimJYoung » Tue, Apr 11, 2017, 11:35 PM UTC

vram22 wrote: post #540

TimJYoung wrote: post #328

Earlier quoted context omitted.

"Please someone, write that !"... We actually have written something similar for our product Elevate Web Builder (commercial, closed-source, written in Delphi), and have considered moving it to Free Pascal in order to allow developers to use it in portable, native desktop applications. The IDE for Elevate Web Builder has to provide a browser-like design-time environment for the WYSIWYG designers, so we created one. I…

Interesting, so you've create or are trying to create (or make cross-platform) something like a web dev environment in and for Object Pascal?

We have a product for web development in Object Pascal, Elevate Web Builder (http://www.elevatesoft.com/products?category=ewb&type=web) that includes an IDE with a WYSIWYG design environment (the IDE is written in Delphi for Windows). In order to supply the design environment, we had to write an emulation layer that mimics the DOM tree and can perform the necessary drawing operations to satisfy all DOM CSS style properties. This layer is ~80% of what you would need to implement a UI toolkit in native Object Pascal using Free Pascal. The last ~20% would be dealing with surfacing the native OS input controls (single-line edit, multi-line edit, etc.), which are just stubbed out right now because the design environment doesn't require them. We've considered finishing this last bit and making the whole thing available for Free Pascal.