>functional and composable way components can be designed and implemented.
Ughh.. that's the point of all modern FE frameworks...
You are putting that description on a pedestal as if that is a unique property of React.
Ughh.. that's the point of all modern FE frameworks...
You are putting that description on a pedestal as if that is a unique property of React.
A component is almost a function returns element. Expanding a component is like calling a function and give it the property.
So you can have some abstract common behavior in HOC f and g, then you can have HOC `h = compose(f(g))`.
A quick comparison with Angular: @Component({template, style}) seems composable if we stretch a lot. But why make template and style in the decorator... They are not something we consider most abstract at all.
The function is the simplest yet composable abstraction over the template, Cheng Lou also has a really excellent talk on the topic: https://www.youtube.com/watch?v=mVVNJKv9esE&t=1470s
https://news.ycombinator.com/item?id=8860722
The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in:
http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c...
Design of a LISP-based microprocessor
A function that returns a component has no more reusability than a component class' identifier. That component itself has a very narrow use case of it being a UI component.
Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?
In effect, JavaScript logic tends to be procedural/imperative, while templates allow declarative semantics, and styles are nearly a 2.5D constraint language. "Separation of concerns" here means only having to think in a particular mode, rather than blending all of those modes of thought into a single eyespan.
Notably, Vue allows for single-file components, while preserving the familiar and intentionally designed separation of declarative (HTML), imperative (JavaScript), and aesthetic (CSS) code.
Bad PHP pages mixes all kinds of shit together. This leads to the thought that to do it 'good' everything needs to be seperated.
It's a wrong thought but I see how people got there.
I don't know why people keep believing that separating templates and js is a good thig. Pete Hunt addressed this in the React into videos he did -
you want 'separation of concerns', not 'separation of technologies'.
React does the former. Vue/any other templating engine does the latter.
You get a very React-like experience with components and functional templates in JS, but it's all standard JS, and there's no framework, just standard web components. The lock-in and risk is very low for enterprises.
The more that I depart from my "bare metal" web tooling the riskier/dumber things get. I always want to see a path back to a basic HTML5 shell, driven by almost-pure JS (w/tiny helper libs), and basic CSS. Just like basic UNIX tooling - basic web tooling just works!
To those thinking about trying lit-html; it IS as simple as the example on the GitHub project page. I was able to build it into a semi-complex application within a couple of hours and it had massive performance payoff w/o compromising how I want to build things. It definitely gets my "KISS" approval stamp.
I am very curious about this kind of decision. I realize you may not be able to share details, but whatever you can share would certainly be interesting.
If your company has issues with React being developed by Facebook, that's an entirely different question.
Anyway, my point is you might want to check if it is okay to use any FE framework at all. It seems like a very strange policy to say "you can use any FE framework except React".
But if you are going to do this use Vue.