What I wish I knew about React • Hacker News Board

Re: What I wish I knew about React

#181

Post by neutronicus » Wed, Apr 29, 2020, 1:24 PM UTC

saagarjha wrote: post #133

jchw wrote: post #87

Earlier quoted context omitted.

It’s the price of success. Similarly, a lot of people now vehemently hate Go, and in a few years they’ll be complaining about the problems with Rust. (No idea about frontend because as far as I’m concerned React is still on top.) I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean w…

I don’t think it’s necessarily success, but novelty. C++ and Java are immensely popular and get nowhere near the vitriol that the thing you mentioned do. Often there’s a number of people on the opposite side cheerleading the thing as well, which underlines the apparent conflict. (Rust is already being complained about, by the way.)

As a C++ developer who occasionally helps a friend hack on a Rust hobby project, I've been waiting for the other shoe to drop on Rust.

Not necessarily because I have many complaints about it, but because I consider it in essence very similar to C++17, with (not-too-)different syntax and a few different but important design decisions in the core language and standard library. Seeing it sold as a radical paradigm shift from C++ has always left me feeling that some people are in for disappointment down the line.

Re: What I wish I knew about React

#182

Post by m5r » Wed, Apr 29, 2020, 1:28 PM UTC

kreetx wrote: post #102

ggregoire wrote: post #95

Earlier quoted context omitted.

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

What's a good place for front-end dev discussions, especially the type which are more on the meta-level?

Twitter can be a good place sometimes

/r/webdev, /r/javascript and /r/reactjs too

Re: What I wish I knew about React

#183

Post by programmarchy » Wed, Apr 29, 2020, 1:33 PM UTC

Off topic, but the yellow border on the page kept drawing my eyes away from the text to the edge of the screen.

Re: What I wish I knew about React

#184

Post by tenaciousDaniel » Wed, Apr 29, 2020, 1:35 PM UTC

ggregoire wrote: post #95

dvcrn wrote: post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

I've been considering the jump into TS, but I don't want to end up in a coffeescript situation (i.e. language is dead, but code lingers on and has to be converted back to JS at some point, rather painfully). Do you think it's worth it?

Re: What I wish I knew about React

#185

Post by nicoburns » Wed, Apr 29, 2020, 1:41 PM UTC

genezeta wrote: post #12

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework…

I think the sense which the original article talks about is an important one: You can generally use vanilla libraries for non-UI stuff. You don't generally need to use anything React specific.

This is in contrast to frameworks like Angular which try to reinvent to entire ecosystem in an "Angular style". Which is a massive pain if the Angular version has a bug, doesn't implement the feature you need, or is simply far too complicated because it's trying to be everything to everyone. In React, there are usually 2 or 3 options for everything with different trade-offs. And this is amazing, because you can pick the library that works for your project.

Re: What I wish I knew about React

#186

Post by karatestomp » Wed, Apr 29, 2020, 1:55 PM UTC

iainmerrick wrote: post #177

partyboat1586 wrote: post #163

Earlier quoted context omitted.

React native code re-use is possible just not in the way people imagined. You can reuse your Redux code, you can reuse higher order components you just can't reuse the atomic UI elements. React native performance is good too it just doesn't come for free. You need to know how to do native animations and you need to do late binding and all the other performance optimisations you should be doing with React anyway. The…

Is React Native performance really good? Compared to what? I've found RN performance passable but underwhelming. It seems generally worse than a good native UI, and no better than a mobile web UI. I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and le…

> Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.)

My experience was that RN was way more helpful on Android than on iOS, in general. But that has more to do with Android than RN, which achieves its utility on that platform by papering over a pile of bad decisions, inexplicable awkwardness, and half-finished-apparently-by-the-Summer-interns APIs, none of which should be problems in the first place. I'd seriously consider using it for just for Android even if I wrote a separate, native iOS version of the same app.

Re: What I wish I knew about React

#187

Post by nsonha » Wed, Apr 29, 2020, 2:03 PM UTC

capableweb wrote: post #58

genezeta wrote: post #12

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework…

I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as bo…

Nah im sure if you look close into, say angular's docs, you'll eventually find out how to bootstrap their app container manually. It's usually the fact that a framework comes with some conventions that you "must" (not should) follow in order for things to work. Like having an IoC container in angular, you can't opt out that.

Re: What I wish I knew about React

#188

Post by WiseWeasel » Wed, Apr 29, 2020, 2:07 PM UTC

jsjw7sbw wrote: post #115

runawaybottle wrote: post #103

Earlier quoted context omitted.

A whole lot of people use it at work and witnessed valid criticisms. It’s not like we’re going to have the knives out when React/Angular is new. Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase. HN…

We rewrote our frontend in hooks and graphql 1 year ago. Hooks are fine, but graphql is a messy time sink for our usecase.

Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge to rewrite a complex REST react app to GQL, since you'd be discarding a ton of data shuffling code, but we've been happy with the resulting simplification of our frontends.

Re: What I wish I knew about React

#189

Post by ncallaway » Wed, Apr 29, 2020, 2:11 PM UTC

andrewstuart wrote: post #104

I love React. In fact I recently gave plain vanilla JavaScript a go and it was so painful that I was glad to get back to React's way of organising a large application. I don't use Redux or server side rendering - they're not needed. The only thing that I think it should do differently is leave styles to be handled natively.

You absolutely can, and I almost always do, styles things with native css (well, I use sass compiled to css) to style your react application (or widget!).

To my knowledge, React itself has no opinion on styling. It's more the ecosystem around React that's gone css-in-js.

But, yes, if you want to do your styling natively that's really not a problem.

Re: What I wish I knew about React

#190

Post by nsonha » Wed, Apr 29, 2020, 2:17 PM UTC

dvcrn wrote: post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

> so you can scrap that entire connect() stuff alltogether

To me that "entire stuff" is about the only thing that is good about redux (barely does dependency injection). See people need to understand that hook is a good API from the library authoring point of view (the react team's and react component library authors') it's not such a clean abstraction for people to write application on top of while unneccesarily make their code depend on magic react functions all over the place.

I cant count how many "data fetching hook solutions" I've seen on twitter. If something does data fetching, then it needs to know about fetch() and may be a reactivity abstraction like promise or rx. A hook is completely unjustified.