Linked by Thom Holwerda on Wed 16th May 2018 23:09 UTC
General Development

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.

Order by: Score:
I feel the same way
by cosmotic on Wed 16th May 2018 23:34 UTC
cosmotic
Member since:
2010-01-31

I feel the same way about electron apps; bloated, feature anemic, poorly integrated, cumbersome... But I feel like all those words also describe "modern" apps on windows. I try to give MS the benefit of the doubt, but every time I try one of the modern apps I'm disappointed.

Reply Score: 0

v RE: I feel the same way
by CaptainN- on Thu 17th May 2018 01:17 UTC in reply to "I feel the same way"
RE[2]: I feel the same way
by hyper on Thu 17th May 2018 06:26 UTC in reply to "RE: I feel the same way"
hyper Member since:
2005-06-29

Electron runs on a highly optimized JS runtime, one which matches the .NET framework on which all those so-called native "modern" apps are built on top of.

Nope and nope. .NET (Core or proper) is better than any JS runtime. And it will always be so because of... JS, the language.

Reply Score: 2

RE[3]: I feel the same way
by CaptainN- on Thu 17th May 2018 19:56 UTC in reply to "RE[2]: I feel the same way"
CaptainN- Member since:
2005-07-07

I mean obviously it's more complex than which is faster - but it's not true claim javascript isn't fast. And it's still getting faster. Believe what you want though - I'll keep writing fast js apps.

Reply Score: 2

RE[2]: I feel the same way
by The123king on Thu 17th May 2018 12:48 UTC in reply to "RE: I feel the same way"
The123king Member since:
2009-05-28

...That's what Apple is planning to do with their merger between iOS and macOS...


Nope. https://www.smh.com.au/technology/users-don-t-want-ios-to-merge-with...

Reply Score: 2

RE[3]: I feel the same way
by CaptainN- on Thu 17th May 2018 19:57 UTC in reply to "RE[2]: I feel the same way"
CaptainN- Member since:
2005-07-07

Users don't know what they want until you show it to them. If you do what users say they want, you end up with Windows...

Reply Score: 1

Comment by gorbie
by gorbie on Wed 16th May 2018 23:36 UTC
gorbie
Member since:
2010-10-22

when you see what can get achieved in something like MenuetOS and some amazing coding skills - web apps make me sad.

another favorite site of mine is tinyapps.org which generally showcases some amazing little apps, generally standalone.

I feel like everything today is going over-engineered or over-simplified.

I came across a self checkout the other day that seems to have adopted a flattened design. It made me rather angry that I did not find it intuitive to use at all. Not a single word or label on any button. AM I too smart to use an interface they have designed for the lowest common denominator?

Or, like everything else lately, have they all abandoned user-centered design? Have designers been given divine intervention? Did Moses come down from the mountain with some UX tablets? did I miss that memo?

Reply Score: 2

v RE: Comment by gorbie
by Yoko_T on Thu 17th May 2018 05:45 UTC in reply to "Comment by gorbie"
This is the reason computers feel slow
by sukru on Wed 16th May 2018 23:52 UTC
sukru
Member since:
2006-11-19

We have much better and faster processors, however applications seem to feel sluggish compared to older times. I remember even Windows 95 feeling more responsive.

I understand that due to hi-dpi displays and multi-monitor setups it is now necessary to use desktop composition. Some other things like security, better unicode support, etc come with costs. I accept them.

However I still believe we can at least continue writing native desktop applications and not push HTML based clunky ones. I like my web sites inside my browser, but I don't want them to take over my PC.

Reply Score: 3

rener Member since:
2006-02-27

yes, exactly, this is why our ExactScanPro is some 20 MB, including OCR and nearly 500 scanner drivers: https://exactscan.com Also macOS and such start to make me so sick, that I dedicated some of my videos to showing and re-exploring vintage things: https://youtube.com/renerebe

Reply Score: 2

Yet
by kwan_e on Thu 17th May 2018 00:32 UTC
kwan_e
Member since:
2007-02-18

