Installed electron / react, it has 1861 dependencies. This is a problem

I don&#x27;t really see the size of it all, or the dependency count, as a problem considering what Electron+React are doing. It&#x27;s a modern framework with its bundler, plus a browser engine with a bunch of wrappers for interacting with different OSs, and all the tooling necessary to build apps for Windows, OSX and Linux. That&#x27;s akin to downloading the salient parts of Xcode, Visual Studio, and gcc and complaining about how many dependencies they&#x27;re all built on. That probably runs into the tens of thousands. Modern software has many moving parts.<p>The wall of warnings, deprecations, messages, errors you can apparently ignore (fsevents and iltorb, I&#x27;m looking at you) is the real issue for me. I want confidence in what I build, and NPM does not give me very much at all. I&#x27;d be fine downloading 1861 packages if they all worked together properly without telling me there <i>might</i> be problems.<p>PS Colin - I think we&#x27;ve met a few times in the Town Wall long before lockdown. Hello from the other person on HN in the NE. :)

Continuing my morning rant on here a little ...<p>I&#x27;m an experienced developer, I have a pretty good ideas of what these boilerplate projects are trying to achieve. However, at the moment I&#x27;m helping Python dev get up-to-speed with web development.<p>They are creating a desktop app, and wanted to use MS FluentUI, a React UI component library.<p>I&#x27;m now trying to teach them JavaScript, webpack, TypeScript, React, ESLint, ... Help them resolve dependency issues. Explain bundlers, the various different module systems ... the list just keeps getting longer!

Electron is Flash for the Desktop.<p>History is repeating. Instead of investing into hard work and portability with programmers, the management decides to take the short part which looks cheap. The result are bloated, memory hungry applications which do not integrate well into the operating system and native toolkits. The last part is maybe not so much noticed on Windows but Linux and Mac users notice it. These companies save money with Electron and the customers have to pay with hardware, reliability and usability. In times of soldered main-memory the memory consumption is a huge issue for everyone. I recommend using native toolkits like Gtk, Qt or Win32 (currently maybe WinUI?) and using appropriate languages (language bindings for important languages are available).<p>Some nice application developers actually store data locally, therefore the applications are working fast and self-reliant. Imaging a chat application which doesn&#x27;t lag and doesn&#x27;t repeatedly load the conversation from the server just because you&#x27;re scrolling upwards. A little bit off-topic ;)

I think you&#x27;re conflating the problem of too many direct dependencies with that of too many transitive dependencies.<p>We go about the rest of our lives using abstractions through interfaces. Those abstractions use abstractions. e.g. To build and use a pencil there are hundreds or even thousands of transitive dependencies. From the wood and graphite to the rubber and metal, each of the inputs like axes to cut wood or to create those other components, and so on.<p>With software we just do a better job tracking the “lineage” of these transitive dependencies, so the numbers seem large.<p>The real problem seems to be the ergonomics of all the direct dependencies. The number of transitive dependencies wouldn’t matter if the direct dependencies were in aggregate ergonomic to work with.

I am really hoping efforts like Blazor Desktop allow for us to escape this kind of hell.<p>You can already build really powerful component systems by combining the current iteration of blazor with stuff like WebGL.<p>You only need to screw around with just enough javascript to interop the canvas from C# land. Then, from that point forward all you need to worry about is C#&#x2F;HTML (Razor) and CSS.<p>With this approach we have been able to construct ridiculously complex web interfaces that sit directly on top of some monster state machine implementations.<p>Think about the dependencies involved above in terms of vendors. If you do it right, you can answer to just Microsoft. I know not everyone agrees with doing business with them, but having a single vendor stack is so compelling in the B2B space when your customers are very security sensitive (e.g. finance).<p>There is always the concern of transitive dependencies, but SQLite is already inside your car so you probably have to trust that one by default... I&#x27;m open to arguments on others.

It may look brittle to a newcomer, but it in my actual experience it is way less brittle than Python, Java or C++ ecosystems. The size is mostly due to packages shipping three different module types in multiple flavors.<p>I am upset about having node_modules in my source tree, however. A global package cache should be a thing.

Has anything improved at all since the last time an article like this was posted?

One of the saddest things is that Electron is less portable than the old guard. Java GUI toolkits, wxWidgets, QT, GTK, even Flash ran on tons more platforms than Chromium&#x2F;Blink&#x2F;NodeJS&#x2F;Electron ever has.<p>Cross-platform development has always been difficult, and I&#x27;m not sure Electron really makes anything easier.

&quot;What Intel giveth, React taketh away.&quot;<p>(Updated for this decade.)

I&#x27;m more and more tempted to create a readable, minimalist document format that can be compiled into a binary file.<p>Web stuff and the dom is too cluttered, too many ways to do the same things, too much things should be made obsolete.<p>Js is also a bad language, js engines are monstrous, to ambiguous.<p>Flexibility is okay, as long as it doesn&#x27;t come with a high cost.

Electron is an abomination that should die as soon as possible. My solution is to never run Electron apps like I always avoided Flash stuff and don&#x27;t do JAVA.

If you want to have many dependencies, try React native development!

Try Qt. Save some memory too.

What is the solution?

&gt;this is a problem<p>I don&#x27;t see it as a problem, but rather a strong signal depicting the general quality of the entire ecosystem and why you should steer clear of the whole mess in the first place.