Hacker News Reader

Comment by mcv | Hacker News Reader

I have a tendency to prefer writing my own library for something instead of relying on someone else's. Not always, obviously, but quite often existing libraries fall short or are too complex to use. And solving the problem myself is almost always an educational experience.

For example, I'm currently writing my own graph layout library because I'm not happy with Dagre and ELK.

View on HN

Also, your own library, at this point, is much less of an attack vector than some dependency from a package manager

From maintaining dozens of projects over decades: yes and no.

Your custom library probably won't fall to a library-specific attack unless you were actively aiming for interoperability. However your custom library almost certainly has many vulnerabilities that you haven't heard of yet. Just a few weeks ago I saw a custom library (PHP) with SQL injection vulnerabilities, I couldn't believe it. I suggested to the client that if he still resists having another professional audit it, at least let some frontier LLM have a look. Yes, I recommended this guy to vibe code his security-sensitive code because "professional developers" today still miss the basics.

> I suggested to the client that if he still resists having another professional audit it, at least let some frontier LLM have a look. Yes, I recommended this guy to vibe code his security-sensitive code because "professional developers" today still miss the basics.

Amen. Nowadays it is borderline malpractice to not use a coding agent for checking the security of your code.

They're referring to supply chain attacks. Taking over open source libraries through social engineering and adding hidden malicious code. Becoming increasingly common.

One could disable updates of dependencies - especially near-real-time updates. Just updating a week after everybody else will have a lot of potential harm with libraries that have a large user base.

If I could have a dollar for every casual strcpy in my DIY libraries I would be a rich man. And would never dare to put them in the line of fire of unwashed Internet :-)

I was more concerned about supply chain attacks, along with the idea of stripping down all dependencies to truly just what you need.

Need a few math operations? pull those in, instead of an entire math lib, for example.

This is an excellent strategy. Don't the front end guys do this already?

Same as people often say about AI writing bespoke applications, these days... Libraries (like applications) often have 98% stuff you don't need, and 2% stuff you do. You can end up better off with your own thing.

I've always liked writing my own libraries and minimal frameworks for PHP, which seems to be a very unpopular opinion, but it almost entirely removes churn from your stack, which is nice for tools that may stick around for years or decades. I also never switched off jquery, preferring simple techs. I'm almost definitely operating at a smaller scale than most web developers here, though.

I've gone back and forth on this. I've been burned with third party libraries, but I've also been burned spending so much time/effort maintaining my own library that I can't get the real job done.

Same, for sure. I'm not actually sure I've come out ahead. I've probably wasted at least a year of work in each direction.

In spite of my above-stated preference, I used Django for my most-recent project, and don't regret that decision a bit.

LLMs will easily exploit it these days.

For personal projects that's fine, but I'd absolutely hate to work with someone who is rolling their own libs for everything, and then when they leave the company puts an enormous amount of tech debt into our hands. It also really doesn't make for good team-work if a developer always forces their own opinion on everything.

In a team environment, those libraries also should be team developed, at least, assure a minimal understanding from other team member.

+1 if they litter their own macros on it too

Reply on news.ycombinator.com