Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

Post reply on HN
Print view View original

581–590 of 866 posts

Re: React is winning by default and slowing innovation

#581

Post by ramon156 »

WuxiFingerHold wrote: post #321
alok-g wrote: post #304

Earlier quoted context omitted.

Which is your favorite, and why? :-)

No OP, but I've also used Angular, React, Vue, Solid and Svelte in real world projects and my default choice is Vue, because it's on par with Solid and Svelte (and with Vue Vapor those three are basically the same) but with the larger ecosystem (vuerouter, vueuse, nuxt, nuxt-ui, primevue, nuxt-content, ...). I must also say that React was by far the most unpleasant and unproductive to use.

I keep reading unpleasant without any arguments. React is simple by nature, what made it unpleasant and unproductive? Granted I mostly do work on Shopify apps, so most of the heavy work has been done for me, I just put components together. This works fine, and I'd rather do this in React than e.g. Angular due to the small scale of the apps. Then again web components would've also been fine.

Re: React is winning by default and slowing innovation

#582

Post by degun »

WA wrote: post #553
spankalee wrote: post #157

Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an…

Web components are an implementation detail. They don't bring anything framework-like to the table. The most important being: reactivity. You have to write DOM manipulations imperatively like you did 15 years ago with jQuery. If you don't want that, you gotta bring a wrapper or another reactivity library/framework. For many use cases, there's not much difference between writing a Web component or an IIFE (Immediately…

The offer a way to build custom components that you can use everywhere, on every frontend framework, or plain html page. That's something that can't be achieved with any other tool. Also, if you use the Lit framework to build web components, @property and @state are reactive. The DOM part that uses those variables updates by itself.

Re: React is winning by default and slowing innovation

#583

Post by nikitaga »

WA wrote: post #553
spankalee wrote: post #157

Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an…

Web components are an implementation detail. They don't bring anything framework-like to the table. The most important being: reactivity. You have to write DOM manipulations imperatively like you did 15 years ago with jQuery. If you don't want that, you gotta bring a wrapper or another reactivity library/framework. For many use cases, there's not much difference between writing a Web component or an IIFE (Immediately…

> If you don't want that, you gotta bring a wrapper or another reactivity library/framework.

Being able to use a different library with a component, instead of the component being tied to React, is the whole point.

React isn't 100x more popular because its reactivity system or any other feature is 100x better. Half the reason it's popular is network effects – too many frontend components / libraries are made React-only even though they don't need to be React-specific.

Those network effects are the trap, not the reactivity system that's as good as any other for the purpose of writing a Web Component. If you don't want to use simple and small tools like Lit.js, that's fine, but that's your choice, not a limitation of Web Components.

The point of Web Components is not to provide a blessed state management or virtual DOM implementation that will have to stay in JS stdlib forever, it's to make the components you author compatible with most / all UI libraries. For that goal, I don't know of a better solution.

Re: React is winning by default and slowing innovation

#584

Post by baxuz »

whoknowsidont wrote: post #341

React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian. Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.

React is a good POC and a was a necessary step, but it's far from well designed.

The performance is atrocious unless you want to spend most of your time ejecting from the framework to do any realtime work, and building meta-tooling that uses direct DOM manipulation and only occasional state syncing with React, like video keyframes.

This is the approach taken by many projects, including tldraw, framer, everything from poimandres, and many things from tanstack.

The issue is that it's a "demented" framework where everything re-executes all the time and it's up to you to manage repainting and memoization manually. Because a "render" is executing the entire component tree.

The compiler is just a massive band-aid on a fundamentally broken architecture, that every other framework has moved away from.

Re: React is winning by default and slowing innovation

#585

Post by chrismorgan »

kqr wrote: post #528
chrismorgan wrote: post #524

Earlier quoted context omitted.

> 1. Import React. This is the step you can do from a CDN instead of you want a faster initial page load. Using a CDN is very unlikely to get you a faster initial page load. Initialising an HTTPS connection to a new host is almost always going to take longer than serving that file first-party; there’s even a decent chance of this if your server is on the other side of the world.

The problem in this case is not the HTTPS connection, but the fact that browsers, when importing ES6 modules, import all their transitive dependencies one by one. This means they can make a bazillion requests under the hood when importing just one library. A CDN is likely to have the library bundled and minified with its dependencies, turning those bazillion requests into a single one, which is much faster.

In that case, if you’re actually talking about bundled versus many-files, please don’t say “CDN … if you want a faster initial page load”. Public CDNs made some sense as performance advice long ago, but now they never really do, but there are still many people who don’t realise it.

Re: React is winning by default and slowing innovation

#586

Post by WickyNilliams »

gloosx wrote: post #576
WickyNilliams wrote: post #570

Earlier quoted context omitted.

Disagree about it being a rookie mistake. In the simple case, yes. But consider data used by an effect could travel all the way from root to the max depth of your tree with any component along the way modifying it, potentially introducing unstable references. Maybe it worked when you tested. But later someone introduced a new component anywhere between data source and effect which modified the data before passing it…

