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

571–580 of 866 posts

Re: React is winning by default and slowing innovation

#571

Post by guappa »

IceDane wrote: post #414
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…

I'm wholly convinced that only people who have never tried to use web components for anything serious, and/or have basically no experience with web dev, are the only ones will make this argument. For example, a guy I know online who is an argumentative, boring backend dev that regularly has really bad and uninformed takes on things he has very limited experience with, he recently said he prefers web components. For a…

Calling someone else boring because they disagree with you instantly makes me think they are right.

Re: React is winning by default and slowing innovation

#572

Post by thedelanyo »

For me the biggest reason I prefer Svelte over React is the ecosystem.

When I was in the React world, the ecosystem felt closed and bloated (although I thought it was one of the biggest). For every task, there's a specific react-this or react-that library, which often comes with lot of technical debts and complexities. I think there are over 100 libraries just meant to solve state management - yet react devs are proud of that.

Svelte is a breath of fresh air for me. If a feature isn't built-in, I can usually just use a standard, framework-agnostic js library from npm.

I think this is better for everyone - developers get simpler, more robust tools, and library authors don't have to constantly maintain React-specific wrappers.

This advantage is compounded by React's frequent API changes, which make it difficult to keep up.

And I believe there many incredible react developers comfortable with the current setup in the React ecosystem, but I find Svelte's approach to be far more elegant and simpler.

Re: React is winning by default and slowing innovation

#573

Post by WickyNilliams »

patates wrote: post #567
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)

I really don't understand this colored functions debate. Async functions are just functions that return Promise instead of T. You can use them in a non-async function but you must then switch to callbacks, because you hold a promise. I don't get how this is confusing, unless you define the whole concept of concurrency in a single thread that runs your UI as well confusing. Hooks are functions that need to be called b…

It's not confusing. It's an observation on their nature. The colouring isn't specific to promises, or even async/await. It applies to continuation style callbacks too.

If you haven't, I recommend reading the (original?) article https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Re: React is winning by default and slowing innovation

#576

Post by gloosx »

WickyNilliams wrote: post #570
gloosx wrote: post #540

Earlier quoted context omitted.

Well, that is really embarrassing for Cloudflare... A recursion in a side-effect via dependencies is a rookie mistake, it's hard to imagine it could slip into production with a proper due process. Maybe they should stop vibe-coding and deploying things to production without any tests or review?

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.

Re: React is winning by default and slowing innovation

#577

Post by baxuz »

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.

Which is arguably worse, because syntax comes with expectations. The way React (and JSX by extension) works is effectively a bunch of overloaded macros, that depends on the pragma used.

And god help you if you want to mix component level code inside React-land and "vanilla". They had to add 3 new hooks over the last 5 years to try and alleviate those issues, all while gaslighting the community and tool authors that the were "holding it wrong".

SolidJS is far better when it comes to how well it follows expectations, and how well it integrates.

Re: React is winning by default and slowing innovation

#578

Post by cranberryturkey »

LandR wrote: post #461
cranberryturkey wrote: post #437

Earlier quoted context omitted.

Look, just because you're the most popular doesn't mean you're the best, did you fools not learn anything from high school? Look at Microsoft in the 90s-2000s -- terrible fucking software, but it was by far the most widely used.

Front end developers and not learning from mistakes of the past... I sense a theme here.

I don't know why I'm in the minority on hating on react any other big-tech "open" source frameworks.

Re: React is winning by default and slowing innovation

#579

Post by thedelanyo »

patates wrote: post #555
sensanaty wrote: post #526

Earlier quoted context omitted.

> 5 straightforward hooks `useEffect` is straightforward? Cloudflare recently (like, literally 4 days ago)[1] had a pretty big outage because of the improper use of `useEffect` (surprise, surprise, it was the dependency array), a hook so infamous if you search "When should I use `useEffect`" you'll get approximately 9 trillion hits, with nearly all of them telling you something different, including Dan Abramov himsel…

Javascript has warts, React has warts, Svelte has warts, Python has warts... It's easy to shoot yourself in the foot in any tech - it's leaky abstractions all the way down after all. useEffect usage needs to die, yes. I don't think it's a case against React, given its age. Otherwise, using React is straightforward. I started coding in it without reading any docs. As someone who used Dojo, prototype, ext.js, jQuery (+…

A child who hasn't tasted other mom's food always say, my mom is the best cook in the world.

You saying you can be productive in react is just ironic. I just read it as, I can be employable using React.

Re: React is winning by default and slowing innovation

#580

Post by zero_shift »

burnerzzzzz wrote: post #561
zero_shift wrote: post #504

Earlier quoted context omitted.

> So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? It would be best to think of it as syntax sugar for create Element() function calls. You enter JSX with angle tags and insert expressions in braces > React is full of magic syntax that looks like functions, but e.g. you can't call them inside an if statement, or you have to redundantly declare the 'dependencies' (variables you read) and so on…

> It would be best to think of it as syntax sugar for create Element() function calls Thats what makes it a new language. C is just sugar on top of assembly. Its so strange that jsx needs a buildstep, but misses ton of obvious ergonomics that one could have added. Why className instead of class? With a buildstep, it would surely be possible to determine if class was a keyword or not based on context

> Thats what makes it a new language. C is just sugar on top of assembly.

I think that's a bad example. C isn't a sugar for assembly: For example what assembly code does a function prototype desugar into? Sugars have 1:1 mappings with host code

Maybe you're just being rhetorical about the spectrum of macros, sugars, and languages, though.

(In my opinion, a better target for that criticism, in JS land, is the Jest test framework, because of all the reordering magic it does that break fundamental ES semantics)

> Why className instead of class?

This hasn't been a constraint since... I want to say React 18, six or seven years ago? I might be misremembering the history but I think that was only a problem in the Early Days when there was paranoia about whether JSX needed to be conservative with reserved keywords

Post reply on HN