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

71–80 of 338 posts

Re: Write Libraries, Not Frameworks

#71

Post by tanilama »

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…

DBs, IMO, are neither library or frameworks. They have their own DSL after all, which is close to programming languages.

Programming languages are hard to categorize as either library or framework. They are libraries with full set of control flow primitives or framework that doesn't assume a particular flow at all.

Re: Write Libraries, Not Frameworks

#72

Post by quickthrower2 »

debaserab2 wrote: post #65

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.

Re: Write Libraries, Not Frameworks

#73

Post by spankalee »

dragonwriter wrote: post #67
JMTQp8lwXL wrote: post #39

Earlier quoted context omitted.

Have you tried React? It feels fairly library-esque to me. You can be useful in as little as two lines of code: const elem = React.createElement('div', null, 'Hello World'); ReactDOM.render(elem, document.querySelector('body')); It's 35.9kB gzipped, although "too big" is subjective. I may be unimaginative, but over my last 5 years or so with it, there isn't much I've wanted to change. As a library consumer, I don't p…

> Have you tried React? It feels fairly library-esque to me. Because it is, in fact, just a library.

React implements the component lifecycle, calling into the component to do it, stores all the component state, and reconciles DOM changes on behalf of the component. It's the very definition of a framework - it's calls the component, the component doesn't call it.

Re: Write Libraries, Not Frameworks

#75

Post by Frost1x »

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 think the key difference is that frameworks usually hijack your control flow, while library are not.

Which is what should be expected.

The point of a framework is to not only provide higher level abstractions to rapidly put together a certain type of application but to also provide a certain approach or set of approaches (a "framework") to follow as a guide during the process.

This means some generalization should exist but if a framework is too abstract its really no longer a framework... it's a library.

A library is supposed to simply provide useful utilities/lego blocks to assemble however you want and not necessarily give specific guidance or patterns.

Certain common patterns of usage may arrive as a sort of emergent property based on fundamental library choices/structure but it's overall pretty flexible.

Re: Write Libraries, Not Frameworks

#76

Post by userbinator »

vbezhenar wrote: post #17
JMTQp8lwXL wrote: post #3

> Do you introduce a domain-specific language? You're now responsible for part of the build chain, and for editor integration. > Now, if there's a major organization backing the framework, maybe the calculus works out. Google can back Angular... In my experience, even large orgs don't necessarily have the capacity for building out full-featured editor integration and build tools. Google has a great team managing Angu…

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.

Re: Write Libraries, Not Frameworks

#77

Post by justanotherc »

> A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls.

Well, when I'm building something opinionated like something resembling a framework, I usually aim for something that handles 80% of the use-cases, and then make sure that you can go around the framework for the other 20%.

Your "thing" should always have a way to get out of the way and fall back to the un-abstracted way of doing things. Then you don't have to predict the future.

Re: Write Libraries, Not Frameworks

#78

Post by AmericanChopper »

smitty1e wrote: post #60
thomk wrote: post #56

Earlier quoted context omitted.

Stuff like that always makes me feel like someone has turned off their logical reasoning and they are just basically creating code that fills in some personal mental gap that somehow 'completes the set' of the things they are working on at the moment.

I always figured that Java folks were - paid per class - sought to reduce the number of executable lines per class to 1.

But that’s just OOP in general. You can choose a language that defaults to not using OOP-style abstractions, but then people will question why you choose python/node/ruby over a proper language like Go (or whatever else)

Re: Write Libraries, Not Frameworks

#80

Post by lhorie »

tanilama wrote: post #71
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…

DBs, IMO, are neither library or frameworks. They have their own DSL after all, which is close to programming languages. Programming languages are hard to categorize as either library or framework. They are libraries with full set of control flow primitives or framework that doesn't assume a particular flow at all.

I don't consider Redis to have a DSL, and similarly, I was thinking about Postgres in the context of its client APIs rather than the SQL language. FWIW, there's another good example there: a client API centered around connections, queries, etc tends to be far more usable in terms of expressiveness and transparency than an overarching ORM framework.
Post reply on HN