>But consider data modified This is why we never modify data but create new data. Data must be immutable. Strictly typed. Always in the form it is expected to be. Otherwise - crash immediatelly. >But later someone introduced This is why we write integration tests. Introducing anything without tests is only guesswork.

Sorry I should have been more precise. I don't mean mutation, but taking the data and producing a new (potentially unstable) reference to pass on. Mutating data in react results in under not over firing.

It is practically impossible to have full coverage of all code paths in integration tests, since there is a combinatorial explosion of paths. In a case where you have 3 components each with 3 paths you have 27 unique paths. And no app is that simple in practice. It gets out of hand quickly.

Re: React is winning by default and slowing innovation

#587

Post by thedelanyo »

gloosx wrote: post #519
WickyNilliams wrote: post #513

Earlier quoted context omitted.

Hooks are very much not normal functions though. They are a new "colour" of function much like async functions - they can only be called in components or other hooks, they cannot be called conditionally, cannot be called in loops etc. The so-called "rules of hooks" (To get ahead of the common objection: of course it's still JavaScript by virtue of being implemented in JavaScript. But so are Svelte, Vue et all)

Surely they are not normal JavaScript functions, but at least the syntax itself is not turned into a DSL like we see it in Svelte or Vue. That is the main difference.

I can create a .svelte file and I can just write only just hmtl - prolly a block of texts within a p tag.

With jsx, I don't think it's possible - I need to return it.

So even if Svelte is a DSL, to me it feels closer to web standard and jsx

Re: React is winning by default and slowing innovation

#588

Post by mhitza »

lelanthran wrote: post #559
mhitza wrote: post #83

The javascript people should stop innovating for a couple of years. To much innovation that lead nowhere. How many ways can one build a web javascript project? Browser people should pick up slack and start developing sane components for the web. How about a backend-supporting combobox, or a standardized date picker across browsers? Then we wouldn't need to constantly innovate how we manage the state of those fundamen…

> How about a backend-supporting combobox, Interesting. How would this specification look, in context of browser standards? > a standardized date picker across browsers Not possible for the majority of use cases. Too much variation in what the date is used for and how the display must be constrained. For example the lack of constraining the dates makes it unusable in most contexts (flights, hotels, meetings, etc). Th…

> Interesting. How would this specification look, in context of browser standards?

I don't know how browser standards work. As an end-user, our feedback doesn't seem to be considered (see the recent XSLT discussion), never went through the trouble of finding out.

In terms of implementation, sure we don't need it to be backend aware (was just throwing that out there as a common pattern for which one reaches to components in frontend frameworks). What they could do is build upon datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... . There are two things they could do with that element to make it usable in this context.

1. A loading indicator, which could be enabled with a bool element property while the Javascript code fetches from the server the data and updates the datalist options. 2. Decouples presentation from value. In a standard select field the option's value can be (and often is) different from the label. In the case of datalist it's not possible. It basically autocompletes on the values that also act as labels.

> Not possible for the majority of use cases. Too much variation in what the date is used for and how the display must be constrained.

On almost all of my personal projects, I just use the built-in date and time pickers available in browsers. I very rarely can do so for client projects, because the inconsistent rendering and patterns across browsers. Having a fixed way of rendering and interacting with those input fields would go a really long way.

You're right on all those things related to constraints, and UX. But for most CRUD experiences you really need only a consistent cross-browser picker, instead of reaching for a component library. Some of what you're talking about can be handled with the browser based Javascript validation, while a couple tailored interfaces makes sense for essential flows where you want to improve user experience.

I've built my fair share of custom forms and controls for the critical flow, but for the common case, accessible (most component libraries weren't in the past) built-in components are better and generally good enough.

Re: React is winning by default and slowing innovation

#589

Post by magnio »

gloosx wrote: post #472

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

Man, I am glad I don't have to work with any developers for whom having to write "className" (which has been in the DOM standard since 2000) over "class" is a deal-breaker.

Re: React is winning by default and slowing innovation

#590

Post by WA »

nikitaga wrote: post #583
WA wrote: post #553

Earlier quoted context omitted.

Web components are an implementation detail. They don't bring anything framework-like to the table. The most important being: reactivity. You have to write DOM manipulations imperatively like you did 15 years ago with jQuery. If you don't want that, you gotta bring a wrapper or another reactivity library/framework. For many use cases, there's not much difference between writing a Web component or an IIFE (Immediately…

> If you don't want that, you gotta bring a wrapper or another reactivity library/framework. Being able to use a different library with a component, instead of the component being tied to React, is the whole point. React isn't 100x more popular because its reactivity system or any other feature is 100x better. Half the reason it's popular is network effects – too many frontend components / libraries are made React-on…

I get your point. I'm fully with you that it makes no sense to use React and write React apps if you can achieve the same without React. I hate the fact that many great frontend components only work with React, especially considering that React didn't properly support Web components for ages, whereas almost every other framework had no problems with them.

However, out of the box, Web components don't come with almost anything. Comparing React to Web components is comparing apples to oranges.

Lit is great, but Lit is a framework. Now you're comparing React with Lit. Different story than React vs. vanilla Web components.

Post reply on HN