Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem with Frameworks

plbrault.com

Post reply on HN
Print view View original

91–100 of 111 posts

Re: The Problem with Frameworks

#91

Post by berkes »

dundarious wrote: post #56
berkes wrote: post #42

Earlier quoted context omitted.

And ideally, you'll wrap them too. In what is often called "Anti-Corruption-Layers". Often very simple Proxies or Adapters. Consequentially, this makes testing (in isolation) far easier too. Which also means you'll choose libraries that are decoupled by design because the others are really hard to write such wrappers for.

Sometimes quite useful, yes, though I would strongly emphasize that the goal is not to wrap the entire API of the dependency -- that is pure busywork and doesn't stave off "corruption". Just the (consciously quite minimal) parts you actually need.

I'll usually even add another guard: only add them if the library uses non-domain language.

For example, so that you can say "chargeCard(payment)" in your domain and app, Instead of having to do things like "openAnonCustomer(payment.customerId) && pmt= addPayment(payment.amount, payment.currency) && bookPayment(pmt)" or whatever weird language, order, or transaction boundaries a library uses.

Re: The Problem with Frameworks

#92

Post by berkes »

chaostheory wrote: post #82
berkes wrote: post #47

Earlier quoted context omitted.

To counter some of your counters, or, actually, to give some advise that I've learned along the way: > - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack Yes. Which is why it is crucial to know software patterns, be able to research architectures and have (someone close, with) experience in making those choices - and seeing them fail. Frameworks are not a real answer…

The key issue is “if you do it right”. That’s easy to type, but hard to execute. You’re essentially creating a private framework without public scrutiny which catches a lot of mistakes. That’s one of the main values of using an open source framework. Are there times when a new framework is better than a preexisting one? Sure, when there are no frameworks that can meet your specialized project, but if it’s a typically…

> The key issue is “if you do it right”. That’s easy to type, but hard to execute.

Indeed. In fact, everyone, including said seniors, will make the wrong decisions, will "do it wrong".

So make sure the "do it wrong" is cheap. And the "do it right" compounds.

Frameworks make "do it wrong" extremely expensive. If, after four years, you find that Symphony really was the wrong tool for your highly event-sourced bookkeeping, there's little you can do other that turning your Symphony into a personal version of it, or Rewrite It In Rust.

Frameworks dictate far more than just the language and where to put stuff. They dictate how you test, how you host, deploy, how your team works, how long sprints can be, if scrum fits and so on. They get their tendrils in the entire project.

Optimizing for "cheap failure" and "compounding interest on doing it right", IMHO does not go well together with many frameworks.

Re: The Problem with Frameworks

#93

Post by pooya72 »

chaostheory wrote: post #83
commandlinefan wrote: post #35

Earlier quoted context omitted.

> completely skip their wrapper Why use Spring Boot at all then?

Because it provides commodity functionality that most developers with Spring experience can understand quicker, along with the Java philosophy of customization over convention. I don’t like Java or Spring, but I understand their benefits and why people like them.

What don’t you like, if you don’t me asking? I was thinking of delving deeply into Spring.

Re: The Problem with Frameworks

#94

Post by pooya72 »

jjtheblunt wrote: post #77
jordiburgos wrote: post #37

Earlier quoted context omitted.

But Spring also saves you the time of putting those wrapped technologies together.

I wonder if Spring has caused more wasted time, configuring its grandiosity, than it has saved people, and I say that because I don't know the answer.

What do you think people waste most of their time on?

Re: The Problem with Frameworks

#95

Post by random_kris »

pooya72 wrote: post #93
chaostheory wrote: post #83

Earlier quoted context omitted.

Because it provides commodity functionality that most developers with Spring experience can understand quicker, along with the Java philosophy of customization over convention. I don’t like Java or Spring, but I understand their benefits and why people like them.

What don’t you like, if you don’t me asking? I was thinking of delving deeply into Spring.

There is quite some boilerplate and for someone inexperienced it is quite a big leap.

Ive been developing with spring for past 3 years and so far I freaking love it.

Ive gotten quite quick with it so I can do an mvp with auth, logging, microservice patterns really fast.

And when project grows in complexity it is very maintainable.

But if you are not expirienced and don't care about maintainability and want something fast then node& express is a way to go imho

Re: The Problem with Frameworks

#96

Post by pooya72 »

random_kris wrote: post #95
pooya72 wrote: post #93

Earlier quoted context omitted.

What don’t you like, if you don’t me asking? I was thinking of delving deeply into Spring.

There is quite some boilerplate and for someone inexperienced it is quite a big leap. Ive been developing with spring for past 3 years and so far I freaking love it. Ive gotten quite quick with it so I can do an mvp with auth, logging, microservice patterns really fast. And when project grows in complexity it is very maintainable. But if you are not expirienced and don't care about maintainability and want something…

Thanks for your insight. I agree with your comment about the trade off between the time it takes to fully learn the framework vs the productivity that you will get. I think that’s true for all frameworks. There’s also Javelin if you need something smaller and quick to pick in Java that is similar to Express.js.

Re: The Problem with Frameworks

#98

Post by dundarious »

berkes wrote: post #91
dundarious wrote: post #56

Earlier quoted context omitted.

Sometimes quite useful, yes, though I would strongly emphasize that the goal is not to wrap the entire API of the dependency -- that is pure busywork and doesn't stave off "corruption". Just the (consciously quite minimal) parts you actually need.

I'll usually even add another guard: only add them if the library uses non-domain language. For example, so that you can say "chargeCard(payment)" in your domain and app, Instead of having to do things like "openAnonCustomer(payment.customerId) && pmt= addPayment(payment.amount, payment.currency) && bookPayment(pmt)" or whatever weird language, order, or transaction boundaries a library uses.

Yes, wrap a useful "flow" for your application, rather than functions. Often I find there is just one flow for a dependency.

Re: The Problem with Frameworks

#99

Post by jordiburgos »

jjtheblunt wrote: post #77
jordiburgos wrote: post #37

Earlier quoted context omitted.

But Spring also saves you the time of putting those wrapped technologies together.

I wonder if Spring has caused more wasted time, configuring its grandiosity, than it has saved people, and I say that because I don't know the answer.

Sometimes it is.

Trying to find solutions to random errors is a big task because of all the layers and layers of classes.

A simpler and renewed architecture that covers all those parts that Spring solves would be beneficial for the users.

Re: The Problem with Frameworks

#100

Post by chaostheory »

pooya72 wrote: post #93
chaostheory wrote: post #83

Earlier quoted context omitted.

Because it provides commodity functionality that most developers with Spring experience can understand quicker, along with the Java philosophy of customization over convention. I don’t like Java or Spring, but I understand their benefits and why people like them.

What don’t you like, if you don’t me asking? I was thinking of delving deeply into Spring.

Imo if you’re doing Java, you need some inversion of control framework like Spring of Guava. You can’t avoid it especially for larger projects

what I really hate is that it focuses on configuration & customization over convention. At the same time, it is a strength for certain projects and teams.

Post reply on HN