Hacker News Reader

Comment by brokegrammer | Hacker News Reader

1. Dependencies break your project only if added unpinned. Most modern package managers will pin dependencies for you.

Now, what if a dependency does break? Well, you can replace it with another dependency, or you can write one from scratch. Using dependencies allows you to save time earlier, and then only spend time writing your own libraries once you hit a roadblock.

2. Frameworks are similar to dependencies. They allow you to save time at the beginning of projects when you're not fully aware of your requirements, and then you're free to write from scratch when you have enough users and resources to do so.

3. Compilation is lightning fast these days because many tools are written in Rust. Projects built using Vite, for example, take a few seconds to build on a 10 year old laptop.

To summarize, these things don't result in websites that will require a lot of time and energy to maintain.

View on HN

I fixed my 10 year-old webapp yesterday. There were only a couple of easy-to-fix issues. I could've fixed them without AI but AI does help speed things up.

The problem is when looking at it 10 years later I want to rebuild it from scratch because the code and build system look so different than what we do now. I'm not sure yet if it will take a long time though, at least if I accept to keep jquery and avoid typescripting everything.

I could have built an web app in 2015 using C without any frameworks or build system. That doesn't mean I wouldn't want to rewrite it from scratch in 2025.

Rewriting things from scratch is something that everyone wants to do as time passes, regardless of the tech stack used initially.

Every pinned dependecy is a security vulnerability, sooner or later.

Once a dependency turns into a security vulnerability, you can either replace it, or write your own library like I suggested. It's more cost effective and time efficient than writing your own libraries from scratch for every project.

For example, I'd rather install React Router for routing in a React app instead of writing my own routing library. I guess some people will reply "grrr React, just use static HTML bro". Okay cool.

> Once a dependency turns into a security vulnerability

How will you know if/when that happens?

Are you subscribed to the development channels of all your dependencies? Do you examine every one of their commits for security fixes?

Your comment reads like someone who deliberately does not measure things to avoid confrontations against your conveniences and biases.

For example modern compilation may very well be faster than in the past, but your application and experience could be still even faster without compilation.

Frameworks also come at a substantial cost. They are highly restrictive, super massive, and almost always unnecessary. I can understand why people use them, but again your application and experience could be dramatically faster without them. People tend to prefer frameworks when they lack the confidence to build without them, but for those of us that frequently measure things large frameworks are always a net negative.

> your application and experience could be still even faster without compilation

I doubt it. Compilation actually improves developer experience and speeds up the process of releasing apps because you have a standardized way to release your app to production.

I seriously can't understand the hate against compilation because it's never been a roadblock for me, especially these days when most builds take a few seconds on slow CPUs. I guess it's cool to hate things for no reason.

> Frameworks also come at a substantial cost. They are highly restrictive, super massive, and almost always unnecessary.

This is highly subjective. Frameworks have been nothing but a huge productivity boost for me. For example, I can spin up feature-complete API using FastAPI in a few hours instead of spending weeks building my own framework to do the same thing.

> People tend to prefer frameworks when they lack the confidence to build without them

Doubt it. People mostly choose frameworks because they want to get work done instead of wasting their employer's money on non-profitable endeavours.

> for those of us that frequently measure things large frameworks are always a net negative

Could be that you're measuring the wrong thing. At the end of the day, engineers need to ship features so that the company can generate revenue. Frameworks are great at facilitating that process. I'm no Math expert but this seems like a net positive to me.

Engineers measure things. Junior developers say "doubt it" and guess at the results.

> This is highly subjective.

It is measurable.

At the end of the day actual engineers measure things. Junior developers deliver features.

I would love to see some numbers then. Until then, I'll just assume that using build tools and frameworks means one is a junior developer to be bogus claim.

> I would love to see some numbers then

Nobody is stopping you from gathering numbers. Again, that is the difference between an actual engineer and a junior developer.

Engineers who speculate about currently non-existent metrics instead of getting work done while shaming others for wanting to make progress should look for employment in academia.

Reply on news.ycombinator.com