The point is by the time render() returns nothing of µhtml is left of the call stack. The user code is in complete control.
The difference is that React's render doesn't make you do the update, while µhtml does.
The relevant difference is that with React your code calls render()once during the entire lifetime of the application session and React remains active for the remainder of that session - orchestrating all actions that the application takes from that point on (i.e. React is in charge).
µhtml's render() has to be called whenever your code wants to patch the DOM; so render() is called many times during the application's lifetime - and when render() returns your code is completely in the driver seat - not µhtml.
I mean in the FE generally we consider something a Framework when it comes bundled with an answer to every question (routing, testing, components, and so on).
What you are describing is an application framework. Not all frameworks are application frameworks. So if you are correct that means that in FE development application framework has been contracted to framework narrowing the meaning of the term significantly.
Still, I guess we can close it in a "we agree to disagree".
At this point your perspective seems to be:
it's a framework if it's an application framework
otherwise it's a library irrespective of the fact whether or not it operates in the manner of a framework.
My perspective is:
it's a framework if it remains active for the entire application session lifetime and orchestrates user code via inversion of control.
a library provides capabilities that abstracts certain details away but these capabilities are only temporarily and directly invoked by the user code; after the capability returns the user code is completely in charge again to orchestrate the application's actions as it deems fit.
I think at this point it's clear which view I find more obvious and less confusing.
React ... is an extremely simple and unopinionated one, that only takes care of your interactions with the DOM.
Calling React unopinionated is in my view misleading at best. It certainly is less opinionated than Angular but that isn't the same thing as being unopinionated. In fact choosing React as your abstraction has a significant impact on your client side solution architecture.
I've noted that React devs can often be classified into two groups: those who see the React tree as their app / have a "component-centric" view, and those who view their state / logic as their app / have an "app-centric" view.
The majority of Kent C. Dodds's article Application State Management with React explores the component-centric approach which goes beyond "taking care of interactions with the DOM" - it essentially uses React as if it was an application framework to the point that "React is your Application".
The "app-centric" approach tries to separate the application from React, narrowing React's responsibilities to just "taking care of interactions with the DOM". However as soon as you use an integration like React-Redux you are coupling your React code with the way Redux operates, trading away the opportunity to cleanly separate your UI from the client-side aspect of your application (and as David Khourshid points out Redux has its own set of trade offs).
In UI As An Afterthought Michel Weststrate discusses how he builds the client-side application around MobX rather than having the UI abstraction dictate the structure of the application (a modern take on Segregated DOM). Having a clear boundary between React (the UI) and the rest of the client-side application is important to use web workers effectively.
The point is that you have to be pretty disciplined and determined (i.e. it's not the path of least resistance) if you want React to just "take care of interactions with the DOM".
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The point is by the time
render()returns nothing of µhtml is left of the call stack. The user code is in complete control.The relevant difference is that with React your code calls
render()once during the entire lifetime of the application session and React remains active for the remainder of that session - orchestrating all actions that the application takes from that point on (i.e. React is in charge).µhtml's
render()has to be called whenever your code wants to patch the DOM; sorender()is called many times during the application's lifetime - and whenrender()returns your code is completely in the driver seat - not µhtml.What you are describing is an application framework. Not all frameworks are application frameworks. So if you are correct that means that in FE development application framework has been contracted to framework narrowing the meaning of the term significantly.
At this point your perspective seems to be:
My perspective is:
I think at this point it's clear which view I find more obvious and less confusing.
Calling React unopinionated is in my view misleading at best. It certainly is less opinionated than Angular but that isn't the same thing as being unopinionated. In fact choosing React as your abstraction has a significant impact on your client side solution architecture.
Redux maintainer Mark Erikson made an astute observation:
The majority of Kent C. Dodds's article Application State Management with React explores the component-centric approach which goes beyond "taking care of interactions with the DOM" - it essentially uses React as if it was an application framework to the point that "React is your Application".
The "app-centric" approach tries to separate the application from React, narrowing React's responsibilities to just "taking care of interactions with the DOM". However as soon as you use an integration like React-Redux you are coupling your React code with the way Redux operates, trading away the opportunity to cleanly separate your UI from the client-side aspect of your application (and as David Khourshid points out Redux has its own set of trade offs).
In UI As An Afterthought Michel Weststrate discusses how he builds the client-side application around MobX rather than having the UI abstraction dictate the structure of the application (a modern take on Segregated DOM). Having a clear boundary between React (the UI) and the rest of the client-side application is important to use web workers effectively.
The point is that you have to be pretty disciplined and determined (i.e. it's not the path of least resistance) if you want React to just "take care of interactions with the DOM".