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

801–810 of 866 posts

Re: React is winning by default and slowing innovation

#801

Post by Illniyar »

Eric_WVGG wrote: post #722
Illniyar wrote: post #712

Earlier quoted context omitted.

I don't know about Mac, but windows had WPF, winforms, UWP - all blessed by microsoft (I'm sure I'm missing a few), and often maintained at the same time. A huge amount of windows apps were built with Java, you had to install the JDK separately - one such thing that comes to mind is Minecraft, another is Jetbrains IDE. Most of the major native apps you use most often, like browsers, render things directly using Direc…

I concur that Windows has always been a mess, but at any given point, wasn’t one of those things the “prescribed way” of doings things? Like, I get that Win32 is never going away, and some of the ideas were busts. The Java phase I think is more analogous to modern React Native and Electron apps.

They were newer. I don't know if they were prescribed. It took a long time for newer frameworks to reach feature parity and even longer to get deprecated.

Microsoft would routinely suggest both, I think there were articles in MSN showing how to do stuff with each side by side. Like programming language flavors.

Linux is even more of a mess I imagine. I think Mac, and especially iOS, were the odd ones out. The Apple ecosystem is built on making sure everyone does things their way. And that translates to having one blessed framework you must use.

Re: React is winning by default and slowing innovation

#802

Post by TomaszZielinski »

mike_hearn wrote: post #770
TomaszZielinski wrote: post #660

Earlier quoted context omitted.

I can’t recall a single time where I would want to put JSX in an „if” statement.. In fact I can’t recall a single time where I would want to use JSX in a different context than the return value of a render phase. So from my personal experience the things you mentioned are non-issues in practice. Do you have a different experience?

I was actually meaning the hooks and memoization stuff not JSX. I think JSX can be put inside conditional logic and loops.

Ah OK, I see it now—I focused too much on the „magic syntax”.

As for hooks, I guess I mentally treat them as magic that lives in its own lane, and so I've never really thought that I could do anything with them, other than what the manual prescribes.

Re: React is winning by default and slowing innovation

#803

Post by conartist6 »

snemvalts wrote: post #710
conartist6 wrote: post #619

Earlier quoted context omitted.

Hooks are magic syntax without any doubt. All magic syntax is made up of non-magic parts, that's kinda the point. The way you know it's magic is it shatters the principle of referential identity, which tells you that a variable is itself. It pretends you can use a simpler mental model but you really cannot and must not.

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

Your example usage only implies what I would consider the non-magic implementation behavior. I could fulfill that contract with `(initial) => { let s = initial; return [ s, v => s = v]; }`. No hidden magic there, and no chance of breaking referential identity.

Re: React is winning by default and slowing innovation

#804

Post by austin-cheney »

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

Earlier quoted context omitted.

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 no…

It is not abstracted at all. It isn't awesome. It is organized according to the TypeScript definitions in the project. The rest of your opinion is challenging to infer because there isn't anything of substance. Really your opinion can be reduced to: I don't like it. That's fine, but it isn't helpful. Its also why I am forced to make assumptions.

It isn't about being proud, or awesome, or some silly vanity. Its about being fast, almost 100ms fast, and organized well enough for quick maintenance.

Re: React is winning by default and slowing innovation

#805

Post by AlexErrant »

nosefurhairdo wrote: post #782
AlexErrant wrote: post #746

Earlier quoted context omitted.

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

No, sadly. I use some features that require the usage of native code, e.g. native echo cancellation, foreground service to keep the audio running when the screen is off, etc. The sdk-js is meant for browsers.

Re: React is winning by default and slowing innovation

#806

Post by dottjt »

zelphirkalt wrote: post #666
dottjt wrote: post #86

Earlier quoted context omitted.

> Yet I still have to begrudgingly use React in several contexts because of the industry-wide inertia, and I really wish I didn't have to. I think you'll find a lot of people begrudgingly have to work and really wish they didn't have to. That means using what they know, which means React. Which I totally get. People want to spend time with their kids, hobbies etc. Worst case, they might be caring for others, like the…

I feel like you derailed the point made. It was not about having to work at all, but about what tools to work with.

Yeah, but having to learn new tools is more work than using the tools you already know. That's the point I'm making.

Re: React is winning by default and slowing innovation

#807

Post by WickyNilliams »

rick1290 wrote: post #751
WickyNilliams wrote: post #535

Earlier quoted context omitted.

Hey I worked on that! And nordhealth.design. Both were used with React. And Vue, and angular, and classic server rendered apps like django

Which pages are django?

Nothing on those docs. But the components were consumed in a Django app

Re: React is winning by default and slowing innovation

#808

Post by the_gipsy »

cjonas wrote: post #716
the_gipsy wrote: post #706

Earlier quoted context omitted.

But you cannot really develop anything meaningful without adding frameworks. I guess redux solves both "state" and "messages" at once, that's good. But what you work with then is not "vanilla react" at all. I don't even think "vanilla react" can really exist, beyond toy examples. You either use frameworks or write them yourself (worse).

> But you cannot really develop anything meaningful without adding frameworks. You can develop extremely powerful web-apps using just React + Redux. Once you need to start dealing with SSR for SEO & server side caching, data preloading, hydration, etc... things get complex. But honestly that's because those concepts are inherently complex and that complexity can only be reduced so far. Another problem is they get bak…

I agree, but my point is that it's detrimental to claim that react is just "function composition".

Re: React is winning by default and slowing innovation

#809

Post by nosefurhairdo »

AlexErrant wrote: post #805
nosefurhairdo wrote: post #782

Earlier quoted context omitted.

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

No, sadly. I use some features that require the usage of native code, e.g. native echo cancellation, foreground service to keep the audio running when the screen is off, etc. The sdk-js is meant for browsers.

Gotcha. I'm unfamiliar with LiveKit and React native so appreciate your clarifications. You've convinced me that your grievances are legit haha.

Re: React is winning by default and slowing innovation

#810

Post by rimunroe »

Etheryte wrote: post #784
rimunroe wrote: post #646

Earlier quoted context omitted.

> 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 cost…

> In that case we could just as well omit it by default and only have users define it when they want something different.

I believe the official recommendation since hooks were announced is to omit the array unless you need it. It makes things much easier to reason about, and many effects can run on each render just fine. It's mostly[0] a performance optimization. Oftentimes you'll want to make an additional comparison between previous and current props to decide if you actually want to do something anyway.

[0] Possibly entirely. Remember that useEffect's goal is to synchronize with an outside system. Additionally, while I can't find references for a similar thing in the docs for useEffect, for useCallback and useMemo the dependency array is explicitly not supposed to give any semantic guarantees about when the value will be re-memoized. React is free to "forget" values if it wants and re-memoize when needed.

Post reply on HN