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

251–260 of 301 posts

Re: What I wish I knew about React

#251

Post by partyboat1586 »

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…

The JS is run in a separate thread because the real-time operations are meant to be handled fully native. If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. You can't code it like a web app where you just replace one large node tree with another if you want it to be instant, you have to mount both and keep one invisible, either using a navigation library or custom code. This way layout changes are smaller packets so it doesn't saturate the low bandwidth of the thread bridge.

The extra latency for a layout change is most noticeable if it's an animation hence why you should use native animations not JS polling animations. I agree the Animations API is not as easy as CSS. If you want to do complicated stuff you need a lot of experience with it. This is one of the major hurdles for new RN devs.

Its possible to get good performance our of it, better than mobile web UI, you just need to have some experience with what costs and what doesn't.

Re: What I wish I knew about React

#252

Post by baddox »

dbbk wrote: post #209
baddox wrote: post #113

Earlier quoted context omitted.

The SSR data fetching story really isn’t much different than the story for managing global state in React on the client. It’s true than a client-side React application could just do AJAX requests on component mounts (or in a useEffect hook) to keep that data in local React component state, and that wouldn’t easily translate to React SSR (because the server renderer can’t know when your component tree is “ready”). But…

I don't really understand why suspending server rendering to load data is still an unsolved problem for React. Ember figured this out 4 years ago with FastBoot.

It’s not an unsolved problem. There are very many React apps with SSR, and popular frameworks that use React and provide straightforward SSR data fetching patterns.

Re: What I wish I knew about React

#253

Post by tarkin2 »

skrtskrt wrote: post #243
tarkin2 wrote: post #158

React isn't a library. You can't drop a bit of it into your project. It distorts how you build the webapp. jQueryUI is a library. You can add it in and your code is still vaguely the same. React is a framework pretending to be a library so people can't say "Oh, what? another framework?" As soon as you use React, you're in the react universe, not the normal webdev universe. With a normal webapp, I can just import an e…

You can just add the bootstrap CDN in the head of your index.html and use bootstrap without installing ‘react-bootstrap’ (I don’t disagree with anything else you said)

If you want to use the javascript components, rather than just the styles, you need the react library version. There are various other UI libraries as well that require you use the react conversion library, which sadly lag behind the vanilla js versions.

Fair enough if you love react then this is acceptable. But it pushes the definition of a library, when just using react means that other libraries need to conform to react to properly work with it.

React does some things nicely. But it's not "It's just a library. Drop it into your existing project. And you're done."

Re: What I wish I knew about React

#254

Post by II-V-I »

otachack wrote: post #211
II-V-I wrote: post #166

Earlier quoted context omitted.

Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes. I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm w…

Maybe bring it up to him with constructive criticism? Tell him the wind tends to change direction and one shouldn't typecast themselves in this field.

I agree. Though this person can be a bit touchy when constructive criticism is aimed at them, this would most likely be beneficial for them, and also the team, in the medium/long run.

Re: What I wish I knew about React

#255

Post by II-V-I »

dehrmann wrote: post #225
II-V-I wrote: post #166

Earlier quoted context omitted.

Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes. I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm w…

This is usually a smell that the person is competent at what they do, but doesn't know what's going on under the hood. Funny enough, I'd rather work with someone who doesn't know the specific technology, but knows what the language was built on top of, because they'll have a better intuition for how it actually works and be able to learn it relatively quickly.

I'd rather work with someone like that, too. All is well and good when one can crank out React components, but if that same person doesn't know how to find, for example, the tag name of a element from an event handler, a little red flag goes up for me, and as you said, probably doesn't know a great deal about what's going on under the hood.

Re: What I wish I knew about React

#256

Post by LinguaBrowse »

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…

> 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 leads to unavoidable glitches in native widgets used as controlled components.

Totally agreed. I’m working on an alternative to React Native that addresses exactly this: React NativeScript.

In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated to begin with.

https://github.com/shirakaba/react-nativescript

https://react-nativescript.netlify.com/

Re: What I wish I knew about React

#257

Post by LinguaBrowse »

partyboat1586 wrote: post #251
iainmerrick wrote: post #177

Earlier quoted context omitted.

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…

The JS is run in a separate thread because the real-time operations are meant to be handled fully native. If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong. You can't code it like a web app where you just replace one large node tree with another if you want it to be instant, y…

> If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong.

I’m working on an alternative to React Native that does exactly this, and it works absolutely fine: React NativeScript.

In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated.

https://github.com/shirakaba/react-nativescript

https://react-nativescript.netlify.com/

Re: What I wish I knew about React

#258

Post by II-V-I »

sngz wrote: post #242
II-V-I wrote: post #166

Earlier quoted context omitted.

Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes. I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm w…

> and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes. this has been my experience too, I'm a full stack engineer playing a devops role right now on a greenfield govt project. Getting our CI/CD pipeline going within our environment constraints with react has been a pain in the ass. Every time something goes wrong th…

Oof. Sorry to hear the FE dev gives up like that. You may become a JS expert if that carries on.

> the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully.

I'm curious to hear what alternative frameworks handled these things better? The only one I've used recently, other than React, is Vue.

Re: What I wish I knew about React

#259

Post by LinguaBrowse »

mikewhy wrote: post #236
ng12 wrote: post #214

Earlier quoted context omitted.

But what good are classes if you're not doing object-oriented programming? React classes are just stateful wrappers around a pure render function. It's not idiomatic and frankly dangerous to do anything you would with a regular ES6 class with a React.Component.

Can you clarify on that last point a bit? Not that I extend React.Component these days, but far as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended. I guess, yes, there's different semantics between the constructor and componentDidMount, but it's UI library, this is common that "when a constructor is call there is no guarantee the component has actually mount…

> as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended.

Facebook recommend composition over inheritance, but you can totally extend React.Component and even get abstract classes involved. In my custom React renderer, all the components in the library are based off React.Component class inheritance.

https://github.com/shirakaba/react-nativescript

Re: What I wish I knew about React

#260

Post by sngz »

II-V-I wrote: post #258
sngz wrote: post #242

Earlier quoted context omitted.

> and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes. this has been my experience too, I'm a full stack engineer playing a devops role right now on a greenfield govt project. Getting our CI/CD pipeline going within our environment constraints with react has been a pain in the ass. Every time something goes wrong th…

Oof. Sorry to hear the FE dev gives up like that. You may become a JS expert if that carries on. > the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully. I'm curious to hear what alternative frameworks handled these things better? The only one I've used recently, other than React, is Vue.

So the issue I'm referring to is this, which has been open since 2017 https://github.com/facebook/create-react-app/issues/2353

There's a slew of workarounds offered in that github issue, most people (including another team in my org) opted to just rebuild the app every time a docker container is created which kind of defeats one of the major pros of using docker IMO.

I ultimately ended up forking off this repository and customizing it to my needs https://github.com/beam-australia/react-env

that solution in itself is very hacky.

as far as I know, vue doesn't have this feature either but I think next.js and nuxt.js does.

Post reply on HN