>8gb RAM is becoming the norm, soon 16gb will be a defualt

Why is Electron so popular anyways? It's bloated even if you make a small application

>>61673537
>Why is Electron so popular anyways?

It isn't. Your assumption is plain wrong.

Moore's law states that the number of transistors on an integrated circuit will increase by x1.41 every year. However programmers get 1.41 times lazier every year. Eventually Moore's law will hit a wall and programmers will have to stop being lazy pieces of shit.

File: Screen Shot 2017-08-01 at 4.29.15 AM.png (87KB, 377x880px) Image search: [Google]

87KB, 377x880px

>>61673537
Because people are perfectly fine with shit like this. This is a "webapp" made in nativefier.
>well its OSX so of course its big.
It is only about twice as large as the windows one i made.
It also uses 130MB of RAM and 20-30% of my cpu (i7-2620m) to exist.

>>61673537
Because large companies are always pushing UI framework of the month that only works on their platform.

>a Javascript programmer could develop for ANY platform for almost ANY purpose.

But it'd still be javascript

>>61673625
Actually the windows version is slightly bigger, i forgot to include the entire folder of shit it depends on.

>>61673476
>a Javascript programmer could develop for ANY platform for almost ANY purpose.

That's great! We develop embedded systems. Mostly low-cost, mass production, control systems. The MCUs we use are usually 8 or 16 bits and sometimes have MULTIPLE kilobytes of RAM and flash memory.

If you think you can help us out with your javascript skills your hired!


No seriously, those architecture usually don't even have C-compilers available. And don't think this is an edge case. Your whole house is riddled with low cost embedded systems NONE of which are programmed with meme languages like JS.

It's striking that someone who thinks he's handy with just JS sees himself on top of the world while he's not even comprehending how big that world really is.

>>61673606
You will also have to pay the massively increasing cost of making anything better if you need it better.

Because it wasn't "laziness" but not getting a time/money budget to pursue smaller gains in efficiency.

>>61673654
>not using powerful cpus and gigabytes of memory in your embedded systems
its like yall poor or something

>>61673667

In fact, that's all YOUR fault. You don't want to spend an extra penny on electronic devices, so we are forced to develop electronics with $0.25 microcontrollers.

>>61673699

Just to add, $0.25 MCUs are actually much more fun to work with than, for example, multicore ARM.

>>61673721
this

>>61673654
no one cares about niche jobs.

File: rly make u thenk.gif (617KB, 498x498px) Image search: [Google]

617KB, 498x498px

When you really think about it, Electron is the best thing to happen to native application development in years, but for the wrong reasons.

Companies are making it as easy as possible to indicate that their software is inefficient garbage hacked together by mediocre hipsters instead of actual professionals. It's no longer a subtle failure, like the awful webshit UI that Valve made for their games. Electron is such a gargantuan pile of shit that it is impossible to hide.

>>61673788
>niche jobs

Do you have a washing machine? A Dryer?
Do you have a coffee machine?
Do you have a (microwave) oven?
Do you have a thermostat?
Do you have an induction/ceramic stove?
Do you have a refrigerator (admittedly full mechanical controlled ones are still produced).
Do you have an alarm system?

These are just examples of some house hold appliances. The list doesn't stop here.

>>61673964
What programming languages do embedded systems typically use? C, right?

>>61673964
My Lexmark printer is running some form of Android.
We're only a couple of years away from toasters doing the same.

>>61673980

I mostly use C or assembly. Sometimes we use Qt (C++) on higher end MCUs that have to render a GUI.

>>61673625
>newton
HAHAHHAHAHA

>>61673992
You're absolutely right. ARM cores are getting cheaper and cheaper ($1.5 for a Cortex M0 with integrated BT and Wifi) so high level languages like C and C++ are most popular now.

Still I expect low end 8-bits MCUs to survive a little longer. As long as they are still a few cents cheaper then will be used on mass production were possible.

>>61674042
>high level languages
>C

>>61674052

C is a high level programming language because the compiler takes care of the hardware specific problems. There's a lot of abstraction between C and the assembly the compiler produces.

Fuck off degenerate, just because you have resources available to you doesn't mean you absolutely have to have your shitty 3 line program gobble them all up. Ever heard of writing efficient code?
>inb4 brainlet ecks dee, how do you not know *obscure devfag shit*
I'm not a dev but I have to use your shitty programs, deploy them and then have employees bitch at me "becuz mai pee cee is 2 slow"

