Creating an app is one thing. What I want to know is what's the update experience like 3 years later when I haven't touched the code in forever and I'm getting a flood of dependabot notifications about critical vulnerabilities.
- 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.
I can relate to working with devs who actual knows about web technologies and are not afraid to learn about stuff outside of their framework-provided comfort zone.
Im in this phase right now, I used gatsbyJS and netlify in my last projects and things became unmaintainable and difficult to upgrade after a few years, am in the process of just doing a complete rewrite where I have more granular control over everything regardless of framework / business corporatization
Your vanilla app will have the same vulnerabilities, but you just won't know, because there are not thousands of people checking your code constantly. Not knowing, and not having vulnerabilities are two very different things.
I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies. Even if you still use Node/Bun/Whatever as your core but then build your own app with no external dependencies you’re going to reduce the security risks you have greatly.
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.
Front end is tricky, but is less security critical as you should not trust the client anyway.
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.
> I’d like you to elaborate on how an app with no external dependencies has the same line or vulnerabilities that an app which pulls literal thousands of external dependencies.
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.
That depends a lot on how complex, large and critical your app is. And on the skills of the builder and the maintainer.
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.
> 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).
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 a vanilla project will have fewer vulnerabilities, not more. Most of the vulnerabilities in frameworks are in the very complicated build tooling or deeply nested dependencies. A vanilla project doesn’t have that, so there are entire classes of vulnerabilities that don’t occur there. Vanilla does come with a higher risk of XSS, but basically all you need is a templating function that does XSS defense like lit-html and you’re good to go.
I suppose that you are not writing your db driver from scratch and you are using a driver that was at least written in the last 10 years, so it will support for sure prepared statements and you will use it, that means no possibility of SQL injections.
Having a very tiny app helps. In 30 lines of JS I couldn't implement a small data structure. But if you're building a front-facing app for consumers then public opinion is the judge of whether your app is emotionally delightful (more important than useful).
Technically obfuscation is perfect until it's found. And many times it's never found (the same is true for passwords in general, you could argue that's a form of obfuscation). For example who would ever find a compressed file that masquerades as completely unrelated and harmless looking plain text that was made with a custom dictionary? I think it's more about how good the obfuscation is rather than it being used at all.
This has been disproven many times. Way back in 2010 it was demonstrated that any 14 character password with special characters could be guessed within 10 seconds using a rainbow table. Likewise obfuscation only hides defects from people, not bots, which only serves to speed compromise and slow resolution.
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.
Who checks dependencies other than the author of the library ? The only time I check them is when they break and that's not a good thing.
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.
This argument comes up super frequently. Yes, more people actually reading the source code is better for identifying security vulnerabilities, but that almost never how it’s either articulated or implied.
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.
Exactly!. Why use a library when you can write everything from scratch yourself. That for sure won't have any bugs or security issues and will be super easy to pick up by the next dev.
I also follow this approach with my operating system. I'm tired of vulnerabilities so I'm writing my own.
Aw guys sorry. I used to be a virologist but now I am an expert on war and geopolitics in about a dozen countries. Gotta do what you can to keep up with the Twitterses. Best of luck with that whole medicine thing though!
Don’t forget to become an organic chemist. What does big pharma know about drug development and production? Plus, it means all my vaccines and medications are Organic and Homemade. Those words definitely mean “better” in all cases.
Going vanilla (assuming it's built of sufficient quality) will save you untold amounts of headache and cost. The bloated dependency stacks and unnecessary breaking feature churn in a lot of these libraries are just a waste of money and time for most organizations.
I mostly use Golang, but you could do Python or NodeJS if you wanted. I would probably prefer Deno since node's HTTP functionality is a bit low level.
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.
> What I want to know is what's the update experience like 3 years later
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.
> 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,
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 still writing and maintaining Angular JS projects in 2020, when I left my old job. It was a worse option than Angular 2.0, but it still worked fine. The documentation still existed.
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.
I tend to use git submodules to vendor into ./lib. It's rather clunky to work with, but once you know a couple commands it works pretty well. As a bonus, GitHub pages recursively clones submodules automatically. If you're using ES modules, you can host a site with no build step (ie github actions) directly from your main branch.
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.
I'll just have vanilla thanks.