Hacker News Reader

Comment by resonious | Hacker News Reader

Not to derail too much from the original article, but I've been starting to feel the same about entire tech stacks. Building CRUD apps is annoying no matter what. Every time a framework makes one thing easy, it makes a couple of other things hard. No matter what tech you're using, there are some generalizable skills that are indispensable for project longevity: good testing, organization of files, consistency in concepts, and thoughtful comments that tell you why things are the way they are.

The idea that we can replace skillful software engineering with the right abstraction just hasn't panned out for me.

View on HN

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

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.

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.

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

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

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...

You are still looking for the right abstractions just not in the code that makes the application work.

Shameless self-promotion: this is exactly the problem our team hit and is trying to solve at kurtosistech.com. It still Just Sucks to build microservices because you need to know a) what you need to write b) what components you need to glue together (do I want a Dockerfile? what testing framework? what CI/CD?) and c) how to actually implement them (how do I write my Github Actions config? how do Dockerifles work again?).

The Kurtosis hypothesis is that we can abstract away most of these things with automation (e.g. force devs to update the changelog, force versioning of the API, handle all the automated client generation) while still allowing users to pop the hood and do the low-level if they really need to (but popping the hood shouldn't be easy).

Just a bit of feedback: micro service architecture isn’t universally hated (I love my Skaffold setup), and “popping the hood shouldn’t be easy” makes the devops engineer inside of me want to refuse to even read more about your product on principle.

If you’re not building a tool for junior developers only, you might want to change the tone of your pitch to more of a “we make this super slick” instead of “we built black box #93784583”

Reply on news.ycombinator.com