Re:Virtual DOM is pure overhead (2018)
by DonHopkins on Sunday May 19, 2019 @06:07AM
(#19952480)
We can only hope that Guy Steele swoops in and saves the day by implementing React in hardware!
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
Also according to Wikipedia[0] Brendan Eich was supposed to create 'Scheme in browser' but in the end it became scheme with Java syntax. I always wonder if it was real 'scheme in browser' the web would advanced faster, at least S-expression is good at expression HTML. Therefore we wouldn't have to wait JSX until 20 years later...
whether getting a component via a function call, vs an named export identifier (component class) - They have essentially the same net benefit over time.
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.
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