Hacker News Reader

Comment by tanilama | Hacker News Reader

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 perfect world, if everything we interact are more or less functional or self-containing, then timing doesn't really matter, and uncertainty is thus controlled.

In the end, the lesson here seems to me is, making good frameworks are much harder than making good libraries. For libraries, you need to make sure the building blocks are solid, but for frameworks you are defining a whole world for people to visit.

View on HN

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 them from just about any language and you can go years without your usage of them ever becoming unidiomatic.

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.

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.

Fc and hooks force you to think in an entirely different manner though. I would say it is an entirely different paradigm. And it is a much higher learning curve.

For instance I see a lot of developers and engineers with 6 months and more experience with functional components and still misunderstanding the point of all of this. And these are smart people at high tier companies.

The main thing being the meaning of having dependencies for useEffect and other hooks.

You're right. But this is the natural progression for React. React emphasizes stateful behavior in components. UseEffects with specific dependencies are actions which depend on the specified variable-set alone, while all the other infinite variables can change however they like. This concept already exists when we talk about state machines.

That said, it isn't a smooth transition going from explicit lifecycle methods in class based components to useEffect hooks in functional components. But it refines the quality of the thinking, and the quality of the code overall, imo.

> The main thing being the meaning of having dependencies for useEffect and other hooks.

This is 100% a result of how react (ab)uses the host language semantics to implement their DSL to describe components and has nothing to do with the conceptual nature of functional components themselves.

It relatively easy to imagine a design that doesn’t require the dependency lists when capturing a callback closing over props or state.

Not saying that design would be better or worse, just that it could exist and still leverage concepts like FCs, hooks, effects etc.

Six months? Something is wrong. I learned hooks in a half day. I occasionally ask someone with more experience if I'm using the right hook to solve a specific problem, but that's a one minute question and the rest I can do on my own.

Specifically, how are useEffect dependecies complex? You list the variables that, when changed, should trigger the hook to run. What am I missing? And I'm not claiming no one struggles with hooks. But people also struggled with the lifecycle methods of React classes. In almost every case I've seen this, I've asked the developer to read the React docs. That's usually enough. I'm guessing there is some other underlying more fundamental issue if someone is still struggling with hooks after six months of hand holding.

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.

Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React component into an Angular app is far into edge case territory. Realistically, you would never consider doing it unless there was absolutely no Angular-only alternative in any way, shape or form.

FWIW, it _is_ also possible to render Angular code inside of React [1] (but again, this falls well into non-idiomatic territory for both Angular and React)

Idiomatically, React is the only thing dealing w/ DOM in an app, and the way it's used is rather frameworky ("don't call us, we'll call you"). And when it's used that way - which is the vast majority of the time - the used idioms do vary heavily depending on when the code was written.

Tying this back to what I mentioned about postgres: _within_ a React codebase, you need to be aware of the _semantics_ of the system: performance is achieved through reasoning about the semantics of things like shouldComponentUpdate/memo and even object identity, one needs to understand the semantics of stale closures and useCallback, etc. This is similar to having to understand the semantics of how various ORM idioms translate to underlying SQL queries. By comparison, the cost of any given jQuery idiom tends to correlate more directly with the underlying semantics, just as the cost of a raw SQL query does - i.e. it's pretty obvious without context how expensive `$('html').html(html)` is, just as it's more obvious what is the performance profile of a CTE vs a subquery, in comparison to whatever the high-level ORM idiom is (assuming, of course, that you know SQL)

[1] https://medium.com/@balramchavan/integrate-import-angular-v6...

> "don't call us, we'll call you"

I don't think with React as distributed (and per tutorial) you can avoid writing that first render() call, so no, “you call us” in this case.

The existence of third-party skeletons and templates that impose some structure or another and pre-write the initial render() call isn't making React a framework.

It's a feature, of course: being mostly on the library end of the spectrum opens up innovative uses of the efficient rendering. A framework by definition is narrow about what one can achieve without fighting it, otherwise (as I have to agree with TFA) its developers would drown in features and complexity.

As to running Angular in React, I stand corrected, last time I built on Angular when it was at version 5. I stand by the rest of my argument, though.

The same holds true for Postgres: idiomatically, it’s the data store and thus comes with its own set of instructions. I’m not really sure what you’re arguing here. Redis gets even worse: here are a few datasets we support, now go architect your use cases around them.

Of course, none of these reasons make them bad tools. Quote the contrary. We are about to ship a react + postgres + redis product. They all work great together for the very fact that like good libraries, we can borrow from each where they are needed.

Just because idiomatically React is the only thing interacting with the DOM isn’t an indictment...it just means React is really good at that and most people would rather use it exclusively for DOM manipulation. The same way that Postgres is often the only data store, not because it forces it upon you, but because it’s really really good at it.

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.

I think React is somewhat of a special case, because a lot of what makes React good is that it mitigates a lot of the issues which make web painful to deal with: "the browser" is this highly inconsistent target, and Javascript doesn't have built-in facilities for modularizing code, and React gives you a sensible way to get consisten behavior and implement reusable components in this type of environment.

Another way to put it is that for web you're already pretty heavily invested in the "framework" of HTML/CSS/JS wheather you like it or not. React is essentially just choosing another baseline framework to replace it, not adding a framework where none exists.

> But is framework necessarily bad or inferior to library?

The point is that more people, projects and even frameworks can use the library you write. If you write a framework, people have to drop whatever it is they're using and go with your framework. That's bad, unless your framework is the one to trump them all, which it probably isn't.

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

You are absolutely right sir 100% every one of starts doing like this he will be more successful

Reply on news.ycombinator.com