Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React is holding me hostage

emnudge.dev

Post reply on HN
Print view View original

381–390 of 553 posts

Re: React is holding me hostage

#381

Post by bernawil »

Accacin wrote: post #186

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.

Re: React is holding me hostage

#382

Post by MrJohz »

philliphaydon wrote: post #356
azangru wrote: post #347

Earlier quoted context omitted.

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} ))

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 together like Lego bricks.

When I was doing more Vue work, this is one of the things that I struggled the most with, that splitting one component into two components required a load of boilerplate and a whole new file. (And that itself was a big improvement on Angular, which usually had multiple files doing different things, at least when I was last using it). This inevitably meant that I'd try and fit more and more stuff into a single component until it the pain of maintaining it was greater than the pain of splitting it. (At which point it would usually be a lot harder to extract the would-be child component than it needed to be, because I'd left it too long.)

I think the rest is mostly just syntax preferences. Like you say, you can write bad code in both cases, and I think a lot of it comes down to which matches better to your mental model if what HTML generation looks like. But being able to easily start a new component, just like starting a new function, is such an important benefit of JSX, for me at least.

Re: React is holding me hostage

#383

Post by patdx »

activitypea wrote: post #148

``` The quickest obstacle you’ll run into as someone new to React will be something like this function MyComponent() { const [num, setNumber] = useState(42); // infinite loop setNumber(n => n + 1); return {num} } Trying to make state updates at the top level of a component will result in an infinite loop. ``` I've taught React to dozens of people without ever seeing someone try this. A render function is an idempoten…

That’s a good point, that example does feel a bit contrived. Interestingly though it is actually “canon” to call setState within the render function (for certain rare situations). I didn’t actually know this until I read the React beta docs: https://beta.reactjs.org/learn/you-might-not-need-an-effect#...

Re: React is holding me hostage

#384

Post by bernawil »

tomgp wrote: post #192
onion2k wrote: post #103

Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds. I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed…

> I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed then I would always expect that to cascade down the node tree. That could cause further updates. And more renders. That behavior is on me. If the framework decided not to cascade some updates that would be weird. It's not that the properties shouldn't be update…

> Svelte just changes the relevant bit of the DOM,

Because Svelte is mutable state galore. I thought we all agreed to say no thanks to that.

Re: React is holding me hostage

#385

Post by PaulHoule »

javcasas wrote: post #366
PaulHoule wrote: post #300

Earlier quoted context omitted.

That is one of the many partial answers that works some of the time but not all of the time. For relatively simple applications you can push all the state high up to the root of the tree or near the root of the tree and have it flow down with props. There is a complexity hierarchy and around the time people woke up to AJAX (there were a few years when it was just a ‘evil Microsoft thing’) I was writing apps that were…

> it is worse when the user can instantiate arbitrary components (say for a knowledge graph editor or a geospatial intelligence tool) that ‘listen’ to event changes. Your application is effectively "anything can modify anything", which is the previous step to "anything modifies anything", I/E big ball of mud. React's answer to that is "keep all the state in a small component" (small ball of mud) or "keep the state in…

I'll push back on that.

In those two applications I joined failing projects that really were a "big ball of mud" and got them working. I didn't just figure out a working solution to the async updating problem, I became intimately familiar with seductive non-solutions.

The problem with the discussion about React is that 99% of the use cases of React don't need to be an SPA. If it's possible to SSR your application you don't need React! Those applications I worked on were dramatically more complex than today's SPA because they needed to be SPAs!

Back in the 1990s people would define a web form in a static HTML page and then write a separate CGI script to handle the form. If there was an error in handling the form the CGI script was unable to redraw the form with an error message and the values filled in because the CGI script didn't contain the form.

Around 2000 or so people realized the answer to this was for the form to drawn by the same script as the form handler, and the script would choose to either draw the form or the next thing after the form based on the inputs it received. Ruby on Rails institutionalized this around 2005 and misappropriated the name "model-view-controller" for this.

