Installed electron / react, it has 1861 dependencies. This is a problem
twitter.com
twitter.com
The wall of warnings, deprecations, messages, errors you can apparently ignore (fsevents and iltorb, I'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'd be fine downloading 1861 packages if they all worked together properly without telling me there might be problems.
PS Colin - I think we've met a few times in the Town Wall long before lockdown. Hello from the other person on HN in the NE. :)
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.
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.
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.
... and Java.
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.
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.
One such example is `is-odd` that is hovering around 500k weekly downloads https://www.npmjs.com/package/is-odd
Edit: it actually does! Hah!
https://github.com/i-voted-for-trump/is-even/blob/master/ind...
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).
Until you have 2000 of them and can no longer reason what the system does or what the interactions between them are.
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.
No its not. I don't think even people naming their object list "DEPS" in their makefile don't think object files are dependencies.
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.
Oh wow, small world! Looking forwards to returning to the Town Wall at some point in the future.
I'm an experienced developer, I have a pretty good ideas of what these boilerplate projects are trying to achieve. However, at the moment I'm helping Python dev get up-to-speed with web development.
They are creating a desktop app, and wanted to use MS FluentUI, a React UI component library.
I'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!
Creating a desktop app isn't web development, it's desktop app development.
You've got to teach web dev from the basics outwards. We (developers) have taken a platform for "document" delivery and layered it with tools for app development. Teach it this way. Start with simple content - including a little style, enough layout to get going, some rollovers or form helpers, and basic accessibility. Then talk about templating (static sites, or server-side apps). Then talk about single page apps. Then talk about desktop apps.
I agree there's more complexity than there should be, but you also dump them in the most complex stack that can be dreamed up in the field.
e.g. embedded development is difficult, but Arduino makes starting out more accessible. Beginners are able to get an LED blinking on a development board without needing to understand all the details.
While expecting to fully comprehend all the complexities of some unfamiliar system is unreasonable, I think it's reasonable to hope for a development experience where what you need to know to be able to contribute is covered by a small surface of well-made abstractions.
you think that e.g. Telegram or MauiKit apps don't look modern ?
(Also, while React is my go to web framework because I’ve learned it well from necessity at $DAYJOB, it’s not particularly modern.)
As I see it, people with genuine desire to learn don't see details such as "number of dependencies" or "linters" as impediments to anything at all.
I think teaching people all that, all at once is the actual problem, not that all those systems are not impeccable (which they aren't). Maybe as developers we should figure out what are the things that are truly important, and draw the line at that, and then treat the rest as optional.
I truly wish that things we do are simpler, but they are not going to get better by wishing. But even that is not my biggest grief, it's that the pain is often self inflicted. Developers love using everything possible and making everything into something they can't live without (in part because it's a way to look down on people that don't know or use something), but it's not true. So, ESLint is a great tool, but a beginner does not need to know about it. I think you do need to suffer a bit before you can appreciate a tool like that. Webpack is a... well, it does things that we need, but a beginner does not actually need to know what goes on when they run their dev server.
Slim things down and it's fine as long as they're still doing the real thing. Kids don't go to school and start with the square root of a negative number. They don't even teach them what a negative number is.
If you want to make a web page or web app fast, with good performance, easy maintainability, small in size/bandwidth, and superb hardware support - go with "vanilla" web components. If you want to follow the latest fashion in web development and have a cool resume then pick a framework (but make sure it's not the most mainstream/enterpise - that's not as cool)
For example, electron includes Chromium, which includes a number of copyleft-licensed libraries... In order to fulfill the license obligations, complete corresponding source code for these libraries must be accompany (or be made available) for each electron app.
pip install mypackage
I've been a developer for some time now. All I know is a lot of developers love unnecessary complexity. It's even more true in the JS world to be honest.
Javascript modules were supposed to make everything easier yet some people still manage to write insane boilerplates and tools on top of that and bring back complexity where it is not needed.
The issue with blind use of pip is that it will inevitably break something in your system when a dependency upgrades too much. Hence virtualenv, and later pipenv.
And setting up a Python project is more than just dependency management. Do you want an egg/wheel/etc? Do you use setup.py, or is it deprecated? Speaking from experience, the docs for various Python tools simply don't agree on these things, and it's very hard to set up a project "correctly" without someone helping you.
The fact that a container is easy today just enables and hides the fact that it's a bit ridiculous to need one for half of the things we now use them for. Same for snap, flatpack, appimage, etc.
Rather than have a handle on my surface and interface with the os, I'll just bundle an os with my calculator app.
All because they're using a newer version of some library that maybe has an extra param on one function to automatically zero-pad or something.
And "they" isn't necessarily the developer of the calculator app but could be the developers of any of the hundreds of dependencies.
We all know all the excuses how we got here. We all know how each individual step along the way has it's excuse. Yet, it's not a great place we got to.
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).
Some nice application developers actually store data locally, therefore the applications are working fast and self-reliant. Imaging a chat application which doesn't lag and doesn't repeatedly load the conversation from the server just because you're scrolling upwards. A little bit off-topic ;)
I agree with this point of view for bigger companies that do chat and music streaming apps. Nonetheless if you're a __much__ smaller company who needs to do cross-compat. applications and has problems hiring personnel (either due to lack of, or too expensive) technologies like Electron saves them a lot of trouble, money and time...
You are aware that ECMA exists? And that JS has been updated quite a bit to align with modern use cases.
This is a bit of a bizarre argument. When using a chat app on a web site, your browser downloads the source, unpacks it, then executes in a runtime on your machine. You're doing the same thing, otherwise the app wouldn't work.
You also had to first download and install the web browser used to download and install the chat app.
Imagine letting a web site decide what features I should have in my chat client.
When I can update my web client every day with a new feature, the advantage of not having an open standard is higher, I can invent new features in days rather than the years it's taken IRC to add things
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.
With software we just do a better job tracking the “lineage” of these transitive dependencies, so the numbers seem large.
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.
Even in the "real world" overly complex and distributed supply chains are a source of problems - and much the same problems as sprawling dependency trees: They are the cause of unnecessary environmental pollution (by shipping components around the world for purely financial or organisational reasons), they decrease transparency (because it's difficult to understand what kind of companies at the very end of the supply chains actually produce your parts) and they introduce risk of failure.
As with software abstractions, those are problems that are easy to ignore by the designers of the end product, until they hit. We're getting more aware of those risks by now, thanks to COVID and geopolitical tensions putting stress on supply chains.
As a dev, it's important to remember that abstractions are a tool, not a mechanism for responsibility washing. When you develop a product, you're responsible for all code of it, not just the parts you wrote yourself.
Such as pertinent real world parallel. Although, it seems that today, the global supply chain seems to be suffering from a "leftpad" issue when it comes to electronics as a few factories in Taiwan and South Korea produce chips used almost everywhere, and some of the factories are in trouble for various reasons.
You can already build really powerful component systems by combining the current iteration of blazor with stuff like WebGL.
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#/HTML (Razor) and CSS.
With this approach we have been able to construct ridiculously complex web interfaces that sit directly on top of some monster state machine implementations.
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).
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'm open to arguments on others.
I really hope Microsoft realises the only place for Blazor are PWAs.
I am upset about having node_modules in my source tree, however. A global package cache should be a thing.
My team wasted a lot of time finding version of node/npm/yarn that works on CI and on all developer machines. Purging whole node_modules and installing everything again used to be weekly occurrence. It is much better now but poor design of JS ecosystem still makes me nervous when I have to update node, npm or bigger dependency.
I'm not saying nothing in the ecosystem ever breaks. I'm saying that despite it being unstable, it is much more resilient than it is brittle. It does look crazy at first glance, you have to experience it to believe it.
Everyone wants a free ride: beautiful modern UI, fast, easy to use, cross platform, free.
If it’s so bad, why is it getting worse?
…because people like free stuff, and no one actually wants either a) a crappier (but better tooled) solution or b) to pay for a better solution.
Its not that no one cares about these hard problems… it’s just that no one actually cares enough to be more than complain about it for free.
It is what it is.
The chances that it will magically resolve itself without a major shift in how developers build things is zero.
The problem isn’t the frameworks.
It’s that people use them.
Windows keeps getting worse and worse. People pay money for it, and yet Microsoft is putting ads in it.
So clearly the problem is not limited to people wanting "free" stuff.
For example, hapi (https://hapi.dev/), a feature comparable web server framework to express, has zero external dependecies.
There are a lot of responsible maintainers of great packages in the node community which keep dependencies to a minimum. It's up to the consumers to use and value them, not just default to the likes of express.
There is esbuild which help eliminate webpack hell, but most shops still use "Create-React-App".
There are some lite weight alternatives to React (like Preact), but most shops aren't using them yet.
I can't really think of anything else that could count as an improvement.
Cross-platform development has always been difficult, and I'm not sure Electron really makes anything easier.
(Updated for this decade.)
Web stuff and the dom is too cluttered, too many ways to do the same things, too much things should be made obsolete.
Js is also a bad language, js engines are monstrous, to ambiguous.
Flexibility is okay, as long as it doesn't come with a high cost.
That runs counter to the usual JS ecosystem philosophy of delivering almost nothing and letting everybody make up their own. That's a fun environment for hobbyists exploring and cobbling things together, and a pain in the butt for professionals trying to get work done.
It would be a huge amount of effort and everybody would hate the result, so I don't see anybody rushing out to do it. Instead, we get this: a framework that installs a large subset of the entire NPM database every time you start clean. As a framework it mostly hides that ugliness, unless you look at the install process and ask "Why is it so noisy?"
All individual developers should recognize and avoid things that lead to this state.
All or at least most should have a common sense of what is good and what is bad, what is attractive and elegant, what smells.
That is not something you can dictate. It has to be something the majority simply recognizes and agrees about, so that they create less of the bad things, and every new developer absorbs the same sense from their childhood googling, the examples set by indisputably valued projects, and school & co-workers.
Right now some of the most valued projects set some of the worst examples.
It has to be cool and admirable to be efficient and robust, and right now it's not.
There is just no way I see to bring this about. You can only do your own tiny part and wish for the rest of the world to improve. Unless you run google or other huge body of coders, you can't change the entire culture. It just changes over decades however it will.
I don'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.
- Node.js std lib is paper thin. You can't even parse a http request multipart body without bringing in a separate package...
- NPM has always been a mess, but it's seems it was all by design in order to make node.js depend on that (commercial) package manager.
Node.js creator biggest regret was its dependency to NPM.