Live data from Hacker News

Write Libraries, Not Frameworks

brandons.me

31–40 of 338 posts

Re: Write Libraries, Not Frameworks

#31
post #12

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…

The repeated joke about killing your ex-girlfriend did not age well.

"did not age well" - that's ageism and I'm offended.

Re: Write Libraries, Not Frameworks

#32
Framework often kill themselves because when there's new innovation or paradigm, it's hard to change. (Angular 1 is example).

So there'll be a rewrite or a complete new framework born. But a library will live forever whatever technology changed or not.

But framework is useful to integrate or test out many libraries into one to build something fast. Think it's like a boilerplate to reuse.

TLDR: Library is the primitive to build upon. Framework is just one use of libraries.

Re: Write Libraries, Not Frameworks

#33
I’m pretty sympathetic to this, as my experience with Spring has been “it’s convenient when it works, but awful to deal with when it’s not working”.

However, I think to push this line of thought, it would help if we had examples of how to build significant applications without a framework. Ideally someone could provide a walkthrough of an app like that. Unfortunately I can’t volunteer myself: the last time I built without a framework, it was a mess.

Re: Write Libraries, Not Frameworks

#34
post #25
post #6

Earlier quoted context omitted.

Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.

> "I won't name names because I don't wish to drag anyone through the mud." If it's a large framework like Angular they can take it...

Considering the author seemed to cite Angular as a well supported framework, probably not that one.

Re: Write Libraries, Not Frameworks

#35
post #12

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…

The repeated joke about killing your ex-girlfriend did not age well.

What's wrong with it?

Re: Write Libraries, Not Frameworks

#36

> 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…

I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0] It is the simplest thing I could conceive (to build, not to use - I plan to provide more…

You can use React like a library. You can even go without JSX, though nobody really does. React is also kind of odd because it includes a bunch of other stuff like hooks, even though most people bring their own state management to it. But it's definitely the least-framework-y of all the major frameworks.

Re: Write Libraries, Not Frameworks

#37
Good article. A while ago I worked a little with Angular and I thought to myself that probably 80% of it could easily be in a reusable library instead of tying it to the framework.

That way you could write a lightweight framework with a powerful library under it.

Re: Write Libraries, Not Frameworks

#38

I’m pretty sympathetic to this, as my experience with Spring has been “it’s convenient when it works, but awful to deal with when it’s not working”. However, I think to push this line of thought, it would help if we had examples of how to build significant applications without a framework. Ideally someone could provide a walkthrough of an app like that. Unfortunately I can’t volunteer myself: the last time I built wi…

If you're trying to build an entire app, you are not building a library. An app uses libraries and frameworks to stitch them together. A library brings functions, and a framework brings connectivity and logical flows. An app without a framework is an app with a hidden framework. An app without libraries is an app with a hidden framework and monolithic, catch-all, single-purpose library.

Re: Write Libraries, Not Frameworks

#39

> 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…

I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0] It is the simplest thing I could conceive (to build, not to use - I plan to provide more…

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 personally mind if a VDOM is used or not, so long as performance is good enough not to ship a noticeably lagging UI to my users. Having experienced both React and Angular --one uses VDOM, the other not-- I haven't found this implementation detail to meaningfully impact performance, but I spent my time building straightforward CRUD apps.

I would consider sharing an example to Ari of something that's hard to do in React/Vue/Angular, and how it's made simple with AriJS. That might help elucidate where it shines, and the key problem being solved.

Post reply on HN