Not long after 2010, for reasons I still don't entirely understand, the web design shops in my county transitioned from successfully writing quality RoR apps to attempting to write "simple" Angular apps. How to do error handling for forms on the server side got forgotten like the formula for Damascus steel and instead people started writing SPAs to do what would have been a trivial task in a server-side application except now the application is "a tiny pebble orbiting a supermassive black hole made out of dark matter".

People who are happy with today's SPA frameworks are happy because they are developing applications that don't need to be an SPA. Once you get into the range of applications that really need an SPA they let you down.

Re: React is holding me hostage

#386

Post by philliphaydon »

mattwad wrote: post #376
philliphaydon wrote: post #370

Earlier quoted context omitted.

> This is just an example, obviously you can write this better in React. The issue is people write SO much conditional logic into their react templates. Not that disabled is boolean and can be written better.

Trying to be fair here, but what about vue makes it less likely that you won't put the same conditional logic into your vue template? If it's just impossible, then you're saying the framework is more limited, which is fine but sometimes you want flexibility. This seems to be a 'best practice' issue as well that can be avoided through PR review. My team has been putting logic more and more into local hook files to kee…

There's nothing inherently stopping people from writing clean react projects. But I've never seen one. But watching people fumble around trying to find where they need to make a change when things are so overly abstracted, and STILL try to justify that react is good, is baffling.

People break tables up into ~50+ files. It's crazy, and everyone does this, and its an absolute nightmare to maintain. Its 100% engrained into react culture that this is the right path forward.

React will never get better if people accept over abstraction as the right path forward.

Re: React is holding me hostage

#387

Post by mattigames »

bern4444 wrote: post #95
mattigames wrote: post #84

Earlier quoted context omitted.

"Doesn't reinvent the wheel" they literally created a whole new language called JSX, I have 13 years writing JS and I dislike React and JSX is one of the reasons. As far I can tell reason it's picked a lot of times now it's market share, people see that is more popular than the competition so they try to learn it, creating a feedback loop that just makes it more popular.

JSX has been around for 7 or so years... that's a good amount of time. Over half of your 13 years :) Do you avoid JSX when using Vue or other libraries that support JSX? Are you invoking the library function directly - React.createElement or vue's equivalent instead?

Yes I do, the only language I use for my personal projects is Typescript; I think JSX, .vue, .svelte they are all a mistake, JS is more than enough if you really need to use it to compose html.

    div('#wrapper',
        div('.container',
            span('.big', `It's not that hard`),
            button('.red', {route: home}, 'Home!')
        )
    )

Re: React is holding me hostage

#388

Post by reactus »

jongjong wrote: post #284

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…

From the moment I understood the weakness of vanillaJS, it disgusted me. I craved the strength and certainty of unidirectional data flow. I aspired to the purity of Blessed Functional Programming. Your kind cling to fad frameworks and half-baked web components, as though they will not decay and fail you. One day the crude spaghetti code you call an "app" will wither, and you will beg my kind to save you. But I am already saved, for React is immortal...

Re: React is holding me hostage

#389

Post by uranusjr »

wokwokwok wrote: post #278
uranusjr wrote: post #226

Earlier quoted context omitted.

JavaScript is a better, but JSX is not JavaScript. It reuses many features from JavaScript, but you still need some sort of translation (compilation) step to make it useful. In this sense it is not really fundamentally different from any of those what you call template languages. You can argue the fact JSX better integrates syntaxes from a proper programming language makes it better than other templating languages (a…

It is javascript. That is literally the difference between JSX and most other template languages. Look it up. The template syntax is converted to literally code and evaluated. The are just syntax sugar. How did you imagine the inline code works? The in-line function declarations? Did someone invent a mini-subset of JS as DSL and a custom runtime…? Don’t be ridiculous. They did not. JSX is literally a thin wrapper aro…

Template language being translated to code is nothing new and certainly not unique to JSX even only when you consider frontend JavaScript frameworks. Vue has been doing that ever since single-file component was a thing. You need to look up things, please.

Re: React is holding me hostage

#390

Post by jaywalk »

YPCrumble wrote: post #375
azangru wrote: post #367

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!

How so? I don't use Vue or React, but I don't see any real difference in readability between the two examples. They're both very straightforward.
Post reply on HN