3. Why is it that all the issues that arise from Web Components merely existing are "solved" by throwing more and more Javascript at the platform (anything from form participation to anything else, really)
4. Could it be that it is Google as the main driving force behind web components is the one hurting people by making the platform ever more brittle and unimplementable?
>Who do you feel React is hurting, and in what way?
There's an entire open source community that revolves around "React alternatives that exist because they're not React". For better or worse, people have ideological reasonings for their choice of JS framework. I've seen it play out countless times at multiple jobs between people who just want to get their work done with the industry standard tooling, and people who have a bone to pick with FB and become fanatical about using Vue/Svelte/*whatever instead of React.
The contrarians usually win out, because the people who just want to do their job and go home don't care enough to fight that battle over and over again. The result is a patchwork of forgotten projects and frozen dependencies that no one knows how to maintain, and a security nightmare where everything is pulling in tons of random unmaintained NPM packages with 4 GitHub stars, rather than the battle tested 5 year old React equivalent with 2k stars.
This is exactly why I use React after using libraries like Vue. The ecosystem matters, and non-React libraries are simply just not there. I want to make stuff, not wrangle around with poorly-supported dependencies.
My biggest issue with React is how it mixes HTML in Javascript. Like putting HTML inside strings or whatever they are doing. Without proper tooling and an editor which supports it, you won't get anywhere. At least that's my amateurish feeling on React, my reason for avoiding it. I may very well be wrong, but I wouldn't know.
Of all the ways to write how your HTML is supposed to look from JavaScript, JSX is probably the closest to Javascript there is. It's a very simple syntax translation to JS function calls, and all code / logic is still plain JS. Every other template language that invents their own loops / conditionals / ways to insert variables is waaaaaaay further away from JS (and also still needs tooling and editor support).
... or don't write how your HTML is supposed to look from JavaScript.
I like Angular's approach the best. You have an HTML file, a SCSS file, and a TS file. The TS file is essentially your model and handles all the thinking. HTML/SCSS are kept declarative like god intended.
Do you genuinely think Angular's template language and all the complexity it comes with is better than JSX just saying "anything between {} is plain JS"?
You'd be wrong. JSX is just syntax sugar over manipulating nested JS objects which represent the state. Try React sometime, their docs are great: https://beta.reactjs.org/
Agreed. React reminds me of early days PHP. Which I supposed makes sense from an engineering org that was birthed on PHP. Separation of concerns?? NAHHH!!
I've seen many people in this space often forget to utilize `import` and `export`, that is not trying to write composable modules so that it's treeshake-able.
Shoelace looks great, thx for posting! If you can think of any more in that vein- that is clean looking vanilla web components without adding a ton of ‘framework’- feel free to share.
Personally, I’m of the believe that the bumbled mess that web development has become can only be fixed by peeling away layers (or perhaps starting from scratch) not adding more. I seem to be in the minority on this though…
Thank you for sharing the shoelace link. Looks like it behaves well on mobile, unlike many other frameworks. I'm using Quasar, but I want to try something else.
Weird that a framework created by Adobe, the creators of Flash, one of the most non-standard web ever created, would be cited as a web standard friendly alternative to React. Such is the way when a company loses its competitive advantage /shrug.
If you're doing JS development, just use React. There's really no good reason not to, and I would argue that in an enterprise environment it would be negligent not to.
If anyone can give a non-ideological reasoning for a better choice, I'd love to hear it.
Also the person building Shoelace has consistently been an early adopter of best practices/standards.
I believe a single person with taste and knowledge can build better components than yet another team chasing after latest 'trends' under time pressure.
First, dev dependencies don't count. There two are from shoelace. Color's main features will eventually be in one of the CSS Color Module's specs. Floating UI's main features will be in the CSS Anchor Positioning spec. Lit is used for building the web components. Lit React can be removed when React supports web components better. The QR library can probably only be installed if needed.
The less thing people know, the high risk, the more defensive. Like losing the entire basket of egg. In traditional way, they dedicated the whole life to one thing, and that was called a cult.
I totally agree with your sentiment, but there are more frameworks out there with sufficient maturity to be considered enterprise-grade on the scale of react. Angular is certainly there, Vue as well at least in my book.
Angular is an option from a high level but I would argue against it on merit.
Vue is off the table. If you’re not prioritizing “ability to hire” with your tech choices you’re in for a bad time. Angular is popular enough that you would get a lot of candidates.
Where I work uses Vue rather than React, and we're _very_ happy with that choice. There's many reasons why (specifically the Composition API is similar to React Hooks, but in my opinion _much_ better thought out, and so is the fact that the state-management story is much more opinionated/first-party), but rather than start a framework war, I will say that every FE engineer we've hired who preciously worked at a React shop (which is all of them) has gotten the hang of Vue within a week and finds Vue a refreshing breath of fresh air. Me included.
I think React without a doubt has the largest ecosystem. And I also think Vue is more than a valid choice, and definitely not a problem in the hiring sphere.
The vdom and batching updates is slow, the theory behind it that direct manipulation of the dom is worse has been pretty conclusively shown to be incorrect, especially with css "contains".
JSX doesn't end up bringing much value over vanilla html, but can lead to a lot of strange and difficult to reason about states.
The "execute everything on every render" style ends up being extraordinarily costly and not particularly beneficial, especially when you add something like redux to the mix.
Alternately, web components have a simple, lightweight and easy to understand life cycle.
Reactivity is trivially implemented via property setters and a call to a render() method.
Tiny, fast rendering libraries like lit-html work great, and for other components you can do without them completely, depending on the needs of the component.
React needs at least one build step, which distances the developer's code from what executes.
Vanilla web components are simple to wrap into framework components for pretty much any framework, and can be used natively by most.
React components are limited to react things, unless you want to include an absurd js payload size.
And "just use react" doesn't really mean anything. What version? With what methodology? Hooks? Class based? Look at how much it's changed. It's very costly for organizations to get caught up in the framework upgrade cycle.
There's a reason why Ionic chose to base their components on native web components. I recommend you read about it.
> JSX doesn't end up bringing much value over vanilla html
> Tiny, fast rendering libraries like lit-html work great,
It's always funny to me how people bash JSX and then praise lit-html that literally has things like ?value and .click that it parses from strings using regexps, but it's somehow "better than react because native web standards".
And lit in general is busy re-inventing react (working on context API as we speak).
I think the Context proposal is rather "send function to data" style data flow. (there's another one, more like plain client-server data flow; req-res) Not really "prop drilling" like its docs say.
I guess `.value` | `@click` is pretty much all tag template literal based libs do. The static parts need parsing, right? Though regex would be slow (if they do), a tiny parser would suffice.
You either provide a custom DSL and embrace it or you claim to be "native standards" and bash JSX.
As far as I understand it's no longer just static parts either. Can't properly test this on mobile, but it looks like function calls like classMap or styleMap are only allowed in certain locations of the code, so it's already JSX-level (or more) manipulation.
This depends on the use. For a complex web app, React may be a good choice. For a web page with interactivity (There is a grey area between), native HTML/JS/CSS provides a much more responsive experience to the user. Faster load, lower latency, and reduced RAM use. It also makes it easier to develop and maintain, due to not relying on a build process or DSL.
or even
https://opensource.adobe.com/spectrum-web-components/
are simply much better as they just work with native web standards. React is just another way FB/Meta hurts people :)