I'll just have vanilla thanks.
- not having to update due to issues in dependencies of dependencies of dependencies
- not having to rewrite it all because framework maintainer decided to shift to a new paradigm and no longer maintain the old version
- not having your massive framework generating weird request flow that isn't defined in any RFC and can't integrate with industry standards
- not having to pay for specialised hosting because only one or two companies know how to properly host and scale a website built with your massive framework
- being able to integrate or understand actual web technologies because you don't have a massive framework abstracting it all from you
Some frameworks or libraries may have been designed with some of this in mind. If you want to scale and integrate with other stuff, pick wisely because your whole code base will end-up tied to that framework, especially if "full-stack". Tho I have to admit developper experience can be awesome.
* having code that is more than an order of magnitude smaller and even faster to build and execute.
* working with developers that can actually program and aren’t super afraid of state management, APIs, DOM, measuring things, test automation, and so much more. I really get tired of hearing about reinventing wheels by people who cannot create wheels or drive cars.
This is if you’re using JS. If you’re building your application in something like GO only using the standard library and writing all the JS you use yourself, then you’ll have almost no external vulnerabilities.
I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now. The most known example is Log4j, but there have been many other examples. This is made even worse with how attacks are done today, which is largely automated. So if you use an extremely common technology which turns out to have vulnerabilities then you’re also going to be far more likely to be attacked.
Because it is not vetted. These dependencies are run through multiple checking tools day by day. You will get automated alerts for dependencies, which you can then easily patch. There is an entire industry behind checking for vulnerabilities in public libraries. The best incentive for something is and has always been money.
You have neither of this if you roll your own entirely.
> I know it’s common in software engineering to rely on others to be your security, but this has proven to be a terrible idea so many times by now.
This is a false equivalency. Log4j was found, publicly discussed and was subsequently patched.
The surface attack is considerably reduced if you do not rely on a large list of dependencies. Moreover, you do manage to know _better_ the ins and outs of each bit of your system (because you wrote it, and the whole surface has been walked on at least once).
Unless you are of a specific interest to an attacker, not relying on external dependencies makes you less detectable as your app may not behave as scanner expect it to.
It's a bit like comparing going on a trip by walking with one person you know well or with 100 people: you still get to make the trip, but, the delays, the risks, the provisions, the contingencies, the consequences of an incident are not really in the same scope.
But for any large project involving more than 4/5 people, perhaps relying on no external dependencies may be a bit complex to manage in the long run.
This only holds if you work only for yourself.
> Unless you are of a specific interest to an attacker, not relying on external dependencies makes you less detectable as your app may not behave as scanner expect it to.
Another argument can be made that you're investing too much valuable time into things that have been solved before - and likely better than a single person could manage.
> But for any large project involving more than 4/5 people, perhaps relying on no external dependencies may be a bit complex to manage in the long run.
In my experience, this is true for any one project with more than one (1) developer, even if the developer might change in the future. Any junior front end developer can be productive in a years old angular project. They might not be in a custom dependencyless project.
I think Node may be a lot worse than this, but looking at two Django projects, one on which I have really kept dependencies to a minimum and one I feel has two many dependencies I get 9 and 74 dependencies respectively.
This is not what the author was suggesting. The author is suggesting that, more people using an open source piece of code has a higher chance to be revised which ultimately would lead to a better security.
When most people make this argument the suggestion is that popular software must be more secure because somebody would have certainly identified and reported the vulnerability. That makes several assumptions not qualified by evidence. In other words it’s wishful thinking.
As a case in point when I reported my first V8 defect it was around the time of Node 4.4. Chrome had been out for several years at that point with many millions of users. The defect I found was that V8 could not perform recursion using only function name. WTF. The problem was missing test cases, not a lack of eye balls.
“Two open source maintainers are walking along the street when one says:
Look! A repo exposing an API allowing unprivileged deletion of users!
The other replied: that vulnerability clearly cannot be real, as someone would have fixed it already.”
I see this argument as “it’s not my job” type of argument.
Most of the time you just install and use. If I had infinite time, I’d do it because it’s fun but I don’t so I don’t.
If there’s a trust chain and I know for sure certain libraries are reviewed I’d have a peace of mind. Alas, that’s not the case and we spend our days in back burner paranoia or blissful ignorance.
I also don't see how this is related to, or disproves, anything I said...
I also follow this approach with my operating system. I'm tired of vulnerabilities so I'm writing my own.
In Comments
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Please don't fulminate. Please don't sneer, including at the rest of the community.
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
I doubt you could write your own OS if your life depended on it though.
Are you really coding web applications with plain Python or plain NodeJS? Does vanilla mean there are no dependencies?
Getting all the way to 0 dependencies can be tough depending on what you're building, and maybe not worth it. But it's a great feeling when it happens.
What's more important than how many dependencies you import is the quality of them, how well they fit your project (using a high percentage of the library's functionality is a good sign), and the total number of transitive dependencies.
One thing I do sometimes is using git submodules for dependencies. It's annoying to work with, but that friction helps me avoid importing too many things on a wim. It also encourages me to use dependencies that are self-contained.
Exactly. I've been there with vanilla js projects. It doesn't make any difference whether it's been written by me or by another engineer.
It's a nauseating experience. There are little if any conventions. You can't trust any APIs if you've not read what they do exactly.
I will never understand this sort of purism on HN. For any medium web app, by choosing a framework, you will move the mental load of maintaining and bike shedding to thousands of other engineers, leaving you to do the actual work.
Suppose you chose a framework. Suppose you were unlucky in your choice. Let's say you chose Angular.js in 2014... only to discover in 2016 that something called Angular 2 is coming out, and that Angular.js is on its way on being discontinued, and the migration story is horrible...
Or suppose you chose Backbone in 2012, and then by about 2015 it kind of died...
Or suppose you chose Meteor in 2013. It was quite popular then... until it wasn't.
Or suppose you chose Aurelia, which had its moment somewhere around 2015 or 2016, when Rob Eisenberg was promoting it taking advantage of the dreaded Angular migration story and of a sneaky clause in the React license. Yeah, it's dead now.
And so on and so forth. At least what you write yourself, for the specific purposes of your application, lives as long as the application itself, and is as fresh as ever.
I was also maintaining Backbone projects.
> And so on and so forth
The web space needed some time to settle down, I'll give you that. The web as we know it is really only less than 20 years old. Technologies took a similar time to settle back when we chose between C, Fortran, Ada and Java (the new kid on the block at the time). If you were _really_ cool, you may also looked into Python.
Engineers had similar discussions back then.
Nowadays, choose React, Angular or Vue and you will have no problems maintining projects 20 years from now.
A more real recent example is this app at work: https://github.com/iobio/bam.iobio.io
That repo is currently unmodifiable due to dependency deadlock/hell. As an experiment we tried re-implementing it as a vanilla web component app. The experience was immediately so pleasant that we committed to that course. We're almost finished. No regrets.
If you want to compare them side by side:
old: https://bam.iobio.io new: https://bam2.iobio.io
This is a relatively simple app. Just a couple pages and a bunch of d3 charts which we only needed to make simple web component wrappers for.
YMMV.