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

211–220 of 338 posts

Re: Write Libraries, Not Frameworks

#211

Post by emn13 »

brundolf wrote: post #36
rhengles wrote: post #29

Earlier quoted context omitted.

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.

For years I used react without jsx - with a few minor conventions to make it shorter to write elements via JS (`_div(...)` being equivalent to the jsx `{...}`, and some minor variant for elems with attrs) it's quite easy to build trees using plain old JS syntax.

The advantages of doing that were better tooling support, since everything under the sun supported JS, but not necessarily JSX very well, and jsx isn't really all that important anyhow. Obviously that's not a factor anymore today ;-).

Re: Write Libraries, Not Frameworks

#212

Post by thom »

simongray wrote: post #160
thom wrote: post #63

This has generally been the approach in the Clojure community. Of course, lacking standard frameworks, every library gets abandoned every few years so you have to learn a new even cleverer one. And wherever you might benefit from a group of very cohesive abstractions (e.g. in data science) you’re instead left with a bunch of random incompatible things (that again, will be abandoned in due course).

What are you talking about? Every Clojure library does not get abandoned. It's just a process of survival of the fittest, like with any language. The popular libraries in Clojure are (mostly) actively maintained like with any other language.

It's great that this has been your experience, but I'm on my fourth SQL library at this point. I've been through several HTML rendering libraries, same with authentication, same with config management. The zipper and component libraries I used are abandoned. The data science story is sad compared to the R or Python ecosystems: Incanter dying, clj-ml unmaintained, Fastmath is good for some random stuff but not comprehensive, tech.ml on the rise but still not standard to the point anything actually integrates with it, multiple competing viz libraries, some of which require a browser. Even core stuff like spec hasn't stabilised yet.

I have used Clojure full time for 11 years and it's nonsense to pretend that the ecosystem doesn't have problems that most Ruby, R, Python or .NET developers don't have at all or as often, by virtue of them having strong frontrunning frameworks. I'm not saying they're necessarily more happy or productive than Clojurists, but there is constant churn everywhere in the Clojure ecosystem, and it increases the cognitive load on every project I have ever done in the language.

Re: Write Libraries, Not Frameworks

#213

Post by andybak »

The one thing I do value from frameworks - especially in an unfamiliar domain - is that they teach me how to structure things.

I can usually patch functionality together from various sources but understanding how to break a process down if you haven't done it before is often very challenging.

For example - Django taught me how to structure server-side code that needed to handle input from both a database and a browser and potentially an API in a way that keeps things nicely layered.

I'd done all this before with PHP but my architecture was a dogs dinner. I could structure my own code nicely now - but only because of the experience I gained from using an opinionated framework.

Re: Write Libraries, Not Frameworks

#214

Post by strogonoff »

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…

This thread is peculiar.

Framework library is a spectrum, of course, but as an obvious indicator of React’s location on that spectrum—you can feasibly use it inside, say, an Angular app to render a particular third-party widget. At its core, React is a super-efficient unopinionated render() and tools for constructing its input. On its landing page it establishes right away (IMO, correctly) that it’s a library.

The reverse, bringing a single Angular component into an otherwise React-based webapp, is basically an oxymoron. Angular will generate e2e test scaffolding for your entire project, prescribe where to query data, expect you to follow a particular file layout in your codebase, and pull in enough machinery to rule out any auxiliary uses.

Re: Write Libraries, Not Frameworks

#215

Post by gruez »

keanebean86 wrote: post #112
infogulch wrote: post #97

Earlier quoted context omitted.

All of which end up getting allocated to a single 56 core cpu.

Even the CPU adds at least one layer of abstraction. Spring JVM Container OS hypervisor x86 Real CPU instructions Electrons Unknown EDIT: formatting

Are hypervisors and containers really abstractions though? All they do is manage access to the underlying resource.

Re: Write Libraries, Not Frameworks

#216

Post by jonathanstrange »

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 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 of time if you're not careful about evaluating the framework.

Re: Write Libraries, Not Frameworks

#217

Post by jmull »

The corollary to this is:

    *Use* libraries, not frameworks
Similar to the case of writing, this isn't absolute. But when you decide to use a framework in your project, you are accepting a set of limitations and should do it with your eyes open.

Unfortunately, framework authors make this difficult. It's understandable but frameworks spend a lot of effort promoting their "pros" to developers and none on clarifying their "cons" (well, typically).

When you adopt a third-party framework for a project, you want to do an analysis of the longer-term implications of the limitations the framework. Sometimes that analysis is easy. E.g., if I am making an "event" app -- like an app for "XYZ's 2021 Comedy Tour" -- there isn't a long term (though there, it makes sense to take it further and see if there's an even more restrictive "template" app that will still nicely meet requirements).

But if you are hoping to extend and build-out your app/project/solution over time, especially if you don't know details of how, up-front, it's tough to accept the limitations of a framework.

Re: Write Libraries, Not Frameworks

#218

Post by masswerk »

skohan wrote: 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…

You could make a point that programming is managing flow control.

Re: Write Libraries, Not Frameworks

#219

Post by eternalban »

There is also Write Libraries, not language features.

The progression language -> library -> framework maps to semantics -> a vocabulary of expression -> ideology.

I think the OP has made an error in considering a framework as a sort of 'maximalist' construct that must cater to any and all possiblities.

Let's consider a (known) rigirously and formally specified 'framework' approach and see if it needs to "predict ... every kind of thing ... [possible to accomplish] within its [constraints]":

https://www.oracle.com/technetwork/java/javase/documentation...

A framework design team is tasked with facilitating a technical goal:

RoR: "MVC for the world!".

Java Beans: "Tool makers of the world, unite!"

J2EE: "Look ma, my IT commodity programmer can do distributed component oriented programming and not even know it!".

At its most abstract consideration, RoR is an idoelogical take on writing MVC. "This is how you do it". Beans nails down an approach for wirable components that can be supported at both design and runtime with tooling and automation. JEE says lays down 4 canonical and formally boxed contexts of reference (naming), transaction, persistence, life-cycle.

None of the above had to predict ahead of time "everything". Frameworks are almost always really about top-down considerations.

[p.s. follows]:

Keep in mind that we're always building on top of the 2 fundamental layers of langauge semantics and libraries. The proverbial "standard library" is the reminder. So that just leaves the final layer, and the critical consideration of "more libraries" or "manifesto on how to use libraries".

The actual core issue is composition limitations. It is far easier to compose libraries (vocab-a + vocab-b + ..) than it is to compose framework (which may not even be possible).

A framework is a 'final consideration' of the best approach for a (set of) niche technical concern(s).

Re: Write Libraries, Not Frameworks

#220

Post by m12k »

One way to improve both frameworks and libraries (but is especially needed with frameworks) is if they create 'safety valves' - places where it's possible for the programmer to just break free of what the framework/library is doing and do their own thing. With this approach, and sufficiently modular architecture, you get ease of use at the highest level, but can drop down to as a low a level as needed to work around limitations (a common example is ORMs just letting you write raw SQL when you want to, but most of the time you can get the benefit of their abstractions).
Post reply on HN