>>61674095
Sure, but C is used on the low end MCUs, too, not pure assembly.

>>61674150

No offense, but could it be that you are confusing low-end devices with low-level programming languages?

C (high level language) is indeed used on low end devices as well. Mostly actually, if the resources permit it and timing isn't crucial.

>>61673964
bringing many examples doesn't mean the job itself isn't niche. for every ES developer there are 5 enterprise Java programers and 10 web developers.

>>61674210
C is hardly considered a high level language by today's standards, simply being able to manipulate memory at all makes it low leveled.

Eventually maybe JS could be precompiled and optimized the same way Android's ART can usually produce "as-fast-as-C" binaries from Java these days.

>>61674479
This

Embedded is a dying breed and will eventually exist mainly as a hobby. Household devices will run full oses soon ala raspberry pis in your fridge, mainly because ignorant IT management

>>61674517
I guess every field has it's own definitions of high and low-level languages. Direct memory manipulation is indeed pretty low level, although this is practically the only low-level thing C can do natively.

>>61674517
The technical definition of a high level language means C is high level because it is compiled.
Look up high level language and C is one of the first examples.

>>61674568

>Embedded is a dying breed and will eventually exist mainly as a hobby. Household devices will run full oses soon ala raspberry pis in your fridge,

Household devices already run full OSes on devices like rpis. That's exactly what embedded systems are.

>mainly because ignorant IT management

If IT management runs your product design a company will go bankrupt. It's about costs. Nothing more, nothing less.

>>61674565
JavaScript is as fast as it gets. It's "slow" in the browser because people use it to modify the DOM. Atom is "slow" because it relies heavily on the DOM.

>>61674565
Good luck compiling eval.

Yesterday I booted on my netbook with XP and 1Go of RAM.

Everything is faster than anything running Win7, 8,10 or "modern" linux distro...
What went wrong ?

>>61674719
Devs forgot how to optimize programs.

>>61674689
Javacript can't be fast.

>>61674807
It can if you aren't using DOM. Even canvas is better, and without graphics, just number crunching, it's faster than most scripting languages.

>>61674905
>it's faster than most scripting languages.

Moving goal posts I see. . .

>>61674934
Performance is obviously not C-level but on the same order if magnitude. What else do you want?

>>61673537
Because it's a decent choice for cross platform desktop programs.

I don't like electron apps at all, I much prefer a program that feels native, but the options for this are limited.

As far as I understand it's either C++ and Qt (which has a costly license) or Java and Swing/JavaFX that are the alternatives if you want cross platform.

>>61673537
I wish Electron apps detected a already installed Chrome runtime, like .NET or MSVC. 40 MB bloat is suffering.

>>61673964
they are mass produced, but the development is small, so

N I C H E J O B
I
C
H
E

J
O
B

File: captain planet.jpg (25KB, 563x446px) Image search: [Google]

25KB, 563x446px

>>61673476
ALL THIS POWER WASTE! YOU'RE WRECKING THE PLANET!

QUICK PLANETEERS! SET ORACLE ON FIRE BEFORE IS TOO LATE!

>>61674992
>Performance is obviously not C-level but on the same order if magnitude.
For trivial benchmarks. For actual software it is behind the JVM.
Because with JIT compilers you can pick one of:
1. designing the language in a way that doesn't require too many guards, tracing and recompilation (like Julia does)
2. don't do much optimization at the cost of performance (LuaJIT and most JS engines)
3. optimizing for throughput and taking the JIT latency hit and horrible warmup times (most JVMs, PyPy(still slow, lol), overly dynamic scripting languages using a LLVM based JIT)
>What else do you want?
Something that can be to-go/online compiled (basically AOT, but in the process to inject in your memory) without JIT overhead during runtime at all. A zero latency solution. That might be possible with WASM, once it gets direct DOM access and GC. However, there is still the browser environment in the way which is the biggest problem in the first place.

>>61673654
I don't want to work for peanuts. Sorry buddy.

>>61673964
Many of them are already IoT devices running JS...
As for the non-cancerous devices, that's an EE job and >>61676817 applies.

>>61676861
Humanity doesn't think long term. That means, the best you get is more power saving hardware running bloated browsers until the climate system collapses or we run out of power.
Given the unlikely case humanity survives that and doesn't fall back into killing each other with sticks and stones it will fall back to very low power communicators using LCDs and two digit megaherz CPUs.

>>61673476
I put my hope on Qbrt though.