React I love you, but you're bringing me down • Hacker News Board

Re: React I love you, but you're bringing me down

#261

Post by pas » Tue, Sep 20, 2022, 6:14 PM UTC

bravura wrote: post #163

buscoquadnary wrote: post #147

Earlier quoted context omitted.

Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…

This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?

adopt better methodologies, languages (TS, ReasonML, etc), find what works for you, automate the hard part, find reusable patterns, don't settle for the popular but mediocre new stuff (eg. React)

Re: React I love you, but you're bringing me down

#262

Post by CharlieDigital » Tue, Sep 20, 2022, 6:18 PM UTC

zero_shift wrote: post #183

hnrodey wrote: post #116

Earlier quoted context omitted.

Are you finding much "professional traction" with Vue? I really like Vue and use it for personal projects but React seems to dominate the job postings.

Vue is mostly used in China, where there is a preference for Chinese tech.

That's probably not the reason why it's heavily used in China.

More likely there was some early draw based on Evan You being the figurehead and eventually a community that built up Chinese language documentation around it that made it more accessible to Chinese developers.

Re: React I love you, but you're bringing me down

#263

Post by mikeryan » Tue, Sep 20, 2022, 6:20 PM UTC

kayson wrote: post #170

mikeryan wrote: post #143

Earlier quoted context omitted.

Functional components tend to be easier to compose. If your class component has very specific functionality that you won't need in other components it's fine but if you want functionality that will be shared across multiple components wrapping up that code into it's own hook is easier to share across components then trying to use wrappers, extending classes and HOCs.

Can you give me an example? I didn't have that experience. I extended classes for everything and it was super easy. But as I said, I was probably using react in a fairly basic way.

For example you have a button that you want to add a hover effect to. So it's got "onMouseEnter" and "onMouseLeave" handlers that sets a "hovered" state variable to true/false.

If you have that functionality in a class component, and want to share it with a new link component, then the React Class way is to create a "withHover" HOC and wrap your link component in it. withHover(LinkComponent) which will have the necessary variables and pass them as props to your LinkComponent which is "okay".

But what if you have like 5 of these little hooks? Your LinkComponent now needs to be wrapped in each (or them all wrapped into a single HOC) and has to accept the props for all of them. Or, if you're extending classes as you describe you now have class LinkComponent extends HoverClass, ClickClass, DataClass etc...

With functional components you have something like a "useHover" hook. It passes back the hover state and the "onMouseEnter" and "onMouseLeave" callbacks necessary for your link within the functional component itself. It doesn't have to expose props to it's HOC, so it's now self contained.

It seems the philosophy of react is to have a lot of "littler" discreet pieces of code be they components or hooks and not have to have a ton of dependencies between them. You tend to get better tests this way as well as it should make it easier for other devs as they don't have to know the whole system and can work on a more discreet bit.

I, personally, use function components pretty much exclusively these days. If the function gets too big with hooks I tend to just create a single hook from them, not because it's going to be shared but just to keep my code more manageable, the hooks create props and the components consume them.

To each their own. I don't seem to be frustrated by the problems many in this thread and the article share.

Re: React I love you, but you're bringing me down

#264

Post by javcasas » Tue, Sep 20, 2022, 6:22 PM UTC

xtracto wrote: post #213

rafale wrote: post #29

I prefer Angular. I never could accept writing css/html in my javascript. To be fair, my background is from XAML, so declaring the state separately and simply binding to it in my html template felt natural. The whole functional approach in React is overkill imo. It's okay if the state mutates in 90% of scenarios. Where there is really benefit from immutable states, I can enforce that on my own.

Yes yes yes! I´ve done some React at my job and also done some Angular/Ionic before. What I never understood of React is why did the creators decided to throw DECADES of Software Engineering development and comingle presentation layer with logic... To separate Views from Logics was an agreed good practice in Software Engineering since I was in undergard school 20 years ago.

That's fair. Why write html in javascript, when you can write shitty javascript in the templates (via ng-if and ng-for)?

Re: React I love you, but you're bringing me down

#265

Post by Rapzid » Tue, Sep 20, 2022, 6:22 PM UTC

Jasper_ wrote: post #207

joshribakoff wrote: post #166

Concurrent react actually makes your app less concurrent: https://github.com/facebook/react/issues/21668 5yrs in progress, it’s still not documented let alone fixed. I tried to look at the code, and they make giant PRs and are experimenting with priority queues and bitmasks, which seemed pretty off in the weeds to me.

Oh wow. I was always skeptical of "concurrent React" (the scheduler approach seemed insane to me), but this seems like such a basic issue, I'm surprised this ever shipped in any form.

Yeah, it seems suss AF.

IIRC it also only bales out during the DOM update phase; not during the calls to render() and then reconciliation(?). And if it bales out, it has to re-render everything again when it comes back to make sure the state is consistent(nothing has changed).

The exact details are fuzzy and that may be incorrect but the impression I came away with after reading an engineering post about the deets was that:

* The risk of thrashing seemed very high

* Debugging performance issues seemed like they were going to be a nightmare. Worse than right now. Worse than hook hell.

This line from the song Taro comes to mind: "Do not spray into eyes. I have sprayed you into my eyes.

Re: React I love you, but you're bringing me down

#266

Post by pier25 » Tue, Sep 20, 2022, 6:25 PM UTC

addicted wrote: post #241

