Biggest tech cancer of the decade (2010-2019) awards are held soon

Biggest tech cancer of the decade (2010-2019) awards are held soon.

What do you nominate?

Attached: 500px-Electron_Software_Framework_Logo.svg.png (500x500, 39K)

Other urls found in this thread:

Why is electron cancer?

Attached: 1200px-Tux.svg.png (1200x1414, 259K)

Smartphone Cameras

Jow Forums maybe?



Attached: Check-your-priorities.jpg (600x550, 47K)

Why in the world would you need to distribute Chromium with each of your apps? Who thought it would be a good idea?
How can lightweight terminal app take up to 200 MB straight from the start?

Attached: 1555532707162.png (1920x1080, 156K)


Attached: 1550425585034.jpg (645x729, 57K)

Attached: cpp_logo.png (918x1032, 45K)


>Why is electron cancer?
it gives noobs like me the ability to write cross platform software that looks great and just werks.

It was more of a case of "it was easy to do and solved the use-case of web devs not wanting to learn a new languages or GUI libraries but still wanting to make """native""" apps."

It's also somewhat built off of the myth that because google made V8 that this stuff will inherently run as fast as native stuff. Without realizing that in order to make that even be close to true you need to put as much time, effort, research, and development into making Electron as was put into V8.

And someone's probably putting forth the effort somewhere. But Electron is a not that product.

You just made it sound good. Congratulations.

OP can't afford RAM...

This is the solution to Conventional 'executables, separate address spaces and a shell' operating systems always lose in functionality to abstract dynamic programming environments. Emacs could've saved us, but you thought you needed one good utility for fetching hypertext from a remote system and you got a third userpace operating system in return.

X as a service.
Anyone that says otherwise is literally brain dead.

Why'd you post a selfie user?

Attached: 1549090394646.jpg (1080x1080, 148K)

Attached: chrome_32x32.png (32x32, 2K)

Welcome to the service economy. Code is alive. Requirements are flexible. Taking 4 years to release a product is unacceptable. You can do things right and be irrelevant by the time you come out. Or you can do things fast and fix mistakes as you encounter them.

A few tech companies have the luxury to put 50 of their top devs in a room and wait 5 years for them to pop out with something great, new, well-built, and game-changing like V8. But very few.

Yeah dev cycles have changed what's new, that has literally nothing to do with X as a service though?

That's entirely what software as a service IS. You're not buying a product, you're buying the service of it being constantly developed in addition to the operational costs of supporting it.

Once upon a time companies released versions of products that you would buy and own and then they would release new version of a product that you would have to buy an upgrade to or not get the new features.

Now they have a single product which they continually develop and instead of a model of ownership and forced obsolescence, instead they charge a subscription.

That has nothing to do with development cycles still. It's a move to make the most money humanly possible to appease shareholders and it's leading to exactly the shit you described. The dev cycles of half finished garbage at best is a result of SaaS not what caused it.
And there is more than SaaS, there is hardware, infrastructure and whatever cancer they will shit out next.

it put boomer native devs after years and years of learning, reading tons of docs and developing in C++,C,C# back into their 70+ yo parents' basement like old useless dogs

it can't get any more pathetic

I want an Emacs front end made with Electron

It's runs a program in a hoisted-up version of Chrome with a few more permissions and access to some windowing options. On top of all of the JIT-compiled javascript tangle of RAM, you can imagine what it'd doing with discarded UI components. Building them 100 times a second with all the properties a DOM object could possibly have, then caching the dead ones regardless of it it's even possible to access them anymore, in addition to having very little to no sense of what is active at any given moment, thus achieving the two-pronged goal of being heavy on RAM _AND_ taking forever to load if you haven't looked at it in a while since it's all in deep-cache page file locations (even though it could be simply reconstructed in a fraction of the time).