www. O S N E W S .com
News Features Interviews
BlogContact Editorials
The desktop belongs to Electron
By Thom Holwerda on 2018-05-16 23:09:04

This doesn’t have to be forever. Maybe in the future, developers will start using React Native to build desktop applications. Or perhaps Flutter! Electron apps have a bad reputation for using too much RAM, have potential security issues, can’t (yet) match the speed of C++, and they often lack the polish and familiarity of a great native app.

But it seems clear to me that OS-specific SDKs are becoming a liability for desktop OS vendors. Developers want to use the technologies they know, and they want maximum reach for the products they build. And they’re smart enough to get what they want. A lack of cooperation on the part of Apple, Google, and Microsoft will only hurt users.

Say hello to your new Electron overlord.

At 33, I'm perhaps staring to show signs of becoming an old man, but I really don't like Electron applications. I use Discord every day, and it just feels slow, cumbersome, and out of place on my virtually 100% Modern/Fluent Design Windows desktop, Surface, and my iPhone X. I greatly prefer proper, platform-specific native applications, but I feel that ship may have sailed with things like Electron and Progressive Web Apps.

I'm not looking forward to this future.

 Email a friend - Printer friendly - Related stories
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-80 -- 81-90 -- 91-100 -- 101-108
RE[20]: Yet
By kwan_e on 2018-05-17 11:52:34
> I just looked at your JS code, the SRP principle isn't something you really get is it. I particularly like the massively long anonymous functions.

Really? That's all you've got? To pick on demonstration code? I guess you didn't bother trying to read the C++ code, because you... can't.

You also seem to know nothing about software development as things under go cleanup and refactoring, and none of that code is "finished" by any means.

Wow. Of all the things you could do to demonstrate you're not an inferior programmer, and you come up with this piss-weak excuse for a code review.

Let's see you write a native server code that automatically converts a native API into a websocket callable function, and display a HTML GUI that can represent arbitrary native structures.

I put up my code in response to someone's request. I'd request to see yours, but you're probably too chicken-shit scared.
Permalink - Score: 1
RE[20]: Yet
By kwan_e on 2018-05-17 11:53:54
> You changed your story of what you said like 3 times.

Nope. You keep making misrepresentations, and I tried to keep adding explanations and details to further explain myself. Now you throw it back in my face by claiming that amounts to changing my story?

Basically your tactic is toc misrepresent someone, and one someone tries to correct you, that's changing their story. f--k off, you c*nt.

Edited 2018-05-17 11:57 UTC
Permalink - Score: 1
Ever tried debugging a vscode crash?
By Jondice on 2018-05-17 11:55:49
For me, visual studio code (built on Electron) will frequently freeze up and go into a vegetative state, or just crash silently. Despite using --verbose, I've yet to get any useful debug info. Is it possible to even get a decent stacktrace from an Electron app?

It seems like it would be much easier to use an advanced language like Scala that can target multiple platforms: JVM and C (Native) and JavaScript. It is a bit more legwork to make it cross platform, but you get all the benefits of each platform that way.
Permalink - Score: 1
RE[3]: Yet
By coherence on 2018-05-17 12:03:25
I would concede that you have to be careful on things like the scope chain, loops, inline JS and DOM access can be a bit tricky.

The main trick with JS (especially with older interpreter) is to make sure you cache any variable that can pre calculated in loops.

Also a lot of programmers rely a lot of jQuery, which can be quite slow in certain operations and they don't do stuff like

