https://shoelace.style/
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 :)
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 :)
2. Have the "non-hurting" web components solved all the issues that literally no other "no -native-standard" frameworks have? https://twitter.com/Rich_Harris/status/1198332398561353728
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?
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.
To be fair, this happens with React too (all the time). It has more to do with the JS ecosystem than with the framework of choice.
That's exactly what they're not doing
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.
React itself is just function calls. JSX makes the function calls look like HTML. HTML is generated from these function calls at runtime.
Anyway, what editor are you using that doesn't support JSX? It has support for it in the major IDEs.
---
EDIT: add links of evidence
https://github.com/adobe/spectrum-web-components/discussions...
https://github.com/shoelace-style/shoelace/issues/525
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.
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…
Sure, and all you need are 50+ dependencies to work with those "standards": https://www.npmjs.com/package/@shoelace-style/shoelace?activ...
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.
2. Shoelace has far fewer dependencies than Ring.
Let us see,
Shoelace: https://www.npmjs.com/package/@shoelace-style/shoelace?activ...
7 user dependencies
46 dev dependencies
VS
Ring: https://www.npmjs.com/package/@jetbrains/ring-ui?activeTab=d...
60 user dependencies o____O
100 dev dependencies o__O
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.
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.
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.
That said I am also against choosing libraries based on political/ideological concerns. React is MIT anyways.
npm install @shoelace-style/shoelace => 19MB, 17 packages
npm install @jetbrains/ring-ui => 189MB, 560 packages
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.
This is just plain wrong. Like, unbelievably wrong.
> 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 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.
Context is a way to avoid prop drilling.
> The static parts need parsing, right?
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.