can’t (yet) match the speed of C++


Yet? How about never?

It's a physical impossibility that a thing that runs in a VM would ever match something that runs without a VM.

Reply Score: 2

RE: Yet
by AnyoneEB on Thu 17th May 2018 02:48 UTC in reply to "Yet"
AnyoneEB Member since:
2008-10-26

JavaScript and other similar non-native languages are not intrinsically slower than C/C++. They are much harder to write good optimizers for and much easier to write slow code in, but it's not an insurmountable problem. JavaScript compilers have gotten a lot better than they used to be and continue to improve. In practice, browser JavaScript implementations tend to avoid over-optimizing on run time because from the perspective of the user of a web browser, the compile time is part of the run time. This is less of an issue for an Electron app which could theoretically do compilation work at packaging and/or installation time.

As an example, https://stackoverflow.com/a/4528285 lists a few areas where Java (not JavaScript, but similar at a high level) out-performs C/C++ due to the advantages of JIT compilation and garbage collection. In practice, of course, these advantages are edge cases and/or are overwhelmed by other factors which make it slower.

To be clear, I'm not predicting JavaScript run time performance parity with C++ any time soon. But it's a research and engineering challenge, not a physical impossibility.

Reply Score: 2

RE[2]: Yet
by kwan_e on Thu 17th May 2018 03:43 UTC in reply to "RE: Yet"
kwan_e Member since:
2007-02-18

To be clear, I'm not predicting JavaScript run time performance parity with C++ any time soon. But it's a research and engineering challenge, not a physical impossibility.