$(this).find("<some selector string>").css({ <css properties> }

$(this).find("<some selector string>").show();

Which really slows stuff down on mobile devices. Also jQuery animations are really slow and will block the whole event loop, whereas CSS transitions are outside of the event loop.

I haven't done a lot of stuff with Server side JS.
Permalink - Score: 2
RE[20]: Yet
By kwan_e on 2018-05-17 12:06:38
> Once it gets past 30 lines you might wanna break it down a bit. Just saying :D

Of all the stereotypical bikeshedding inferior programmers like to do, this is it.

I mean, sure, take no notice of the fact that most functions in that file aren't long. And if you bothered looking at the commit history, there has been refactoring work quite a few revisions.

And "30 lines" is arbitrary, like as though someone learnt that in uni and had trouble getting rid of the training wheels. Typical cargo-cult practices of inferior programmers.

Any more junior-programmer-code-revi ew comments you want to say?
Permalink - Score: 2
RE[21]: Yet
By coherence on 2018-05-17 12:11:14
Actually I did read the C++ code, I didn't comment on it because ...

I don't do C++ professionally and I would be talking out of my backside if I critiqued it.
Permalink - Score: 1
RE[21]: Yet
By coherence on 2018-05-17 12:15:09
LOL you started calling me a shit programmer so I decided to nitpick your code that you posted to show how good you are.

You don't like it so starts throwing more insults.

BTW ran it through JShint. I didn't include where it couldn't find d3.js as I expected it was referenced somewhere else.

39 warnings

56 Unexpected use of '<<'.
56 Unexpected use of '|'.
57 Unexpected use of '&'.
64 Unexpected use of '&'.
65 Unexpected use of '&'.
67 Unexpected use of '&'.
68 Unexpected use of '&'.
70 Unexpected use of '&'.
71 Unexpected use of '&'.
152 The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
213 Use '===' to compare with '0'.
215 Use '===' to compare with '0'.
257 Unexpected use of '>>'.
257 Unexpected use of '|'.
257 Unexpected use of '&'.
257 Unexpected use of '|'.
260 Unexpected use of '>>'.
260 Unexpected use of '|'.
260 Unexpected use of '>>'.
260 Unexpected use of '&'.
260 Unexpected use of '|'.
261 Unexpected use of '&'.
261 Unexpected use of '|'.
265 Unexpected use of '>>'.
265 Unexpected use of '|'.
265 Unexpected use of '>>'.
265 Unexpected use of '&'.
265 Unexpected use of '|'.
266 Unexpected use of '>>'.
266 Unexpected use of '&'.
266 Unexpected use of '|'.
266 Unexpected use of '&'.
266 Unexpected use of '|'.
305 Use '===' to compare with '0'.
403 Use '===' to compare with 'true'.
957 Don't make functions within a loop.
985 The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
1061 Missing semicolon.
1146 Misleading line break before '?'; readers may interpret this as an expression boundary.


26 unused variables
916 inserter_args
32 read_enum
79 read_char
83 read_char32
90 read_string
102 read_structure
141 read_structures
157 read_associative
179 read_multiarray
190 read_optional
200 read_variant
233 write_enum
246 write_numbers
270 write_char
275 write_char32
280 write_string
289 write_structure
314 write_structures
330 write_associative
350 write_multiarray
363 write_optional
370 write_variant
753 html_void
1305 create_service
1332 create_push_notifier
1333 create_kaonashi

Maybe you should add a JS linter to your commit process.

Edited 2018-05-17 12:17 UTC
Permalink - Score: 0
Quality engineering is a social responsibility
By Dasher42 on 2018-05-17 12:15:41
Javascript was a shit language from the start. Any language that starts out with global variables and sticks you with workarounds to fix that is ill-conceived for any serious use. That's unfit for any program larger than a script.

There's a danger in allowing industries to grow up around sub-par standards, and it's now apparent in the creep of bloated, insecure technologies where they least belong. I am going to refuse apps built on Electron whenever possible, because it's encouraging waste and negligence.

Yes, there's a learning curve to the discipline of programming languages like C++, Rust, or Ada, but we'd see far fewer security breaches and less unnecessary obsolescence of perfectly good hardware if we insisted on decent engineering. People's privacy, rights, and sometimes even safety are on the line in our field. Software engineers should program like social responsibility is a part of our job, because it is.

Edited 2018-05-17 12:21 UTC
Permalink - Score: 1
RE[8]: Yet
By Yoko_T on 2018-05-17 12:15:59
With C# it a lot harder for a novice to do something truly terrible. Also it is relatively simple where to point a novice to the right bit of documentation if they are doing something incorrectly. In Comparison to C, I wouldn't even know where to start these days.

You mean other than creating an app using C# to begin with?
Permalink - Score: 0
RE[21]: Yet
By coherence on 2018-05-17 12:26:22

This is not exactly straight forward to read.

Edited 2018-05-17 12:30 UTC
Permalink - Score: 1

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-80 -- 81-90 -- 91-100 -- 101-108

There are 2 comment(s) below your current score threshold.

No new comments are allowed for stories older than 10 days.
This story is now archived.

News Features Interviews
BlogContact Editorials
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?