Hacker News Reader

It's a huge problem because when you consider what it's really doing (what people want from it) it's not much.

All people want from Electron is a GUI system that works on all platforms. In theory there are several libraries that do that but they lack the features people want (QT, GTK).

In a sane world, it will be a single dependency: the GUI library.

You have to be careful when you consider what the system is doing before you justify its complexity. It might be doing a lot of useless work.

For example, what does webpack do? esbuild has proved that webpack is useless and spends its time doing useless work. Bundling with esbuild takes a fraction of a fraction of a second, where as webpack can take anywhere from 30 seconds to several minutes. Yea, it's doing "work", but it's not the work you actually want to do.

All people really want from Electron is the render engine from Chromium and the V8 JS engine, but without the sandbox, so that it can access the file system and do a few other things.

How many of these hundreds of dependencies are contributing to that end? Very very few, if any.

The "modern" web frontend development environment is really bad. Making excuses for it does not help.

> All people want from Electron is a GUI system that works on all platforms

No. What those people want is web tech as a GUI library. That's two very different things.

A cross-platform GUI library with good customization and theming options and support for custom controls that isn't reliant on the (Google) Web Specs (w3c) is what's really missing from the ecosystem.

JavaFX meets that requirement.

A GUI app that uses JavaFX requires exactly one dependency: the GUI library itself (OK, JavaFX is split into a few different modules). Often you'll add a few open source helpers, e.g. if you want a Material Design theme.

> A GUI app that uses JavaFX requires exactly one dependency: the GUI library itself

... and Java.

Yes, that's true. A minimal runtime can be quite small by modern standards (~20mb) but it's not free indeed. Only C or C++ can be "dependency free" in this regard because it's the only languages where operating system vendors are guaranteed to ship the standard library with the OS. All others have to bundle.

Go is better in this regard because it doesn't even expect much from the OS: everything is bundled.

These days you bundle everything with Java apps too. Or at least that's the direction the JVM authors want people to go in (see: jlink and jpackage).

It's not a single binary like Go, but in practice that's rarely an issue. Most normal programs have more than one file making them up.

Chromium also comes with a lot of API's, for example webGL and WebRTC.

That's not necessarily a good comparison. Electron comes as a binary, so it already has all its own hundreds of dependencies integrated.

The dependency hell wit JS projects is real, and upgrading can become a major timesink and pain if you are not maintaining and upgrading the project constantly.

There also exists a surprising amount of ridiculously unnecessary packages that many worthwhile ones depend on.

One such example is `is-odd` that is hovering around 500k weekly downloads https://www.npmjs.com/package/is-odd

On that page there's a related project called is-even . I pray for maximum laughs that is-even depends on is-odd, and just negates the return value of is-odd...

Edit: it actually does! Hah!

https://github.com/i-voted-for-trump/is-even/blob/master/ind...

It's even worse in this case. Following the Github link, you'll get to an archived repository inside an org that the author created as a joke. In his own words: 'This is a joke. You'll only see this org if you are attempting to troll me about repositories I created when I was learning to program.'

It got in there and is now part of the foundation of tons of other projects.

Maybe it doesn't matter but at the very least this ecosystem seems very immature (in the psychological sense).

There was a lot of discussion about this when left pad broke the internet. One of the arguments for it was that it’s easier to reason about what a one line module does.

Until you have 2000 of them and can no longer reason what the system does or what the interactions between them are.

What definition of ”dependency” are you using to estimate that GCC has tens of thousands?

gcc alone doesn't. xCode, Visual Studio, and gcc probably do. Although I don't really know that for sure.

Okay, but still thousands for gcc then?

I bundle and distribute GCC for an OS distribution and I can count 5 dependencies for building GCC from source (not including a host toolchain), two of which are also runtime dependencies. That means if you're installing GCC, you also need to install binutils and a C library. GCC itself, of course, bundles a number of dependencies like the gcc toolchain driver, the cc1 and cc1plus compilers, the collect2 linker front-ender, plus a number of runtime libraries both for the toolchain and for bundling into the executable. If you're targeting C++ that adds a couple more runtime dependencies which can optionally be bundled with GCC. Of course, everything also depends on the host runtime.

Some OS distributions split GCC into multiple packages with interdependencies, putting for exaple the C preprocessor into a separate package from the compiler proper (which is odd, considering it's the same executable, but there are historic reasons).

So, an exact number of dependencies for GCC, depending on how it gets packaged for your development host, can range from 3 to 14 or 15.

Certainly not. I barely remember my LFS school project, but I don't think i installed more than a dozen libs for the second Gcc compilation (the one w/o the host system). And half of those libs were used for "make test".

I guess any individual function defined outside of main() can be considered a dependency, the question is just whether it's you or someone else who's in charge of maintaining it

You are correct that in Node.JS a module is just a function that can be re-used in more than one app. But as making a module is the only way to separate your code into several files and folders in Node.JS - Node.js developers also make "modules" that can not be re-used in other apps - so while one app depends on them, other apps can't depend on them and they are not published on the NPM registry... One cool thing about Node.JS modules is that you can import/require them inside main! So whether or not a function is in main or not only says how the developer likes to structure/place the functions. It's rare, but the best programmers I know likes to have all "dependencies" inside the same file - so basically they do not use any dependencies ...

> I guess any individual function defined outside of main() can be considered a dependency

No its not. I don't think even people naming their object list "DEPS" in their makefile don't think object files are dependencies.

Dependency count isn’t a good measure because different ecosystems have different default sizes to split something out.

Number of unique maintainers, on the other hand, is more consistent across languages and represents a real risk re supply chain safety, since compromising any maintainer is a route to a hack.

> Hello from the other person on HN in the NE.

Oh wow, small world! Looking forwards to returning to the Town Wall at some point in the future.