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

What I wish I knew about React

bitsofco.de

Post reply on HN
Print view View original

61–70 of 301 posts

Re: What I wish I knew about React

#61

Post by valera_rozuvan »

If you look at it from one side, React doesn't have technical problems or the way it's built. If you look at it from another side - React opens up a wide range of possibilities - you can simply drown in them. Adequate things you have done all your life - suddenly feel not so adequate anymore :) For example, it would be fine to use plain old CSS, but with React it just feels wrong. If you look at the number of libraries that try to evolve CSS, there are many. But there is just no winner in sight. Pretty much the same situation is happening in state handling. The number of possibilities! It's amazing. Eventually, though, something gains momentum, like Redux did. This has consequences for React ecosystem, but also everywhere else in JS world. It slowly migrates to Angular, and other frameworks - as the cool kid on the block.

Elegant, simple concepts of React - they are outweighed by the environment they live in. React allows for rapid prototyping, provokes ideas which sometimes break traditional ways. Anyways, I will leave these thoughts with saying that personally I don't have issues with it. I adapt React to what I want - it doesn't adapt my thinking ;)

Re: What I wish I knew about React

#64

Post by mjfisher »

sunaurus wrote: post #50
irrational wrote: post #22

Earlier quoted context omitted.

Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.

I started my career with jQuery, and soon after moved to Angular v1. There was nothing simple about those tools - the mental models involved were complex, different parts of an application were difficult to isolate from each other and optimizing performance was a nightmare. Compared to all that, React is ridiculously simple - it has a very small API surface, different parts of your app are isolated by default and per…

When people say "web development used to be simpler", they're probably not referring to the front-end tooling (which has certainly improved) - but when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls.

Re: What I wish I knew about React

#65

Post by osdiab »

dvt wrote: post #44
osdiab wrote: post #30

Earlier quoted context omitted.

I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my…

> I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. Respectfully, that's not at all what HTML is supposed to be, but even so, as it turns out, sometime…

What do you think HTML is for?

If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not use React.

If you’re using the web as an application delivery platform that works cross platform without installs and instant updates, then HTML is the base of your UI framework, and as such it helps to have predictability that frameworks like React offer.

Re state, for me the “bad thing” about global state is usually the same “bad thing” about jQuery-based apps - that anything can mess with anything. But all the solutions you mentioned, and especially the Context API, force components to declare their dependencies and update shared state in restricted ways, which makes that “bad thing” much less bad.

If you don’t like shared state at all, feel free to not use any of those, and pass around state throughout the app - but don’t complain to me when synchronizing state throughout your web app becomes a problem, or that boilerplate becomes a drag, because those are the problems these solve.

Re: What I wish I knew about React

#66

Post by efdee »

7777fps wrote: post #54
efdee wrote: post #19

Earlier quoted context omitted.

Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount. Classes in React generate false expectations.

I liked that model because as an ASP webforms developer the class lifecycle is easy to reason about, like a page lifecycle. In ASP you wouldn't put initialisation code in the page constructor either, it would go in Page_Init, Page_Load, etc. Of course the tooling there made it both easier to put in the right place and harder to edit the page constructor to stick it in the wrong place.

I remember ASP.NET Webforms, and the reason most of the community moved towards MVC-ish frameworks is exactly that most of the time, you ended up shoehorning functionality into different lifecycle methods, which made them much harder to reason about. Most of the time, for anything more complex than just performing the initial databinding, you'd just be looking at the lifecycle chart and trying to figure out which place would be best to put which part of your code. Page_Init? Page_Load? Page_PreRender? I remember the pain of trying to add dynamic controls to a site right in time before ViewState was hydrated but AFTER something else had happened.

I agree that for the easiest of use cases, lifecycle methods make sense. But you very quickly leave that comfortable zone and then it just becomes painful and confusing.

Re: What I wish I knew about React

#67

Post by shlob3 »

irrational wrote: post #22
efdee wrote: post #15

Earlier quoted context omitted.

These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.

Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.

completely irrational comment - the web of the past was garbage and simplistic, and no amount of spaghetti jquery will ever change that HN is full of "le wrong generation"and nostalgia blinded devs who think everything in the past was better when it was complete rubbish just like the 90s

Re: What I wish I knew about React

#68

Post by 7777fps »

andrewstuart wrote: post #32
zappo2938 wrote: post #9

To understand React, it is important to understand the difference between imperative and declarative coding. [0] React is a way to write declarative code that use life cycle hooks or effects to do imperative "stuff". The best explanation oh how useEffect works is by Dan Abramov [1] It is also worth reading his article on React as a UI Runtime as it is a good explanation of React conceptually under the hood. [0] https…

This is a critical point to understand. If you're not doing declarative programming with React then you're swimming upstream. Problem is that the concept of declarative programming would be very difficult to get beginners to grasp. Once you grasp it though, it's absolutely incredibly powerful and importantly - simple. And this is where React loses beginners who jump to more intuitive programming models.

But that's great until it isn't.

You can design all the declarative things you want, but someone will eventually come up with a requirement that doesn't appear to fit a declarative structure, such as an event that fires 2 seconds after something else happens.

And so to resolve that you can construct state machines with transition states to get back to a declarative model, but those state machines can quickly become a bigger headache to maintain (yes, even with redux) than if you'd just been able to setTimeout from the component in the first place.

And you start with the best of intentions of re-usable components but find more things that ought to be owned by the component pushed up to the store and suddenly there isn't a neatly re-usable component but an empty shell of something that still needs the other half plumbed in manually every time.

I love the idea that you can abstract everything happening in an application to state and render reproducibly from that, but the reality is that it's really hard and time-expensive to do compared to jquery.

But that would be fine if the tooling was there. If React had a CLI like the AngularCLI it wouldn't be such a problem to add new actions, or new pieces of state, or new components.

But it doesn't, so each new component ends up adding a little more state into the state machine which ends up breaking types in far off places.

Now there's probably an assumption about how state is built up or how reducers are typed or how actions are defined that I'm missing some reason why this shouldn't be happening. But it is happening, it's the reality for the project I've been working on and it's a real headache.

Re: What I wish I knew about React

#69

Post by cmckn »

ng12 wrote: post #7
prodave wrote: post #2

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

> And anyone who has used classes in Java or other languages would feel at home. Not really because there's nothing object oriented about React.Component. It's just a wrapper for a function implemented as a class.

THIS is what I wish I knew about React. As a Java user, I made incredibly wrong and damaging assumptions because "classes, I know what these are"! I still can't make heads or tails of hooks, but in due time!

Re: What I wish I knew about React

#70

Post by ivan_gammel »

ddek wrote: post #57
dvt wrote: post #8

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra…

In the context of a website , I completely agree with you. No blog needs react. Reddit is worse because of react. However, given websites aren’t the only use of react I strongly disagree with your overall sentiment. My organisation uses react in place of desktop apps, and it’s been a game changer for us. We work faster, we train devs faster, deployment is easier, we can painlessly hit everything from desktops through…

This is that moment that proves we’ve made no progress on desktop. In 1990s we had Borland Delphi and CBuilder, in 2000s we had .Net and Qt, now this? How on Earth this is better?
Post reply on HN