Hacker News Reader

Comment by thehappypm | Hacker News Reader

Mechanical engineers don’t attempt to have “one part that does everything”. Maybe we should think more like them.

Libraries over frameworks. It's that simple. Frameworks always make something hard the initial authors didn't think about. That happens a lot. Libraries provide some small set of well-tested functionalities, which you can replace if they don't serve you well.

Every framework I've worked with had some issues, and because it's a framework it becomes a herculean effort to switch to something else. If it's only a single functionality that's much easier.

While I agree, I always find picking tens of libraries for a project and making sure the dependencies work out to be somewhat difficult.

What would be the way to orchestrate those libraries? Some sort of orchestration library?

I think "orchestratability" is a property of a library. If you start using a library and you find it hard to make it play nicely with other libs, it's probably not a well-designed library.

So you introduce a layer for interoperability. And now your library perf has tanked.

I don’t see how this comment makes sense in context. Surely GP isn’t suggesting that you include an additional tool to orchestrate library dependencies, but to choose libraries that don’t have complex dependency burdens.

If you want two incompatible tools to work you need an abstraction. However because of extra layer of abstraction you suffer performance loss.

> Libraries over frameworks.

I currently maintain a minimalistic website, and using a static site generator has been golden.

I consider that a framework. The moment I need to do anything the framework author didn't think of, I'll end up spending hours. But because I make so few changes, the bulk of the website content is Markdown, and the very limited styling is done with the HTML/CSS templating system. Basically, because this website is a low priority, anything that proves complicated is a bad investment. A framework is great here.

The problem with this is that either you use a framework or you end up writing one ad hoc using your libraries.

Say you use a web server library to help you handle requests on the wire, you’ll probably end up writing something generic where you set up a server, and pass in just the application code to receive the request and return the response which the library will send back.

You just wrote code that surrounds your application code — you made a framework. Then you realize that handling things like logging shouldn’t be in every handler so you invent middleware, you realize that your big ole block of app code is actually lots of small ones in if statements about the path so you factor that out and invent routes, etc. etc.

> or you end up writing one ad hoc using your libraries.

I hear this argument a lot, but I don't think it really ends up working that way. You build an application with some abstractions, not a framework. The difference is that the code you write does what you need, and doesn't need to support a bunch of different use cases. When you need to change it, you can, without worrying that you're breaking someone else's use of it.

And because you only need to support the one application, you can make it as simple as it can be to support that application.

>Libraries over frameworks.

I agree with this but it does have tradeoffs as well. Libraries, especially if they are many and small, can get out of sync a lot. I feel like I spend too much time on dependency maintenance.

That's how you spend days debugging npm dependency hell between libraries instead of coding with your framework of choice.

well, they don't have a silver bullet part, but there are standardized components like screws, gears, levers etc. It's just that mechanical engineering is constrained by physical laws, and that gives design constraints that don't exist in software.

Standardized parts sound a lot like libraries implementing common interfaces.

Have you see how modern cars are built? This [0] is a marketing blog but explains pretty well that in fact they do lean heavily into the "reuse the thing for all the things"

[0] https://www.carexpert.com.au/car-news/platform-sharing-the-m...

The mechanical engineers at my work can barely use a computer. I think I'm good.

Reply on news.ycombinator.com