[HN Gopher] Liskov's Gun: The Parallel Evolution of React and We...
___________________________________________________________________
Liskov's Gun: The Parallel Evolution of React and Web Components
Author : technojunkie
Score : 23 points
Date : 2024-10-09 17:34 UTC (5 hours ago)
(HTM) web link (www.baldurbjarnason.com)
(TXT) w3m dump (www.baldurbjarnason.com)
| mattmanser wrote:
| Great insights and a truly informative read.
|
| Shame it didn't get more traction, possibly because it was so
| long. Would have loved to see where the comments would have taken
| it.
| 12_throw_away wrote:
| A very enlightening history. As a non-frontend-dev, this is the
| context I've been missing - I finally get why Web Components have
| been such a confusing mess every time I've tried to learn them.
|
| (as a bonus I very much appreciate the takedown of React's claims
| to "unidirectional flow" and "functional programming")
| tialaramex wrote:
| I was wondering if this ends up actually involving Barbara
| Liskov's ideas or it's just a pun or something and it does end up
| that these technologies have problems with Liskov Substitution,
| so that's nice.
| jjcm wrote:
| This is an excellent writeup, probably the best I've seen that
| summarizes the issues with webcomponents with the viewpoint of
| react. I'd like to add a few more reasons why I think
| webcomponents haven't had great adoption though:
|
| 1. Lack of convention. They tried to create lower level APIs
| rather than an opinionated structure of how to organize
| webcomponents, leading to the majority of consumption of them to
| be via a framework. They promised to remove the need for
| frameworks, not create more! I really wish webcomponents
| implemented more ease-of-use features and convention rather than
| relying on libraries to do this.
|
| 2. Lack of organization. This is similar to the above, but the
| majority of the time I see people bundling their html and css
| into js files in order to have a one-component-per-file approach.
| There's a part of me that kind of wishes we had html imports for
| subdirectories, and allowed you to load either button/ (and all
| subfiles) or even button.gz, which would have the html/css/js all
| bundled together in a sensible and opinionated way. The lack of
| opinions on how to organize your components, and the lack of html
| imports, have led to a chaotic mess where everything has to be
| interpreted before first paint.
| IceDane wrote:
| This post is really something.
|
| While it is obviously full of interesting internet history and
| technical details and a bunch of good points about, well,
| software architecture in general, it was extremely hard to get
| through. It's way, way too long and makes me think that this
| person really loves the sound of his own voice.
|
| The author is a perfect example of an enlightened centrist. The
| post starts out with a (way too long) self-righteous lecture
| about the tone of the internet, and then quickly devolves into
| just bashing react using some pretty dubious arguments. Hypocrisy
| at its finest.
|
| Some of his claims about react are, at best, extremely
| misinformed and at worst, makes me truly want to doubt his
| ability to build software and abstractions -- which I don't
| really honestly believe, because many of his other technical
| discussions clearly show he knows what he is talking about, at
| least to some extent. Some of the claims:
|
| - Impossible to understand what is going on in any given
| component: You can absolutely build components that make this
| hard and are tightly coupled to all sorts of state and what have
| you.. but you can also not. You can build tangled balls of mud
| anywhere, using anything.
|
| - Claims that "large chunks of the react community have given up
| on unit testing".. by citing some random guy on twitter. Maybe I
| should create a xhitter account and make the opposite claim.
| Meanwhile, if you want some actual data, try looking at npmtrends
| for @testing-library/react.
|
| - Blathers on about the virtual dom. Is it a perfect solution?
| No, no one has ever thought it was. But in practice, re-renders
| are rarely a real problem. It also doesn't "re-render everything
| every time", and when there are too many re-renders, there are
| ways to avoid them. If it's still not fast enough, by all means,
| just use something else. The part about it not "acskhually being
| functional" because it performs optimizations under the hood is
| also just straight up embarrassing. It's an abstraction. And it's
| never been _really_ functional as much as has been inspired by
| functional programming. It 's still a pretty useful approximation
| to think about react components.
|
| The part about "react commodifying devs" is just patently absurd
| and boggles the mind. Management (with a capital M, like the Man)
| has always been trying to treat developers as replaceable units
| where one dev is the same as the next dev. React has absolutely
| no role in this whatsoever except for the fact that, in the
| context of the web, it became extremely popular extremely fast
| and thus appeared in more job postings than anything else, since
| nothing has grown within the realm of software development quite
| like web development has grown.
|
| While he addresses some really interesting issues with
| implementing web components, he just keeps bashing react every
| chance he gets, and considering how much of this post is spent on
| that in particular makes me really feel like this post is a (not
| so thin) veneer on top of what was originally meant to be a rant
| against react, in the same vein as all the other rants he starts
| out his post by distancing himself from.
___________________________________________________________________
(page generated 2024-10-09 23:01 UTC)