Since Fiber, React has become difficult to reason about. There is a stateful crawler that is going up and down and sideways in your hierarchy, running code with side effects and telling you that it will isolate those side effects. The golden brick road is surrounded by briars, because you cannot know the nuances of that renderer’s contracts, because you cannot read the code of that renderer, because it’s too dense to understand. I miss the days when React was a simpler “dive” than Angular in this regard, and I could boast about its simplicity. In the interest of efficiency, we have forgotten how to climb the walls of our garden.
Absolutely. React started off simple but with things like Redux added on, it has become unnecessarily complex. The performance benefits of React is overrated. Javascript is so fast these days that you can rerender the whole page on navigation and no one will know the difference. I built a whole social network site based on a simpler alternative, UIBuilder, and you can see for yourself that it is performant: https://circles.app
UIBuilder is here: https://github.com/wisercoder/uibuilder
And once it's well baked enough, it works very cleanly with universal rendering strategies. It means you don't have to separate logic into components where it doesn't belong because the server render ignores loading logic in componentDidMount. It's suddenly all first class
And, then, theoretically you can remove Redux and just use Context
It has gotten really wacky along the way. I hope they don't lose sight
Hi, I'm Dan. I write boring code. I love Go because it's super boring.
I like to read boring code, write boring code, and then get on with my day. I don't like long walks through the codebase trying to understand how everything is wired up in a super-cool functional way. Get off my lawn kids.
I think it's mostly down to the paradigm you're most familiar with. Classes are normal to OO developers, functional composition is normal to FP developers.
This is simply not true. Your post is very strange, you just assume classes are simple and boring but everything else is 10-20 files with fancy magic and blah blah blah.
The truth is that Dan is wrong about what makes code boring. Immutability is boring. Dan just likes Go.
I like immutability. It can make code easier to read and understand if done well. But within reason.
It's not that I'm creating some strawman where the alternative to a class is 10-20 functions across as many files - but that's actually mild compared to some things I've really seen.
To give an example, about a month ago I had to read a co-workers implementation of a feature and it was literally a maze of some 30 functions many of which returning closures, some of which return other closures. With state scattered all over in withStateHandlers, etc. I spent two hours on a Saturday trying to understand it and make the changes I needed to make before I gave up and assigned the ticket to my coworker who wrote it all. Basically he's the only one now who can modify that code easily (and incidentally he's away now on leave, if we have to modify that code again, we're screwed.)
So immutability of data is awesome. Immutability of code is not. If it was a couple boring classes I could have read the code and made all the changes I needed to make in less than an hour.
Simple an predictable and boring is fantastic where code is concerned. I love Go not because of the features it has, but specifically because it's limited enough that the code written in it is almost always easy to understand.
A better bigger-picture innovation would be to have a React-alike that is actually only the view layer, and makes it significantly easier to write your business logic using plain old JavaScript functions/classes.
Ideally it would have an API that encourages you to write your business logic as a hierarchy of state machines, because that's what apps really are. But the state management should definitely be done outside React, similar to what Redux has done, where your actual state is transformed into props and passed into React.
Also, screw you HN for always penalizing my account so that my content shows up at the bottom instead of the top and has no chance of being seen. My content is good, your algorithms suck.
This. This is spot-on IMHO.
I'm not an expert by any means, but I wrote a fairly substantial react app recently, and I found that redux not only made this straightforward, but made it hard to do anything else. I did have to learn redux and redux- saga on top of react, but it wasn't hard.
I enjoy my code fairly explicit, so writing a button click that invokes some request has me writing:
- A click handler
- 3 new action name consts (request, success, failure)
- An action instantiation function that takes the necessary arguments for request.
- A saga function that catches these request actions, runs a request, and invokes the success action/failure action depending
- 3 handlers in my reducers. One for every action.
It all adds up if you have a ton of buttons :P
You might want to check out our new `redux-starter-kit` package [0], which can simplify some common use cases for things like action creators and reducers. There's also many other existing libraries to handle repetitive code like API requests as well [1].
[0] https://github.com/reduxjs/redux-starter-kit
[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma... , https://github.com/markerikson/redux-ecosystem-links/blob/ma...
That said, thanks for the recommendations! I’ll check them out.
Also related, the new Redux FAQ entry on choosing between async middlewares: https://redux.js.org/faq/actions#what-async-middleware-shoul...
It's possible to completely separate out your state machine and use it separately from rendering... It's also possible to integrate it all. Best practices are generally somewhere in between and having your state where needed... if it can be contained, contain it... if multiple controls need it, globalize/context it.
Pete Hunt always said he saw React components as mini MVC modules.
it's even less true nowadays with features like Context or suspense to supplement the component states. Redux was kind of a temporary hack.
Found it: https://web.archive.org/web/20140329114924/http://facebook.g...
> JUST THE UI
> Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.
So I was mistaken. It didn't say that's what it's only intended for, but that's what many people use it for.
Either way, it's not great at the M or C parts of MVC. Context does very little to ease that pain. Redux was more manageable but also overly complex, but it's only React's design that forced it to be so complex.
With React I can often bring in additional components and libraries without friction. With Angular it feels like doing anything means significant friction. And heaven help you if you want to change the way something internal works, or work around things.
Oh yeah... drag-drop integration... that was the single biggest pain. None of the component libraries worked well, and doing it manually was harder than I've experienced before, including just straight JS, and definitely worse as a whole than using say jQuery-UI.
If it were a year or more ago, I could cite better examples of pain points. 2+ is better than 1.x, but still horrible. I'd rather see people adopt Vue over Angular. I still prefer a react-alike over any of them.
Whenever I’ve needed drag and drop functionality in the past I’ve found it in existing UI components. A fairly comprehensive one is primeng. I’ve also added an angular colour picker and highcharts without very much trouble.
Often when I hear people complain about angular, I wonder if they just don’t understand it very well and are trying to do things the wrong way. Angular is opinionated, but I don’t find it terribly difficult or painful, though at this point I do have rather a lot of experience with it and find it’s difficult to put myself back in the shoes of someone with less.
I really do enjoy the framework and how comprehensive it is. I like having a framework that gives me so much out of the box without having to go to a somewhat unstable ecosystem of related projects. Frankly I think Angular’s bad name is due in part to it simply being fashionable to put Angular down, and partially because it’s critics never really learned how to use it.
Also, something about jsx just rubs me up the wrong way.
As to JSX, it's something close to what I wanted a long time ago... when E4X was added to Mozilla's browsers, along with support for it with Flash/ActionScript3 and XML literal support in VB.Net (not that I love that language) ... interactivity to the UI was SO much simpler. The shame is it was never really supported in other browsers, which left it dead on the vine.
When JSX came out, it's REALLY close to what I already wanted, and in most cases better. In the end, I can compose a React/JSX component starting with a static render function in a file by itself... I can grow it and turn it into a class or wrap it in higher order components. Compose with extensions like react-redux, material-ui, react-jss with ease. Every single time I write an Angular component, I'm looking up configuration arguments for @directives. It's just painfully restrictive by comparison.
Simplest react component
// HelloComponent.js
import React from 'react';
export default ({name}) => <div>Hello {name}!</div>
// StatefulComponent.js
import Hello from './HelloComponent.js';
...
return <Hello name={this.state.name} />
React is the view layer, so the class concept of "here's some data and methods to alter it" doesn't really match with what happens - I don't know that components every should have been classes in the first place.
"You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers." etc.
Also, bits of class issues show up in the other complaints.
So, no, it's not just "what is a class" and it's a weird hill to die on. I feel like most of these responses to hooks in general just focus on the most trivial detail aka bikeshedding.
Hooks, suspense, context wormholes - I'm not sure if these features should be part of a view engine. React, to me, did one thing and did it well, but now... I don't know.
https://www.youtube.com/watch?v=kz3nVya45uQ&t=39m (from elsewhere in the comments here)
LOL, did they just block a video presentation for some incidental random music in the background?
Sure, I know what it does and why it is needed, but it is ugly, cumbersome, and I keep forgetting it nonetheless.
- https://www.npmjs.com/package/babel-plugin-autobind-class-me...
- https://www.npmjs.com/package/babel-plugin-transform-class-p...
In the end it depends on your style. I think this might be useful in a way that can be more pure than some other methods might be.
At the same time, I've a passion for trying to make code more maintainable - which often means avoiding too much abstraction and keeping logic plain and up-front, where it can be found and followed, so I share some of your concerns.
But I'm excited about this. One of the best parts of React has been that the same logic that makes a good program makes for a good react app. Treat your components like functions (regardless of whether they are classes or not) - small, single purpose, decoupled from state - and you'll have an easier time. Hooks look to help that.
To be fair, that's pretty much what happens to all newish coders who are learning classes. Learning to use classes responsibly is really just part of the learning, though that seems to be the part that instructors pawn off to the next guy.
Once you learn how to use them judiciously, classes become extremely useful tools for encapsulation/abstraction where you need encapsulation/abstraction.
And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.
It's not a language thing. OOP discipline is a coding thing in general.
And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.
You sound like you don't actually understand why people like Typescript, or, more specifically, static typing.
Eh, in my experience, there are two types of Typescript users: 1) those users who appreciate the safety that type systems provide when used properly, and 2) those enterprise users of the language who have mostly only coded Java and C# and who like Typescript because it lets them write Java-style code for the browser.
On the other hand I'm not trying to hide that I'm bitter about the mental lazyness around typescript - I had some bad experience with interviewers who praised ts (without ever bothering to learn the core principles of javascript) a bit too much for my taste (but again, this may just be dismissed as anecdotal evidence, which it is).
How is static typing "mental laziness"?
``` private handleClick = (event) => {} ```
By "mental lazyness" I mean that people (as in people I have met with) piss on javascript and praise typescript and in the process they never bother to learn about javascript.
I do like vue, react, angular of course, but I don't think that you become a frontend developer from one day to the next and keep saying that typescript is _exactly_ like java (or dotnet).
I don't know if it's just something I don't see that often and aren't that familiar with, but I also can't stand the overuse of HoC's for this purpose. Seen some very clever and very, very unreadable HoC's so far and I hate working on codebases that use them liberally.
<InRoles roles={[...]}
allow={() => <Component ...props />}
deny={'/route' /* or a render, or skip */}
/>
In the end it depends on what you're trying to accomplish. HoC's are pretty useful. Also, it really helps in terms of unit testing your more functional components.
I completely agree.
When I started using React a couple of years ago, the only thing that made sense were the classes.
The bad aspect about React and JSX is that in general there are way too many JS acrobatics which alienates everyone from the codebase who isn't a JS ninja.
As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt.
> Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions.
I really don't like this, and to me this feels really finicky, and unfortunately the explanation doesn't make me feel warm and fuzzy ether. While it is great they are adding a linter plugin for it, i feel like this is going to be really easy to shoot yourself in the foot, and feels like it is relying on behind the scenes magic too much.