Hacker News new | past | comments | ask | show | jobs | submit login

>are simply much better as they just work with native web standards. React is just another way FB/Meta hurts people :)

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.




1. You are not reading those numbers right!

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.


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.


> If you're doing JS development, just use React.

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.


Why is Vue off the table?

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.


Ability to hire. There are fewer vue developers and people tend to apply for jobs in tooling they already know.


I would argue that dev dependencies do not really matter. That leaves a mere 7, 2 of those belong to the same namespace as the style.

That said I am also against choosing libraries based on political/ideological concerns. React is MIT anyways.


It is not like I endorse (or don't appreciate) one or another, just a bit of stats

npm install @shoelace-style/shoelace => 19MB, 17 packages

npm install @jetbrains/ring-ui => 189MB, 560 packages


Sure, I'll bite.

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, but can lead to a lot of strange and difficult to reason about states.

This is just plain wrong. Like, unbelievably wrong.


> 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.


> Not really "prop drilling" like its docs say.

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.


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.


I’ve got a feeling this comment won’t age well…




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: