Live data from Hacker News

Write Libraries, Not Frameworks

brandons.me

291–300 of 338 posts

Re: Write Libraries, Not Frameworks

#291

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 wouldn't mind frameworks if they actually had what they claim to offer. Nowadays so many frameworks don't even deliver, they have those nicely looking webpages and come with advertisement after advertisement of their features (even if they aren't sold!), and then when you look closely at the source code or API docs, half of those features are vaporware. This is more than infuriating, it can actually cost you a lot…

I can’t even figure out what Spring is claiming to offer. The only benefit of Spring is that you can move what ought to be compile-time exceptions into the runtime.

Re: Write Libraries, Not Frameworks

#292

This feels like an apples vs oranges comparison. Libraries tend to be more focused and single purpose (e.g., provide an interface for technology X). When you begin composing libraries together to do a multitude of things you tend to end up with a defacto framework whether you call it that or not. Frankly, I'd rather use a framework that has been battle tasted and hardened through open source and is well documented in…

React is a great example of a library that provides enough structure that you typically don’t need a framework. I don’t think you always need a framework for this reason. And it’s definitely battle tested as are all the extras like router etc.

Aside from the fact that create-react-app itself is pretty much a framework, even if you don't use that and roll it all yourself you end up with a codebase that has many of the same hallmarks of a framework such as directory conventions, common class patterns, a bootstrapping mechanism, etc. There's plenty of messy React codebases out there that screw this up.

Re: Write Libraries, Not Frameworks

#293

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…

IMHO, the framework vs library debate is similar to the inheritance vs composition.

Inheritance: You must predict how people will use your class. Make a mistake and they're screwed and need to resort to all kinds of hack. (Like frameworks)

Composition: People will use your class if it fits their needs. They can easily wrap the code, tweak or simply discard it. (Like libraries)

Re: Write Libraries, Not Frameworks

#294
Do we need frameworks? If you think a framework is a layer of abstraction, then an OS is a framework, a browser is a framework. You dont need angular to write web app but you need browser and OS. So someone needs to write frameworks.

Re: Write Libraries, Not Frameworks

#295

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…

> http://web.archive.org/web/20141018110445/http://discuss.joe... "Right. Fuck you. Fuck your lack of hammers. Fuck your factory factory factories. And fuck your store. If you decide to pull your head out of your ass, I'll be over here, duct-taping a rock to a stick so I can actually hammer a actual nail into a actual piece of wood." I'm reminded of the HGttG scene regarding the display department.

> duct-taping a rock to a stick so I can actually hammer a actual nail into a actual piece of wood.

Note to anyone actually trying this: if you have a drill, drilling a hole in a piece of wood and sticking the stick (preferably dowel) through works better; if you need more weight, attach the rock to one side of the head, and a coin or other patch of metal to the other.

Also (if you have the space for it): adopt a lathe/smelter/set of chemical-refining glassware/etc today!

Re: Write Libraries, Not Frameworks

#296
Do we need frameworks? If you think framework is a layer of abstraction, then an OS is a framework, a browser is a framework. You don't need angular to write a web app, but you'll need OS and browser. So someone needs to write frameworks.

Re: Write Libraries, Not Frameworks

#297
post #55

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…

With Postgres that's because SQL has been a standard for decades now. And with idiomatic React the changes were largely not because of what you claim: not anticipating needs well enough. The changes in what is idiomatic were largely around discovering better ways of doing things, along with JavaScript itself changing. You can still write a React component using idioms from five years ago and it's still easy to read the code. React is very focused, and very simple. The main motivation for moving to the newer idioms is that you can make the code even shorter and more readable. It seems to me that they anticipated the need to keep up with the JavaScript language evolving quite well.

Re: Write Libraries, Not Frameworks

#298

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.

666f 6f0a 6261 720a - newline separated ASCII is not inherently usable, f09f 988a 0a - utf8 is almost magic

And this conversation happening on web platform... Is it usable? Browser complexity is enormous.

I'd argue XML tooling is a joke. Can it make a closure?

Re: Write Libraries, Not Frameworks

#299
Whenever I've had tools a platform/infra team provides that feels like I'm working with my hands tied, maybe it makes things withing some predicted boundaries and everything else hard, this seems to be the culprit. I never realized it until I had a teammate redesign an infra tool from a framework into a library, explicitly pointing out this distinction. Now I explicitly think about it as a fuzzy spectrum when I'm writing what's kinda analogous to higher order code, or really anything that feels like "investment" code I want to leverage to help myself down the line. Being aware of the spectrum has let me be intentional about my choices in a way that may be the biggest improvement in my programming since I learned about unit tests.

Recently, pytorch-lightning has been interesting to me because it seems to be relatively close to the boundary between these two ideas.

Post reply on HN