pier25 wrote: post #103

Earlier quoted context omitted.

> The two-way data binding in Svelte saves ~4 lines of reusable hook function Based on the RealWorld projects, Svelte saves you around 50% in loc vs React. https://medium.com/dailyjs/a-realworld-comparison-of-front-e...

That’s from 2020 and I’m pretty sure that’s using class components, considering the latest implementations has a separate (using hooks) implementation.

Yeah unfortunately the author hasn't kept making these articles.

You can see the React+Redux implementation here:

https://github.com/khaledosman/react-redux-realworld-example...

Re: React I love you, but you're bringing me down

#267

Post by datavirtue » Tue, Sep 20, 2022, 6:26 PM UTC

narrator wrote: post #138

yamtaddle wrote: post #86

Earlier quoted context omitted.

Nope, I'm with you. React inventing a half-baked, partial re-implementation of objects/classes (in a language that already has them!) with super-weird declaration syntax & runtime behavior, just to avoid telling their userbase "Ok you will have to use classes sometimes, for certain functionality", was when I started looking around, because they were clearly out of real problems to solve that were sufficiently good-lo…

The cycle of javascript libraries: * SHOW HN: UberTinyUltra.js Here's my new super light-weight 4k Javascript Library! * How I switched to UberTinyUltra.js from PopularFramework.js and simplified my life! * SuperCoolStartup switches to UberTinyUltra.js * How I built my unicorn on UberTinyUltra.js * UberTinyUltra.js 2.0 now with a compiler, classes, typesafety and a C++ like turing complete template language to take o…

Often, things don't get bloated because the developers are bored, it stems from users requesting features because they are doing it wrong.

Sort of how AWS keeps mucking with Lambdas so that thier customers can keep doing it wrong and paying too much.

Or how doctors just give patients scips if they ask about a drug and it won't incur them any liability.

Over and over I have seen the world shout the praises of a new paradigm that solves a problem...except they totally misunderstand the concept and run in an unintended direction. No one can fight that momentum. So they don't. It happens with nearly everything in tech.

Re: React I love you, but you're bringing me down

#268

Post by jnsaff2 » Tue, Sep 20, 2022, 6:27 PM UTC

azemetre wrote: post #251

sergiotapia wrote: post #60

Since quitting React I've been happier with my day to day. Phoenix Liveview came in clutch and showed me I don't have to put up with these kinds of self-inflicted problems. If you're tired of React and the npm lunacy, I recommend you take a dip into Elixir and Phoenix Liveview. Take it for a spin, see how much better it is for you and your users. It's _sane_. You don't have to "split the context" anymore. xD

What are some resources (book or courses or videos or blogs) you'd recommend for learning Elixir and Phoenix?

I can recommend this book currently in beta, that has been pretty good at keeping up to date with most developments in LiveView.

https://pragprog.com/titles/liveview/programming-phoenix-liv...

Re: React I love you, but you're bringing me down

#269

Post by pier25 » Tue, Sep 20, 2022, 6:27 PM UTC

WHATDOESIT wrote: post #197

pier25 wrote: post #99

Earlier quoted context omitted.

I totally agree. I actually stopped using React around the time hooks were announced. In retrospect it's still not clear if hooks were even a good idea. Changing the core methodology of a project used by millions of developers at the time was extremely irresponsible. They basically made obsolete all React educational resources overnight. I'm sure people making money by producing React educational content were very ha…

There was no way to make async rendering possible with classes. It was necessary and they spent a lot of time trying different approaches that'd continue the old paradigm, but it couldn't be done.

Maybe, but would you need async rendering if React wasn't so slow?

Re: React I love you, but you're bringing me down

#270

Post by ravenstine » Tue, Sep 20, 2022, 6:28 PM UTC

azangru wrote: post #124

ravenstine wrote: post #21

Earlier quoted context omitted.

What React does is no longer novel. People have both cloned React and have made other libraries/frameworks that accomplish the same thing differently or even faster in some cases. Frontend craft has also become too complex in general. We really need to step back and decide whether all this fucking shit around SPA, SSR, route splitting, transpiling, everything-as-a-type, "me too" features between frameworks, overempha…

> React takes us forward in the sense that most of us don't want to go back to direct DOM manipulation There was recently a demo of what a Todo MVC app might look like if written in vanilla JS with today's apis. It looks fairly decent; I could see myself going back to something like that: https://frontendmasters.com/blog/vanilla-javascript-todomvc/

It's definitely feasible and even pleasant to write a frontend app in vanilla JS, if it's relatively simple. I hate to be that guy, but... does it scale?

Perhaps it can. I haven't really tried to write a large scale frontend app in vanilla that is similar in complexity to apps I've worked on that have millions of users. Maybe it's feasible, but it would take a lot of dedication to "do things right" by the developers on the team.

Also, reactive templates pretty much kill any desire I would have to by relying on direct DOM calls. With something like React or Svelte alone, there's practically no disadvantage to using them even strictly for rendering besides added file size. With vanilla, it would take more effort to make things efficient because you don't necessarily just want to call render() whenever something changes. It's really nice having a templating system that allows you to change things surgically without doing a lot of extra work rerendering things that shouldn't actually change.

However, I think vanilla JS rendering definitely has a place in terms of writing small, purposeful, modular components. Frameworks should make it straight forward to use vanilla components so that things that would be more succinct in vanilla can be written as such.