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

Write Libraries, Not Frameworks

brandons.me

Post reply on HN
Print view View original

81–90 of 338 posts

Re: Write Libraries, Not Frameworks

#81

Post by hesarenu »

lhorie wrote: post #55
tanilama wrote: post #49

I think the key difference is that frameworks usually hijack your control flow, while library are not. But is framework necessarily bad or inferior to library? I would like to present React as an example. React heavily regulates the control flow for its developer, leaving several specific hooks to allow you control the timing when your code would trigger. But React is an excellent piece of software. And assuming in a…

I would argue React is actually a great example why the article title is on point. Idiomatic React has completely changed several times over the course of a few years. This shows that it did not anticipate people's needs well enough. And React is in the fairly enviable position of receiving corporate backing in the tune of a million dollars per year. Now consider tools like Redis or Postgresql. You can interface with…

Could you point out which reactjs code has completely changed? I believe reactjs has remained the same, there are deprecations, hooks etc but basic premise is same.

Re: Write Libraries, Not Frameworks

#82

Post by tasogare »

zests wrote: post #48
userbinator wrote: post #9

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…

Most of those crazy looking Spring classes aren't used by users and are just used internally by the framework developers. Of all the complaints people have about Spring, I've never heard "these classes are too abstract" or "these names are too obtuse." There was maybe one instance where I had to deal with obtuseness like that. Definitely not the norm.

It still shows up in 2000 lines of stack traces when an exception occurs. For comparison a similar stack traces in Asp.net Core is 20 lines...

Re: Write Libraries, Not Frameworks

#83

Post by tanilama »

hesarenu wrote: post #81
lhorie wrote: post #55

Earlier quoted context omitted.

I would argue React is actually a great example why the article title is on point. Idiomatic React has completely changed several times over the course of a few years. This shows that it did not anticipate people's needs well enough. And React is in the fairly enviable position of receiving corporate backing in the tune of a million dollars per year. Now consider tools like Redis or Postgresql. You can interface with…

Could you point out which reactjs code has completely changed? I believe reactjs has remained the same, there are deprecations, hooks etc but basic premise is same.

Yep.

React went from React.createClass -> class xxx extends Component -> Hooks.

But I don't think that means...change? The fundamental concept of react, that UI is a derivative from the state, stays the same. Class based or Hook (or just a really nice way to write Functional Component), stays the same.

Re: Write Libraries, Not Frameworks

#84

Post by pierremenard »

This article looking at frameworks as introducing cyclic dependencies of interpretation is illuminating: https://parametri.city/blog/2018-12-23-language-oriented-sof...

> The trouble with frameworks is that to use it, you have to match your application to the language of the API. If you’re not careful, you end up coupling your system to the framework. This means that you create a cycle between yourself and the framework by architecting your component as an interpreter from F_o to F_i.

You can avoid this cyclic dependency by marginalizing the framework at the edges of your application, as suggested in the post, but that strikes me as much easier to do with libraries.

Re: Write Libraries, Not Frameworks

#85

Post by niftich »

userbinator wrote: post #9

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 call "Spring" is you take your homegrown, doesn't-depend-on-Spring business logic, you make a config file, and if you're not executing it a servlet container, you make one entry-point class to start it all up [1].

There other projects under the Spring umbrella, and some of them are meant to be called from your code. Like Spring JDBC for database access, whose framework-like nature is apparent, yet in terms of its usage pattern, it resembles a library [2].

[1] https://docs.spring.io/spring/docs/current/spring-framework-... [2] https://docs.spring.io/spring/docs/current/spring-framework-...

Re: Write Libraries, Not Frameworks

#86

Post by huntedsnark »

I liked this piece, but came out of it more on the side of frameworks, oddly, than libraries. I went into it with a bias ostensibly shared by the author based on the title but here we are. Probably different priorities or values in terms of what constitutes 'shipping' I would guess based on our respective backgrounds.

Re: Write Libraries, Not Frameworks

#87

Post by diehunde »

userbinator wrote: post #9

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…

I prefer to read articles like the one you linked. They feel honest. If you don't like something you don't have to say "but yeah for this specific case it's fine, or if google is behind then it's alright..." just to be more correct and avoid comments from haters. I don't mind if you are a junior dev or Joel Spolsky. You should always write with confidence, especially when it's an article about an opinion.

Re: Write Libraries, Not Frameworks

#88

Post by tasogare »

userbinator wrote: post #76
vbezhenar wrote: post #17

Earlier quoted context omitted.

One option is using XML with complicated enough XML Schema. Good editors like Intellij Idea support editing such an XML and provide good autocompletion, on-the-fly validation. XML libraries would parse that XML into tree and validate it against schema without any additional effort. While XML certainly deserves some blame, the amount of tooling around it is unmatched.

While XML certainly deserves some blame, the amount of tooling around it is unmatched That tooling was created as a result of XML being difficult to use otherwise, not the other way around; in much the same way that some languages like Java seem to depend on an IDE to be even usable, far more than others.

I disagree. The amount of tooling come from the combination of well-written specification and enterprise jumping on it. Also, basic XML is quite easy to grasp even for people with really limited or no technical skills, which is also a big bonus for adoption. Granted, some XML later developments indulged in the factory factory pattern, but XML got lot of underserved blame, especially when the purpose it’s to advocate another less readable format that doesn’t handle comments.

Re: Write Libraries, Not Frameworks

#89

Post by gorgoiler »

This is good advice and of course, because of the nature of computer science and software engineering, it WLOGs its way to many other topics.

For example: I’ve always enjoyed the tools that come as a pile of small Unix utilities, rather as one single application (GUI or not, but usually GUI.)

BitTornado in the early 2000s. Git of course, where you build your own workflows that work for you using the different command line tools (fetch and rebase, pull and merge, cherry-pick if you want to.)

Much of the Debian helper script suite is designed to be reusable in small components in a makefile, rather than enforcing you do it all their way in one big invocation. And of course the current systemd vs bash-plus-lsb-shell-functions comparison.

I found I couldn’t use ZFS without systemd recently, on an Ubuntu install. ZFS shipped with init scripts that only worked with systemd, but systemd meant my console booted blank. I decided to fix the former rather than the latter and it was pretty easy to write my own ZFS init scripts using the LSB init shell functions — a library, not a framework.

Re: Write Libraries, Not Frameworks

#90

Post by grecy »

syspec wrote: post #26

The best distinction I've read is: When something is a library, your code calls functions on it. When something is a framework, it calls functions on your code

I'd add to that and say

When something is a framework, it calls functions on your code AND it does a lot of the heavy lifting for you.

I studied Frameworks in my Software Engineering degree, but really had no appreciation for them until developing large software in WebObjects.

Until you've extensively used a well-written Framework, libraries seem great. After, you realize a library just helps you here and there, but a Framework is so much more.

Post reply on HN