Live data from Hacker News

Ask HN: How can we make React better?

news.ycombinator.com

41–50 of 68 posts

Re: Ask HN: How can we make React better?

#41

I kinda enjoy working with React (because of JSX simplicity and composability). I think you could add easy support for some styling solution like it's done in Vue. I would focus on making React stable, fast and lightweight but improve on tooling and ecosystem around it. * I would like blessed way of extracting React components, so they can be reused between projects (like right click in IDE and share) - something lik…

I'd just like to voice a -1 for TypeScript (or Flow for that matter)

In my experience it doesn't help people, especially at an earlier stage, but rather clutters what people already know about JavaScript. It causes tooling to slow down and ultimately doesn't prevent bugs that could not already be caught by good design and linting.

I'm much more of a fan of something like PropTypes, which isn't just superficial, but actually runs on your code in all places and will stop you passing the wrong types to components, regardless of what environment you're in.

Otherwise everything else on this list is a +1

Re: Ask HN: How can we make React better?

#42
Decide what it wants to be and what its endgame is.

Currently it's a DOM management library that runs like a in-browser plugin, basically hijacking the browser, with tendencies to be a cross-platform native tool.

Realistically, it's a bloated view layer with a huge runtime (React + React DOM are ~100k minified).

While performance on iOS is good, the Android experience is horribly slow and full of bugs. What people like about it is the yoga layout engine primarily.

So basically you have a 100k runtime at minimum + a questionably maintainable, and definetly not a reusable native aspect of it.

Re: Ask HN: How can we make React better?

#45
post #22

Maybe this is either an uncommon use case or I'm missing an easy way to do it, but when you have a component tree like A->B->C (-> denoting child relation) and A contains most of the state and B contains many (say > 1k) children, and you keep updating state in A which only affects one or a few of C, the diffing process as I understand will check all of C whether they need to be rerendered. So if you update the state…

If you are in the Redux world I would maybe take a look at Reselect (https://github.com/reduxjs/reselect). As the other comment said, your problem should be solved by shouldComponentUpdate or more granular coupling of state to the component (or a combination).

Re: Ask HN: How can we make React better?

#46

I kinda enjoy working with React (because of JSX simplicity and composability). I think you could add easy support for some styling solution like it's done in Vue. I would focus on making React stable, fast and lightweight but improve on tooling and ecosystem around it. * I would like blessed way of extracting React components, so they can be reused between projects (like right click in IDE and share) - something lik…

+1 for typescript

Re: Ask HN: How can we make React better?

#48

I kinda enjoy working with React (because of JSX simplicity and composability). I think you could add easy support for some styling solution like it's done in Vue. I would focus on making React stable, fast and lightweight but improve on tooling and ecosystem around it. * I would like blessed way of extracting React components, so they can be reused between projects (like right click in IDE and share) - something lik…

I'd just like to voice a -1 for TypeScript (or Flow for that matter) In my experience it doesn't help people, especially at an earlier stage, but rather clutters what people already know about JavaScript. It causes tooling to slow down and ultimately doesn't prevent bugs that could not already be caught by good design and linting. I'm much more of a fan of something like PropTypes, which isn't just superficial, but a…

TypeScript has been very helpful in our react projects. There isn't much clutter, as usually the only types you define are props and state – things you want to know anyway.

TypeScript doesn't prevent any bugs that tests would not, but it does so faster and more concisely.

Tooling slowdown depends on your tooling setup; TypeScript can compile JSX on its own.

PropTypes are useful if you're transitioning from a plain JS codebase. But if you can start with and go full TS, I highly recommend going that route.

Re: Ask HN: How can we make React better?

#49
post #31

I wish non-css animations were easier! If you have any animation where you want to tween the state yourself (say changing position as a function of time), then that requires updating the state at 60fps or whatever requestAnimationFrame goes at. It feels philosophically wrong to do that under the declarative paradigm of react. React is supposed to be responsible for taking the state and "transitioning"(or diffing) the…

This is a library that I've used before to handle some complicated animation: https://github.com/joshwcomeau/react-flip-move

No longer actively maintained, though, so you might want to check out https://github.com/aholachek/react-flip-toolkit instead.

Re: Ask HN: How can we make React better?

#50
post #47

bring back 2-way binding. There are use cases, where it greatly improves productivity. Leave the choice about it to the developer.

I wonder if this could be solved with a general jsx decorators feature? For example:

    
...where bind is a normal function in scope that receives the element and/or its props?
Post reply on HN