Live data from Hacker News

Write Libraries, Not Frameworks

brandons.me

201–210 of 338 posts

Re: Write Libraries, Not Frameworks

#201

A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls. The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago: http://web.archive.org/web/20141018110445/http://discuss.joe... (Sadly, that site is gone, b…

My comment in that discussion from ~15 years ago was based on experiences with a project that I "inherited" - 30,000 Java classes and interfaces, 20+ layers of abstraction, team of 30+ people working for a long time. And most importantly, it didn't actually work!

I actually "finished" it to the point of a working system for the customer with real customers in about 5 weeks by ignoring most of what they had done - required a handful of classes and JSPs. Probably distinctly under-architected but it worked and was built on for a number of years after.

Re: Write Libraries, Not Frameworks

#202
post #5

I was expecting a one-sided rant. Instead, I got a reasoned distinction between two different approaches, the trade-offs of each, and a discussion about the cases where one approach (frameworks) can be beneficial but also identifying the added risks of going that route. I agree with the conclusion, and why. I wish even more people were willing to write down a discussion of alternatives and their trade-offs. Instead o…

Yeah, I was expecting something a lot less nuanced after that warning at the beginning. I both love using full-featured frameworks (I reach for Django over Flask) and totally agree with the article. This was the blog equivalent of someone sincerely saying “Pardon my language, but gosh darn it that man is a jerk!”

Flask always looks better at the start but Django always gets me further, faster, safer (protecting me of my mistakes).

I’ve spent the past 4 months learning rails and it makes me realize how much I didn’t appreciate about Django and its magic compared to rails magic.

Re: Write Libraries, Not Frameworks

#203

I found the blog post to be just another take on the micro-services vs monolithic application debate. Where micro-services = library and monolithic = framework. As a full-time coder I take a different approach - documentation is everything. I could care less if a piece of code is a library, a framework, is made up of micro-services, or is monolithic. It all means diddly-squat if the documentation sucks and you can't…

Django’s docs are world class. It’s by far the example I always reach for when talking to people about how I think “great” docs should be written and served.

Re: Write Libraries, Not Frameworks

#204
When a programmer thinks to herself

I see the author is in the "they is not a singular pronoun" camp, which means we cannot be friends.

Anyway I don't know how it is in other parts of the stack, but based on my experiences on the front-end, to build a large-scale project you're going to need a:

- Router

- Way to manage forms & validation

- Way to communicate with the backend

- Set of tools for testing

- Set of commonly used components - that includes layout

- 118n support

- Convention where to put certain files and how to name them

- Store

So it would make sense to have all this in one coherent framework. That being said not all projects are large-scale projects. Normally you'll only need a subset of the mentioned.

Bottom line is it's a question of scale.

Re: Write Libraries, Not Frameworks

#205
post #169
post #85

Earlier quoted context omitted.

Spring class names are the stuff of legend, but most of those classes you wouldn't deliberately use in your application. They're there so Spring can layer up its own functionality feature by feature. The only problematic part about this is when these class names leak into error messages, and the level of indirection becomes difficult to follow. The way you use the core inversion-of-control framework people often just…

I agree in theory, but in practice I've found it very hard to keep Spring (Boot) out of my code. Part of the blame I think falls on Spring's DI container, which is "too good". It makes it easy to pull in any bean, even the wrong one, which means developers have to be disciplined managing how beans depend on each other, and you end up with controllers returning entities. Of course, any codebase turns into a mess if yo…

> The core turned out pretty well isolated, but the rest is all Spring. Database access? Spring Data. External interface? Spring MVC. Communication with external services? Spring RestTemplate. I'm not saying it's bad, it's actually awfully convenient, but it's not so easy to swap out

External interfaces are just isolated interfaces, which end up being tied to a framework as frameworks do most if not all of the heavy lifting.

Just because you picked Spring Database to implement your persistence layer it doesn't mean you are bound to Spring to add a webapi or a web app, though.

If for some reason your frameworks are leaking out of any of your external interfaces then that's an issue with how you designed your app, not the frameworks you used.

As an example, some Clean Architecture examples using ASP.NET Core decide to implement their persistence layer passing around Entity Framework classes as their interface. That, obviously, tightly couples the whole app to Entity Framework in particular and ASP.NET Core in general. This coupling in turn is completely eliminated by passing a generic repository interface, but using Entity Framework's convenience often forces us to ignore that.

Re: Write Libraries, Not Frameworks

#206
post #189
post #127

Earlier quoted context omitted.

> It allows you to remove the concern of logging from your classes completely. You say that like it's a good thing. When there's a bug to look into grepping strings from the log is one of the first steps, the first step if you don't have a stack trace, I want that string to be where the problem is. Having the logging in with the rest of the code is an inevitability anyway and unless you only want logging at function…

I agree, things should be straightforward, readable and logical. The Java people are describing here is alien to me, and I code Java for a living at the moment.

> The Java people are describing here is alien to me, and I code Java for a living at the moment.

you're looking at enterprise java, not regular java

Re: Write Libraries, Not Frameworks

#207
It's the most honourable way, but kiss goodbye to recognition and money. Somebody will slap a UI/app on top of it and get all the credit and get paid for it. It's one of the paradoxes of free software/open source.

AGPL fixes this somewhat but it just makes it practically not profitable for everybody involved.

Re: Write Libraries, Not Frameworks

#208
post #191
post #141

The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer. If I surrender this to a framework, there are a lot of decisions I can't make with regard to performance, and I have a lot less certainty about when and in what order exactly things are executed. There are of course some exceptions, but in general I want libraries to provide me simple, synchronous functi…

This hits home for me right now. I'm currently battling some performance problems related to a lot of "magic" that happens when using the Apollo GraphQL framework and am strongly considering ripping it apart and taking back control of what happens and when.

Would be super awesome if you could share what you find! Having the same issues here - and I have a real time accepting that stuff becomes slow when you wanna return over 1k records. Sometimes way less for advanced things. Read: nested objects. But that slow? Come on.

I also use nestjs and there it seems updates to how to resolve a field has made it tons faster l, purely looking at the trace.

And I know that it won't be as fast as regular old json due to the checking but that slow? Must be something someone can do :)

Re: Write Libraries, Not Frameworks

#209
post #85

A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls. The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago: http://web.archive.org/web/20141018110445/http://discuss.joe... (Sadly, that site is gone, b…

Spring class names are the stuff of legend, but most of those classes you wouldn't deliberately use in your application. They're there so Spring can layer up its own functionality feature by feature. The only problematic part about this is when these class names leak into error messages, and the level of indirection becomes difficult to follow. The way you use the core inversion-of-control framework people often just…

DI/IoC is just another way of expressing global variables. The global variables exist because of the constraint of class-orientation getting in the way, among other things. Spring exists because of the relative weakness of the Java language. You won't see this kind of technology emerging in more powerful languages.

Re: Write Libraries, Not Frameworks

#210
First you write libs, then you get tired of always doing the same scaffolding work, so you build the boilerplates to cover the most common flows - and before you realized you end up with a framework... the resistance is futile
Post reply on HN