Live data from Hacker News

React is holding me hostage

emnudge.dev

391–400 of 553 posts

Re: React is holding me hostage

#391
post #382

Earlier quoted context omitted.

JSX forces you into small tiny components because anything of any decent size becomes unmanageable. There's way too much mixing of JS into the template. Vue you can do Submit In React I've seen people do: if (!props.isFormValid) { return Submit ; } return Submit ; This is just an example, obviously you can write this better in React. My point is there's /always/ so much conditional markup like this in every react pro…

> JSX forces you into small tiny components I'm surprised you see that as a disadvantage, for me that's always the biggest advantage of JSX-style syntax! I don't want huge components that do everything, I want components to do as little as necessary to be actually useful. It's the same as if I were writing functions: keep them fairly small, make sure they're doing a specific thing usefully, and then compose them toge…

I also love small and well thought components. But as an engineering lead and manager it’s a lot of effort wrangling devs to do so. They always start small and then overtime converge on multiple return statements full of huge amounts of inline JS.

Re: React is holding me hostage

#392

Earlier quoted context omitted.

That’s highly dependent on the type of product / customers you have. If you’re running an online shop selling ice cream, going from 100ms to 2ms list sorting speed isn’t gonna get you more sales. I’d argue most online products are ice cream shops to some degree.

The data seems to indicate otherwise: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-... > A 2017 Akamai study shows that every 100-millisecond delay in website load time can hurt conversion rates by 7% > 10 years ago, Amazon found that every 100ms of latency cost them 1% in sales

Would be fun to see that revisited.

Also misleading to imply a linear relationship. There will be a marginal cost, but no reason to assume constant.

Re: React is holding me hostage

#393

Earlier quoted context omitted.

> return Submit ; In JSX, the "disabled" attribute is a boolean; so it would be just: return Submit ;

Incredibly this is more readable than the Vue example given as a reason why Vue’s syntax is better!

The fact is that Vue enforces this and react doesn’t. So most devs do not write things this nicely

Re: React is holding me hostage

#394

I never understood why React became so popular. I thought it was a kind of mass hysteria. I was exposed to a broad range of front end frameworks early in my career (Backbone, SproutCore, JavaScriptMVC/CanJS, AngularJS), one of my colleagues was experimenting with Google's PolymerJS and recommended it. After trying it out, I was blown away by its elegance and simplicity. Yet somehow it never caught on. When React came…

> It's not difficult to think of scenarios were it fails; for example think of what happens to an element's scroll bar after it has been re-rendered from scratch; it resets...

To this day I can immediately tell that an app was made using React once the first focus/selection bug rears its ugly head.

Re: React is holding me hostage

#395

Earlier quoted context omitted.

There's 2 things that I hate about react. 1) JSX - It's terrible. Svelte, Vue, Riot... they all got it right. JSX, mixing a weird syntax of HTML and JS together is just inferior to HTML with additional markup. 2) I don't know why but every react project has crazy levels of abstraction. Everything is 15 layers deep and making any sort of change requires way too much effort to navigate 15 files and code reading to make…

How is this example from vue docs: preferable to the jsx version: or even this loop example from the vue docs: {{ item.message }} better than its jsx counterpart? items.map(item => ( {item.message} ))

i dont have a dog in this fight but JSX is PHP all over again with additional "creative solutions" where html and js keywords clash. but they both make html less readable in different measure for different people. please carry on with the arguments :}

Re: React is holding me hostage

#396
post #87

Earlier quoted context omitted.

> In functional programming, functions are not allowed to do that. The only thing a function is allowed to do is return a value. Oh, yes, they are allowed to do that. You capture the effects into a list, and return the tuple of list and return value. If you feel like it, you wrap that into a monad to pretend you are only "returning" a single thing. > In FP functions can only rely on the parameters passed to it (it ca…

Wow, I've never seen a reply that so thoroughly fails to address any of the points it's trying to reply to. When you reply to "in FP, functions cannot do that (change state anywhere)", you say "you are allowed to do that: capture the effects into a list, return the tuple of list and return value" without realizing you're saying exactly the same thing?! The distinction between "return value" and "return value plus som…

You return a tuple, which first element is the value the function would return (I/E "return jsx stuff") and the second value is a list of operations (effects) you intend to perform I/E "I intend to change this variable to value X", "I intend to run this external function when these values change".

The function's only observable behavior is that it returns a tuple with JSX and some effect descriptors.

No, this is not basic FP. This is somewhat advanced FP.

Re: React is holding me hostage

#397

Earlier quoted context omitted.

Admittedly I haven't worked on a large multi team react project before but I thought the whole point was that Facebook found React scaled well with teams (vs the state of the art at the time) Not only can you componentise your UI code, but you can componentise your UI system meaning teams can develop independently of each other...

That's not what I see and hear though. People complain often about how complex things become with React and simple things take a long time to set up or develop, compared to rendering a simple template on the server side. Usually people are not FB and people often do not have the same kind of strict development rules or enforced discipline, nor are they as many people as FB. Maybe the FB tool is not right for them.

Where React usually gets complicated is when non-trivial state gets involved.

Once you have state that needs to span your application and prop-drilling becomes too much of a drag, the misalignment between React's "pretend we're going to redraw everything" and "I'm only changing this one field in my state" causes most of the issues with React.

Re: React is holding me hostage

#398

The whole thing around React is odd to me. People laugh at web development, especially the frontend, for changing libraries every week but you read a thread like this and everyone is so sure that React is a bad library and we should be using some newer library instead. I work with React daily and it has issues, but I find most issues can be worked around without much trouble. It's easy to hire people, onboard people,…

People laugh at web development, especially the frontend, for changing libraries every week that's a 2016 meme. Things have been remarkable stable since.

Except React decided to change to hooks and break all their docs. And Vue decided to break things with ver 3. And then there's Next. No, Nuxt. Wait, no, it's Nest. Or Sveltekit. It's not frontend anymore, it's more like frontend on backend, but not quite. No, is both now, we got interactive islands. And web components. Oh and wasm. Or was it blazor? And we have webpack. No, Vite. Or Parcel? Almost forgot, it's esbuild this week, innit?

But other than that, yes, frontend is pretty stable now.

Re: React is holding me hostage

#399

Earlier quoted context omitted.

> It's easy to hire people, onboard people Yes they'll know the React part. It's the Redux/Mobx/React Router/whatever snowflake libraries you chose part that will be more difficult. I really don't like incomplete solutions personally.

Well, don't use those. Pure React is enough 95% of the time, and then an additional 4.9% can be handled with jotai in a couple of places. React + GraphQL + jotai is my preferred stack

> Don't use those...then an additional 4.9% can be handled with jotai...

Needing Jotai on top of React's defacto state management is the issue. TFA talks about an ecosystem of libraries that attempt to fix React's shortcomings. Pure React does have undeniable shortcomings like proper, non-brittle routing.

Re: React is holding me hostage

#400
post #75

Earlier quoted context omitted.

Forms are absolutely a problem, though. Forms not being "reacty" isn't going to get you out of needing them.

As react is only the core library and not a batteries-included framework, you will often find additional libraries that help with certain use-cases. E.g. if you are dealing with forms a lot, I would strongly suggest using react-hook-form or formik.

I do use react-hook-form! It helps a lot.
Post reply on HN