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

781–790 of 866 posts

Re: React is winning by default and slowing innovation

#781

Post by Seattle3503 »

827a wrote: post #164
apsurd wrote: post #112

Earlier quoted context omitted.

+1 React DX is really great. It started really great and it got weird and bloated but it's still really great relative to the JS landscape hell. But, also yes, it's a pain in the ass and a frustrating kind of necessary evil. So there is room for improvements. Nextjs is a living hell. The ironic thing is AI makes it dramatically more tolerable to the point it's actually pretty good. But that can't be a good thing in t…

Next initially jumped the shark when they went all-in on server-side rendering. The reason why Vercel did this is clear: client-side rendered apps can be hosted basically for free on Firebase, Cloudflare, or S3, so the only way they can raise their Vercel cloud revenue is by forcing their users into a dynamic-first world, pushing so much complexity and dynamism into the framework that only Vercel could disentangle ho…

I had a friend rave to me about Next because, to him, page load times were absolutely essential for good search engine placement. I wonder LLMs will make this sort of SEO less important.

Re: React is winning by default and slowing innovation

#782

Post by nosefurhairdo »

AlexErrant wrote: post #746
nosefurhairdo wrote: post #404

Earlier quoted context omitted.

You don't have to use their hooks! Looking at your pastebin link, I would probably opt for something like a factory pattern instead: https://pastebin.com/PbnBqX4a Just because you're in React land doesn't mean you can't still write regular old js/ts and hook in only when you need it. I imagine you'd do something quite similar in any other framework.

I appreciate your example. Some libs do not expose "vanilla" js/ts functions that I can call - e.g. `LiveKitRoom` https://github.com/livekit/client-sdk-react-native It only takes 1 hook to pollute your entire factory pattern; the comparison to colored async functions wasn't spurious. Hook-only options seem especially prevalent in the React Native ecosystem (ironic, given the memory constraints of phones). Of course,…

You can't use their js sdk? https://github.com/livekit/client-sdk-js

Re: React is winning by default and slowing innovation

#783

Post by stack_framer »

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…

> conditionals are `if (...) { ... } else { ... }`

As long as you're not invoking a hook in those if/else blocks!

Re: React is winning by default and slowing innovation

#784

Post by Etheryte »

rimunroe wrote: post #646
Etheryte wrote: post #631

Earlier quoted context omitted.

I'd say that most of the time, that's the wrong thing to do. For the vast majority of effects, you don't actually want to call it for every variable that's referenced in it. A good example is literal arrays, functions, and so on, if you have a prop that's an inline function definition, you'll be calling the effect on every render because the reference is new. You could work around this by memoing every inline functio…

> You could work around this by memoing every inline function definition, but at that point, what are we even talking about. This is a normal part of optimizing React components and the exact reason for the React compiler’s existence.

If this was the case, why do we need to define the dependency list to begin with? If this was both the mainline right thing to do and the compiler can do it, why are we doing it manually? In that case we could just as well omit it by default and only have users define it when they want something different. The answer, in my opinion, is that it's just a patch over what's a leaky abstraction and the added overhead costs more than the benefit in the end.

Re: React is winning by default and slowing innovation

#785

Post by balamatom »

zelphirkalt wrote: post #672
balamatom wrote: post #415

Earlier quoted context omitted.

>You still get JSX Give me S-expressions instead. How else am I supposed to prove to frontend developers that I didn't make those up

S-expressions is basically the much better version, that doesn't need a special interpreter/parser and doesn't reinvent the wheel.

Natural language has parentheses. Math notation has those and different kinds of brackets, too. But tell me, what language has closing tags? A language for parrots?

Only half joking, it's same principle as how indentation-based Python ate world, while languages with `begin` and `end` keywords like Ruby and Pascal are hardly to be seen these days

Re: React is winning by default and slowing innovation

#786

Post by whoknowsidont »

rictic wrote: post #768
snemvalts wrote: post #710

Earlier quoted context omitted.

You can write const [a, b] = useState('x') in vanilla js and typescript. Hence it is not magic syntax .

Yeah, that's vanilla syntax. The semantics are fairly magic though. The component function that calls useState though isn't a normal function, it's a function that must be called in a special way by the React runtime in order to line up all of the hidden state that React maintains so that it can magically infer the data that your `useState` call maps to and then there's more magic to maintain the lifetime of that dat…

Some of you are really going out of your way to make this more complicated than it is.

Next you're going to complain about the fact that the compiler handles static variables with controlled allocations for you in C.

Like there's no rational basis for your complaints or critique other than grandstanding.

Re: React is winning by default and slowing innovation

#787

Post by koakuma-chan »

jjordan wrote: post #740
koakuma-chan wrote: post #147

Earlier quoted context omitted.

AFAIK "TanStack" doesn't support RSCs? That's a deal breaker for me. Also the guy named his framework after himself, it can't be good.

What do you get from RSCs that you don't get from creating a proper backend?

Having to glue the front-end and the back-end together.

Re: React is winning by default and slowing innovation

#788

Post by ipaddr »

johnfn wrote: post #154
ipaddr wrote: post #120

Earlier quoted context omitted.

It won by marketing and the angularjs to Angular breaking change. If they kept going with angularjs or had an upgrade path react wouldn't be default in the enterprise stack. That's all on Google. Meteor was node framework. jQuery is probably still more popular but it is only a lib. Vue had a Chinese language problem. React won because a framework by Facebook felt safe.

If every other framework failed because of , that does indeed sound like React won due to its own merits.

Merits yes technical merits no.

Products rarely win because of technical merits. Products win with marketing. Technical merits can add another layer to the marketing but without facebook's brand people would still be on angular.

Re: React is winning by default and slowing innovation

#789

Post by monooso »

whoknowsidont wrote: post #701
actinium226 wrote: post #379

Earlier quoted context omitted.

I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…

>I think it's very hard to argue that React is effective or well designed. This is a foolish take. React is the reason the modern web is as usable as it is. Anyone who contests otherwise is simply ignorant of web development history. >(and even Netflix is moving away from React They're not moving away from React, they're doing pure SSR with it. https://react.dev/reference/react-dom/server/renderToPipeabl... You don't…

> Anyone who contests otherwise is simply ignorant of web development history.

Or is perfectly aware of web development history and doesn't share your opinion.

Re: React is winning by default and slowing innovation

#790

Post by brazukadev »

austin-cheney wrote: post #779
brazukadev wrote: post #756

Earlier quoted context omitted.

Is it some bundled code or those ~4k lines are written just for that case? You don't reuse even your own code? I would start by organizing the code in a sane and logical way. But that's why I said, if you enjoy coding this way, great.

It is arranged in objects defined as TypeScript interfaces. It can be easily broken down into numerous smaller files and be equally organized, but then the code would be in multiple places without any benefits except that there would be fewer lines in one file. I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript. If they aren't…

> I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript.

I knew anything I said your answer would be something in this line. You think what you wrote is amazing but it is just verbose bad abstraction. If you think the difference between 4k lines of code and separated logical modules is just a matter of fewer lines (which might not even be the case), there is nothing I can say to you but it is funny that you use this terrible code as an example. You literally wrote all DOM manipulation repetitively and inefficiently by hand. But it makes you proud! Congratulations, I guess.

I couldn't care less about JSX tho you made too many assumptions about someone that thinks the example code sucks.

Post reply on HN