It is a physical impossibility because doing something extra is always slower than not doing something extra. As for JIT, native code (I'm not just limiting it to C++) is not at odds with JIT. If Java (and other VM languages) can use JIT, then so can/does native code. But the stackoverflow link doesn't really show anything, since it's comparing Java to Java-like native code, and not sensibly native code.

The issue, though, is not just speed. It's also memory usage and power consumption. No VM language can approach native code in all three areas of speed, memory usage and power consumption.

Reply Score: 2

RE[3]: Yet
by woegjiub on Thu 17th May 2018 05:06 UTC in reply to "RE[2]: Yet"
woegjiub Member since:
2008-11-25

There's no doubt you *can* write faster code in C than in an interpreted/bytecode language.

There's also no doubt that it is *possible* to hand-write assembly that's faster than the C compiler enables.


The caveat is of course that making said faster code requires a level of expertise and time investment.


If you need to spend a long time learning and conceptualising a solution that gives you even a 5% speed-up, you need to be able to justify that.

It's writing for a heavily optimised platform that allows ideas to be expressed easily, or writing for a platform that requires heaps of domain knowledge and will come back to bite you with overflows, memory access issues, and security problems unless you're an expert.


99% of desktop applications just don't warrant that level of expertise.
A chat, to-do, or text-editor app aren't a compiler or a browser, so they don't need it.

Reply Score: 3

RE[4]: Yet
by kwan_e on Thu 17th May 2018 05:22 UTC in reply to "RE[3]: Yet"
kwan_e Member since:
2007-02-18

The caveat is of course that making said faster code requires a level of expertise and time investment.


You sound like someone stuck with a C89 knowledge of native programming.

Modern native languages don't need that level of expertise or time investment. All it requires is to unlearn the nasty habits acquired by learning Java or Javascript or C#.

For example, your StackOverflow link talked about the GC being great at a bunch of small allocated objects. Yeah, if you wrote native code with allocations for small objects everywhere, then of course it would be slow. But you have to go out of your way to do inefficient stuff in native languages, especially in the last 6 years.

If you need to spend a long time learning and conceptualising a solution that gives you even a 5% speed-up, you need to be able to justify that.


Again, not just about speed. But about power consumption and memory use.

99% of desktop applications just don't warrant that level of expertise.


Again, what expertise? Modern native languages are easy, and you have to increasingly go out of your way to write inefficient code.

Edited 2018-05-17 05:23 UTC

Reply Score: 3

RE[5]: Yet
by woegjiub on Thu 17th May 2018 05:57 UTC in reply to "RE[4]: Yet"
woegjiub Member since:
2008-11-25

You sound like someone stuck with a C89 knowledge of native programming.

I did C99/C++11 stuff at uni, yeah.
It involved so much fucking around with boilerplate I have no desire to revisit them.

Modern native languages don't need that level of expertise or time investment. All it requires is to unlearn the nasty habits acquired by learning Java or Javascript or C#.

What languages? C and C++ are a complete horror to use.

For example, your StackOverflow link talked about the GC being great at a bunch of small allocated objects. Yeah, if you wrote native code with allocations for small objects everywhere, then of course it would be slow. But you have to go out of your way to do inefficient stuff in native languages, especially in the last 6 years.

I'm not the dude who posted that link.

Again though, which languages?
Teams of experts still fuck up with memory allocation in C/C++, to this day.

Again, not just about speed. But about power consumption and memory use.

pypy comes damned close to native on all 3 fronts, so it's not inherent to compiled vs. interpreted.
And Java runs on *ATM cards*. They are powered through induction and have memory measured in bytes.

Reply Score: 3

v RE[6]: Yet
by kwan_e on Thu 17th May 2018 06:38 UTC in reply to "RE[5]: Yet"
RE[7]: Yet
by woegjiub on Thu 17th May 2018 07:25 UTC in reply to "RE[6]: Yet"
woegjiub Member since:
2008-11-25

First of all, could you please drop the condescending tone? It's not helpful.

First of all, completely irrelevant to what we're talking about. And if the university is making you write boilerplate, that's probably more the fault of your course. I did C++ in uni as well, but I basically had to teach myself the language because universities don't teach C++ well.

Getting going in those languages still has a massive conceptual overhead that doesn't exist for things like JS and Python.

C devs are always massively elitist in this way.

If the barrier to entry is higher, and I can get what I want done quickly in Python, why should I bother learning the current best practices in C?

Do your own research. It's not like certain new native languages haven't gotten a lot of hype recently.

So Go/Rust?

Again, how are you writing it?

The way C textbooks explain it.

It's about barriers to entry again.

There is so much content out there on C, how is a beginner supposed to know what's "good" and what's "old"?
You have the benefit of hindsight. For me, I was already productive in interpreted languages, and then I was forced to use native languages in an archaic fashion with zero libraries allowed.

It seems like C for beginners is almost always approached as "this is how the computer works at a low level".

If I just want to make a small GUI, why do I need to know or care about anything other than the bare minimum of how to put together a UI and call functions?

(To be clear, I do know that and I do consider algorithmic complexity, but it's stuff I shouldn't have to know until I hit bottleknecks.)

Really? Then why do you believe the writers of the VMs for Java, C# and Javascript, who write the VM in C++, don't fuck up memory allocation too?

They probably did.
They're all paid to make those engines as efficient as possible though.
Unlike someone making a desktop app in their spare time.

Damned close != native. Which is the whole point. No one said it can't be fast. It just can't be AS fast. Do you understand the concept of equality.

Of course I do. Do you understand the concept of diminishing returns?
Who gives a shit about a 5% speedup if it takes longer to deliver?

Do you understand of concept of *comparing* with native languages on the same systems?

Do you also want to tell me what language the Java ATM card VM is written in?

The point being that it *can* work under those constraints.
I don't care that C is faster or more efficient or uses less RAM.
If the code is harder to grasp or the barriers to entry are higher, the use-case *needs* to warrant it.

The vast majority of use cases don't need it.

Reply Score: 4

RE[5]: Yet
by coherence on Thu 17th May 2018 06:37 UTC in reply to "RE[4]: Yet"
coherence Member since:
2018-02-04

All it requires is to unlearn the nasty habits acquired by learning Java or Javascript or C#.


This is such blatant arrogance. I get quite tired of C devs thinking their shit doesn't stink. Some of the worse libs I've had to deal with is proprietary C libs. I ended up re-implenting my own versions in C# that actually worked.

You can write efficient code with a managed language such as C# or Java. Understanding what the CLR or the JVM is doing in the background is pretty key and almost every interview I've had for a contract in the last 10 years have given me about 45 minutes worth of questions about how memory etc is managed by the CLR or JVM.

Even with JS, if you wanna get a job at a decent place doing it. You will be asked about programming patterns, DOM manipulation and a bunch of other stuff relating to performance and security (XSS, XSRF etc).

Reply Score: 3

RE[6]: Yet
by kwan_e on Thu 17th May 2018 06:43 UTC in reply to "RE[5]: Yet"
kwan_e Member since:
2007-02-18

"All it requires is to unlearn the nasty habits acquired by learning Java or Javascript or C#.


This is such blatant arrogance. I get quite tired of C devs thinking their shit doesn't stink. Some of the worse libs I've had to deal with is proprietary C libs. I ended up re-implenting my own versions in C# that actually worked.
"

I believe I said native languages. C is not the only native language. Yes, many C libs do stink. But there are OTHER LANGUAGES.

You can write efficient code with a managed language such as C# or Java.


That's not the argument.

Understanding what the CLR or the JVM is doing in the background is pretty key and almost every interview I've had for a contract in the last 10 years have given me about 45 minutes worth of questions about how memory etc is managed by the CLR or JVM.


And yet learning about the ins and outs of a native language is too hard? Funny how people complain about learning the all corners of native language, but they'll have to learn just as much about the VM anyway. How can anyone say it's easier then?

Reply Score: 1

RE[7]: Yet
by coherence on Thu 17th May 2018 07:43 UTC in reply to "RE[6]: Yet"
coherence Member since:
2018-02-04

I believe I said native languages. C is not the only native language. Yes, many C libs do stink. But there are OTHER LANGUAGES.


Yes however many of those other languages aren't that much better in terms of speed than C# or Java. Yeah memory consumption is a bit more, but even phones have gigabyte or more of it.

Also while C is pretty mainstream, the other languages that I can think of most are either esoteric (impossible to hire for outside of the US), only really work on *nix properly or are almost dead languages. There is C++ but you get 90% of the benefits using C# or Java, without all the headaches.

Also my main complaint was your absolute smarmy arrogance regarding programmers who prefer a managed language and how we are somehow inferior. No I just care about getting the job done. I am a software engineer not a computer scientist. I write reliable code, that normally has decent automated test coverage. Most of it is Web APIs or Services.

And yet learning about the ins and outs of a native language is too hard? Funny how people complain about learning the all corners of native language, but they'll have to learn just as much about the VM anyway. How can anyone say it's easier then?


Sorry it isn't really comparable, you must know this. Learning what the CLR or JVM do can be summed up into a few pages (at most) of general principles and best practices. Also Patterns are just good coding practices.

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.

There are tonnes of other benefits to using a managed language with type safety. Performance and Memory isn't always the most important thing.

Then you have things like hiring and clients. Most clients already have bespoke .NET software, it is easy to find a decent C# dev and getting rid of the idiots I can normally do within 15 minutes on the phone.

There are other considerations other than performance that if you are being pragmatic are much more pertinent.

Edited 2018-05-17 07:53 UTC

Reply Score: 1

RE[5]: Yet
by Gargyle on Mon 21st May 2018 16:26 UTC in reply to "RE[4]: Yet"
Gargyle Member since:
2015-03-27

All it requires is to unlearn the nasty habits acquired by learning Java or Javascript or C#.

Just being interested, which nasty habits?

Reply Score: 2

RE[3]: Yet
by coherence on Thu 17th May 2018 05:47 UTC in reply to "RE[2]: Yet"
coherence Member since:
2018-02-04

Depends on the language and what you are doing. With C you are correct it will win out in almost anything. Other compiled languages ... not so much, in fact Java and C# beat quite a few languages that are compiled to a native binary when considering power consumption.

Also JavaScript is a lot more energy efficient than a lot of languages when dealing with string manipulation (regexs) according to the paper below.

http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pd...

I suspect that JavaScript will continue to be faster and more memory efficient as the years go by because there is a huge resources being put into making it faster. C and its compilers have had 40+ years of people making tooling for it. JavaScript has at best about 10 years (basically since Google released V8).

Edited 2018-05-17 05:52 UTC

Reply Score: 1

RE[3]: Yet
by CaptainN- on Thu 17th May 2018 06:05 UTC in reply to "RE[2]: Yet"
CaptainN- Member since:
2005-07-07

It's an oversimplification though - where do you draw the line between what's vm and not vm. Userland vs. kernel code - I could say kernel code is the only native code, and then someone else would come along as say only code written in asm counts. It's all arbitrary.

In practice a high level dynamic language like JS will probably never run as fast as highly optimized C++, but it's already really really fast compared to VMs of the old days. Modern JS engines run circles around even not too old (comparatively lower level) Java and .NET environments.

And then there's webassembly, which is also available, and is no slouch. It's just not true that a JIT or a VM (which BTW aren't the same things) is or has to be slow. It's not even true that an interpreter has to be slow.

Reply Score: 2

RE[2]: Yet
by Torbjorn Vik Lunde on Thu 17th May 2018 08:17 UTC in reply to "RE: Yet"
Torbjorn Vik Lunde Member since:
2009-09-04

Languages that use garbage collection _will_ be slower pretty much always.

(ASM.js does not feature garbage collection however, but then you're writing in a non-JS language that compiles to ASM.js.)

Reply Score: 1

RE[3]: Yet
by AnyoneEB on Thu 17th May 2018 08:40 UTC in reply to "RE[2]: Yet"
AnyoneEB Member since:
2008-10-26

Yes, except in rare edge cases, garbage collection will be slower than explicitly freeing memory (and, of course, in those edge cases, you can use garbage collection in C/C++ if it's right for your application). But the explicit calls to free (or simply allocating on the stack in the first place) can theoretically be added by a compiler, not just by a human. In practice, this is really hard and is currently only done in very simple cases (e.g. when an object is constructed and freed in the same method), but it's not impossible to imagine a type system that could capture most common memory usage patterns in Javascript while being inferable without annotations in reasonable code. I'm not up-to-date on the details of how modern Javascript engines work, so it's entirely possible some analyses along these lines actually are already being done.

Reply Score: 3

RE[4]: Yet
by CaptainN- on Thu 17th May 2018 20:05 UTC in reply to "RE[3]: Yet"
CaptainN- Member since:
2005-07-07

There are improving algorithms for GC though - it used to be that most GC would "stop the world" and climb all the trees to figure out what to clear, but these days GC engines are getting smarter, and are able to clear smaller limbs in shorter bursts. It's still a problem, but it's getting better, and it's not slow.

And then again, there are ways to manually manage the GC, or you can use those asm.js/webassembly manually allocated memory blocks if you really need faster memory access with no GC hiccups. There are options in the electron space. I'm actually kind of excited to write some RUST apps which could be delivered to web browsers as a PWA or electron app.

BTW, a better PWA system for desktops could go a long way to reducing the need for standalone electron apps. Chromes implementation of web apps was horribly broken on the desktop, but the mobile platforms (Android and iOS) both have a great solution. If you install a PWA shortcut to your homescreen on those platforms, and the PWA is written well, it's hard to tell the difference from a native app.

Here's one to try (the ads ruin the experience on iPad and desktop, but that's a different problem):
https://www.makebeliefscomix.com/Comix/

All we really need is something similar on the desktop - then no more need for electron!

Reply Score: 3

RE[2]: Yet
by panzi on Thu 17th May 2018 10:44 UTC in reply to "RE: Yet"
panzi Member since:
2006-01-22

Java is not comparable to JavaScript in that regard. In JavaScript (and any dynamic language) property and global scope lookups are hashtable lookups! So many hashtable lookups for everything that is just dereferencing a pointer in native languages. There are hard limits on how you can optimize such a language.

Reply Score: 2

RE[3]: Yet
by coherence on Thu 17th May 2018 12:03 UTC in reply to "RE[2]: Yet"
coherence Member since:
2018-02-04

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.

Reply Score: 2

RE[3]: Yet
by AnyoneEB on Thu 17th May 2018 17:00 UTC in reply to "RE[2]: Yet"
AnyoneEB Member since:
2008-10-26

In practice, modern Javascript engines perform type inference and are able to compile code that semantically has those slow hashtable lookups to something similar to what you would expect for a Java field access. This usually involves some type tag checking when the analysis can't guarantee it got the type right. Due to branch predication in modern processors, checking a type tag is nearly free if check passes. The main issue with that kind of optimization is that in dynamic languages, programmers sometimes actually take advantage of the fact that it's dynamic and write code in a way that doesn't really have an equivalent in static code, so the JIT is forced to fall back to slower code. In other words, some Javascript code is in fact intrinsically slow (e.g. as a worst case, eval can never be fast in general), but that doesn't mean all of it is.

Reply Score: 3

Comment by coherence
by coherence on Thu 17th May 2018 03:10 UTC
coherence
Member since:
2018-02-04

A huge number of applications are built in managed languages now. This is the same old complaint when Java and C# came out. I use lots of IntelliJ products and they are all built in Java, they work fine.

Anecdotally, I use VS Code, Discord, Slack all day. I have no idea what you are on about it "feeling slow". I run VSCode on several low end machines now i.e. a E6410 laptop (old core i5) to a Core 2 Duo from 2008. However in all my systems I have fast SSD disks and as much ram as I can stuff in them.

I also use Discord on my iPhone 6S. Works fine, no faster or slower than any other application on my iPhone. I have no idea how Thom's iPhone X would be slower with discord.

The only applications that are a lot faster than VSCode are Notepad++ (which only has about 20% of the features of VSCode).

Considering that both Discord and Slack are better than Skype which are native, really shows that it really doesn't matter.

Anyway, all electron is really doing is fulfilling Atwood's law:

I propose a corollary to this rule, which in the spirit of recent memes, I'll call Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.


https://blog.codinghorror.com/the-principle-of-least-power/

Edited 2018-05-17 03:28 UTC

Reply Score: 4

Electron is garbage
by Darkmage on Thu 17th May 2018 03:22 UTC
Darkmage
Member since:
2006-10-20

I get random hangs all the time in slack. It's just absolute garbage. Having said that GTK is no rose either. Unable to even auto connect signal handlers in C++. I think every desktop environment is stuffed at the moment. They are all flawed in one way or another. No big surprise to see there's no relief coming any time soon.

Reply Score: 1

RE: Electron is garbage
by CaptainN- on Thu 17th May 2018 06:07 UTC in reply to "Electron is garbage"
CaptainN- Member since:
2005-07-07

That may also have to do with how they wrote Slack. That's a LAMP app on the back end, with a bunch of jQuery on the front end. You are bound to run into performance hiccups with that kind of stack - although, Slack has actually done a wonderful job with it.

Reply Score: 2

What?
by Soulbender on Thu 17th May 2018 04:38 UTC
Soulbender
Member since:
2005-08-18

I like some Electron apps (Atom, vscode, slack) but this article is just clueless in the extreme.
But such is the way of this industry. Every X months something comes around that a bunch of morons thinks solves everyone's problem and that should be used for every possible solution. (See Blockchain, NoSQL, RubyOnRails, XML etc etc)

It's "use the right tool for the job", not "shoehorn the tool I like into being a half-assed, at best, tool for the job".

Edited 2018-05-17 04:46 UTC

Reply Score: 4

RE: What?
by CaptainN- on Thu 17th May 2018 06:09 UTC in reply to "What?"
CaptainN- Member since:
2005-07-07

NoSQL - ain't that the truth! Something like MongoDB is not even really NoSQL anymore - it's more like unsafe less articulate SQL.

Edited 2018-05-17 06:09 UTC

Reply Score: 1

not old
by ksec on Thu 17th May 2018 04:45 UTC
ksec
Member since:
2013-04-04

at 33 these signs are being wise.

Reply Score: 1

Which OS-specific SDK?
by ybailly on Thu 17th May 2018 06:55 UTC
ybailly
Member since:
2018-05-17

"OS-specific SDKs are becoming a liability for desktop OS vendors"
Definitely, doing C++ or Python using Qt is a very good proof of that. Cross-platform, easy to use (yes, even in C++). Why reinvent yet another square wheel? Why spend an insane amount of time and energy in testing and re-testing things a compiler would catch right away?

Reply Score: 2

RE: Which OS-specific SDK?
by ThomasFuhringer on Thu 17th May 2018 07:24 UTC in reply to "Which OS-specific SDK?"
ThomasFuhringer Member since:
2007-01-25

Actually I would find it time Microsoft (and Apple) incorporate Python into their OS. If cross platform toolkits prevail in the end or rather wrappers around native widgets prove to be the lasting solution has yet to be seen. For performance critical parts you can always combine C (or objective C) with Python. Works perfect.

Reply Score: 1

A total disregard for the users
by ThomasFuhringer on Thu 17th May 2018 07:18 UTC
ThomasFuhringer
Member since:
2007-01-25

HTML was devised as a language to diplay text, with embedded pictures and links to jump to other text pages.
In the meantime all kinds of weird things have been bolted on to make it somehow useable to build database applications and now they even tell us it is the future for desktop programming. It is a nightmare.

Reply Score: 4

no efficiency
by yoshi314@gmail.com on Thu 17th May 2018 07:42 UTC
yoshi314@gmail.com
Member since:
2009-12-14

There was a joke i saw on twitter once.

"What would you do with a beefy 18-core laptop?"

"I'd run two electron apps at the same time"


The more i experiment with this technology, the more i understand that joke.

Reply Score: 6

Cross platform
by Soulbender on Thu 17th May 2018 08:07 UTC
Soulbender
Member since:
2005-08-18

Developers have clearly signaled their intentions: they want to make cross platform desktop applications that work right now using web technologies.


a)there are already plenty of open source SDK's for this very purpose.
b) you can't build IOS and Android apps with Electron.

it compiles into a binary that works on every OS


Mac, Windows and Linux (supported platforms for Electron) is only a subset of "every OS".
I'm also pretty sure it doesn't "compile into a binary"..

Edited 2018-05-17 08:08 UTC

Reply Score: 4

RE: Cross platform
by Moochman on Thu 17th May 2018 08:52 UTC in reply to "Cross platform"
Moochman Member since:
2005-07-06

For phones there's Cordova. In fact you can use the same (web-technology-based) code for mobile and desktop, all platforms, by using a combination of Electron and Cordova.

Reply Score: 3

RE: Cross platform
by Delgarde on Thu 17th May 2018 10:07 UTC in reply to "Cross platform"
Delgarde Member since:
2008-08-19

I'm also pretty sure it doesn't "compile into a binary"..


I suspect "packages into a binary" would be a more accurate description... bundling the runtime into an installer alongside the app.

That seems to be the future of Java – with the modularised runtime libraries that landed in 9, they support building a cut-down runtime environment that's got just the bits you care about for running your microservices container, or whatever...

Reply Score: 3

RE: Cross platform
by coherence on Thu 17th May 2018 16:37 UTC in reply to "Cross platform"
coherence Member since:
2018-02-04

They are the most used. Honestly nobody cares much about the rest. Icaros / Amiga OS user here.

Reply Score: 1

Unsafe framework
by bitwelder on Thu 17th May 2018 08:56 UTC
bitwelder
Member since:
2010-04-27

cvedetails started tracking Electron only this year, but there are already two pretty ugly security vulnerabilities recorded there.
https://www.cvedetails.com/product/44696/Electronjs-Electron.html?ve...

Reply Score: 3

Ever tried debugging a vscode crash?
by Jondice on Thu 17th May 2018 11:55 UTC
Jondice
Member since:
2006-09-20

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.

Reply Score: 1

zima Member since:
2005-07-06

an advanced language like Scala that can target multiple platforms: JVM and C (Native) and JavaScript

You mean what, it ~compiles to JVM, C and js?

Reply Score: 2

Dasher42
Member since:
2007-04-05

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

Reply Score: 1

zima Member since:
2005-07-06

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

With Rust or Ada, perhaps, but I'm not so sure about C++...

Reply Score: 2

Comment by The123king
by The123king on Thu 17th May 2018 12:45 UTC
The123king
Member since:
2009-05-28

I thought you were talking about this for a moment: https://en.wikipedia.org/wiki/Acorn_Electron

Reply Score: 2

Here's the deal
by fretinator on Thu 17th May 2018 13:23 UTC
fretinator
Member since:
2005-07-06

I've been predicting this since the late 90's.

It reminds me of when CD-ROMS first arrived. There were all kinds of CD-ROM programs. John Dvorak even had a show where they went over the best CD-ROM programs. Well, eventually the idea passed and there were just Desktop Applications - some of whom used media stored on an external media and some which didn't.

I've always felt this was true of the Web. At some point, there are just applications - pieces of code that receive input from a user, access resources to process the input, and then output information back to the user. It doesn't matter which machine houses the running code, which machine houses the data, etc. The idea of "Web Apps" will gradually disappear, and it will just become another source of information. Some apps will primarily access local resources, and some will access remote resources. Some will run from local resources, some from remote. The difference won't mean much to the end user, and developers shouldn't have such impedance when switching from local to remote resources. There will just be apps.

Reply Score: 3

electron desktop?
by l3v1 on Thu 17th May 2018 19:22 UTC
l3v1
Member since:
2005-07-06

Holy f*cking sh*tfilled pancake factory. Just because something can be done it doesn't mean it should be. And that's all I have to say about that.

Well, that, and two more things.

Electron is sort of like a web browser and a web server all in one convenient package. Developers build a user interface using HTML, CSS, and JavaScript (the same as any website), and build the “backend” for their app [...] using JavaScript.


No. Just no.

Developers want to use the technologies they know [...]


Exactly. Problem is, have you met some of these people who call themselves developers these days? I say, if they want to use the tech they know, OK with me, just let the rest of us be. You want Electron? Fine, take it, run with it, just forget about shoving it down the uncaring crowds' throat.

Reply Score: 1

RE: electron desktop?
by CaptainN- on Thu 17th May 2018 20:07 UTC in reply to "electron desktop?"
CaptainN- Member since:
2005-07-07

The uncaring crowds, er, don't care. If the app runs well (Slack, VS Code) they'll happily use it, and most won't even wonder about whether it's native or not - the truth is, no one cares.

Reply Score: 3

Oh please not again.
by bryanv on Thu 17th May 2018 20:03 UTC
bryanv
Member since:
2005-08-26

Subtract 20 years, and it was Java Swing applications.

Sorry, I've seen this bullshit before. I'm calling it.

Reply Score: 1

RE: Oh please not again.
by CaptainN- on Thu 17th May 2018 20:12 UTC in reply to "Oh please not again."
CaptainN- Member since:
2005-07-07

What BS though? 10 years ago, everything cool on the net was built with Flash, and then AIR let Flash run on iOS. Some banks and other financial institutions still use Flash/AIR based apps (oye). Today Flash is all but dead on the net, but is used for quite a number of native apps.

You know what? No one cares - and they are right not to care. If the app does what was advertised, people will use it.

Something will doubtlessly come along and dethrone JS, because it always happens - but it won't be something harder to use. It'll be something even more abstract, and even easier to build with.

Reply Score: 3