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

291–300 of 301 posts

Re: What I wish I knew about React

#291

Post by FeloniousHam »

_0w8t wrote: post #217
tenaciousDaniel wrote: post #184

Earlier quoted context omitted.

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?

You may also consider Flow. It is literally JavaScript plus type annotations. The annotations can be even put into comments turning the files into vanilla JS making this very clear. So there is no danger that if FB abandons it one ends up with code that needs to be converted. On the other hand Flow is much less cool than TypeScript these days. Plus using it for development under Windows have issues, although FB has s…

We started out with Flow, but moved to Typescript not because it's "cool" (I suspect it's the Flow users who are smoking clove cigarettes in black berets), but because the language improvements and tooling support are a huge productivity boost. The killer is how flexible it is, it incrementally scales from straight JS to full-on type religion. You only have to use as much as you find useful.

Re: What I wish I knew about React

#292

Post by dbbk »

baddox wrote: post #252
dbbk wrote: post #209

Earlier quoted context omitted.

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.

They don't suspend the render though. The main options, like with Apollo/Relay essentially have to do a double-render.

Re: What I wish I knew about React

#293

Post by peter_d_sherman »

Excerpt:

"The way I like to think of it in comparison to Angular is this: Angular is a framework for architecting and building applications. It, for the most part, doesn’t change the way you write your HTML or CSS, but it heavily controls the way you write Javascript.

React, on the other hand, is a library for building user interfaces. It, for the most part, doesn’t change the way you write Javascript that isn’t directly related to your UI, but it heavily controls the way you write HTML and CSS (or the equivalent of it). And this brings me to the next point…"

Re: What I wish I knew about React

#294

Post by sngz »

azangru wrote: post #283
sngz wrote: post #280

Earlier quoted context omitted.

> but I would say environment variables are not React's concern; it’s up to you how to architect your code I don't consider it part of the "code" but part of configuring the application based on the environment you're deploying it on(Precisely why the FE dev basically said its not his problem). The fact that a lot of people are suggesting you just build the app every time you deploy a docker container is really conce…

Dotenv runs on the server. If a part of your application also runs on the server (such as with Next, Nuxt, etc.), and your responses are generated dynamically, then it is trivial to use the dotenv. If, however, the runtime of your application is confined entirely to the browser, and what you are serving to the browser is only static assets, such as with create-react-app, then, if you still want your environment varia…

yep i know how it works after looking into it since I didn't know anything about react before, just makes me not want to use react or vue for any enterprise level software.

All those solutions you mentioned I've considered and are mentioned in the github issue. I just think its way too much work and overly complicated for what is basically a prototype. Which is why I opted for the simple hacky solution.

> This really is not something that is React’s responsibility

This is why I'm already pushing for our team to move off react I don't think its the right fit for us. We also don't like JSX

Re: What I wish I knew about React

#295

Post by iainmerrick »

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.

If I'm coding in a style that works fine on web, and also works fine in native code, but is slow in React Native, then I'd suggest I'm not the one doing it wrong, it's React Native itself.

This way layout changes are smaller packets so it doesn't saturate the low bandwidth of the thread bridge.

Even if they were to stick with the multithreaded architecture, it should be possible to build a layout structure in the background thread and just hand ownership over to the UI thread. I believe the RN team are working on doing this with their new Hermes runtime (sharing objects directly rather than marshalling them into and out of the JS engine), so that ought to help a bit. But I really think the threading model is just wrong-headed in the first place.

Its possible to get good performance our of it, better than mobile web UI

Is there a case study or even just an example that demonstrates that? I'm skeptical. Mobile browsers are very fast these days, so there's no obvious reason why RN should necessarily be faster.

I suppose RN might have an edge if you're making extensive use of native code. But then calling native code from RN is very laborious, so RN doesn't exactly pull its own weight in that scenario.

Re: What I wish I knew about React

#296

Post by Lammy »

doublerabbit wrote: post #290
aylmao wrote: post #148

Earlier quoted context omitted.

You should try to use it too! If you discover you don't like anything about it, all the better, you can say you've experienced it and not just read about it. If you happen to like at least parts of it, you've just expanded your knowledge and arsenal of tools for UI development.

I just can't get myself around to use anything by FANG just due to their licenses. Using a framework means your project will never purely be yours. React license: > The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against…

Am I missing something, or did they drop that in 2017?

https://engineering.fb.com/web/relicensing-react-jest-flow-a...

https://github.com/facebook/react/commit/b765fb25ebc6e53bb8d...

Re: What I wish I knew about React

#297

Post by iluvblender »

Can_Not wrote: post #278
iluvblender wrote: post #75

Earlier quoted context omitted.

I just started studying svelte today (alongside Vue). I look forward to sharing my thoughts soon.

Things I wish I knew about Svelte: error handling is fragile and/or non-existent.

I will keep that in mind, Thank you :)

Re: What I wish I knew about React

#298

Post by kuschku »

acemarke wrote: post #267
kuschku wrote: post #262

Earlier quoted context omitted.

Actually, you can pass instances of it around just fine, if you know how it works. It’s not any different than a view subclass on Android, or a widget in Qt.

Instantiating it does nothing useful, though. `React.Component` is basically an empty shell with a marker flag on it so that the React renderer recognizes it, and the `setState` method just delegates to the actual renderer implementation. There's no reason to ever instantiate it yourself.

But that's the point. All UI frameworks are like that.

You can't `new MyRecyclerView(...)`, you've got to `LayoutInflater.inflate(MyRecyclerView, parent)`, which isn't any different from `React.render(MyApp, parent)`.

Re: What I wish I knew about React

#299

Post by temporallobe »

hombre_fatal wrote: post #221
temporallobe wrote: post #212

I tried React and hated it, especially JSX, but I made some decent money working on React projects in the past. I much prefer libraries/frameworks where the view is completely separate and is more “pure” HTML. I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish. Maybe one day I’ll clean it up and push it to a Github repo, but then again, d…

> I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish. You lost me there. Cute for a solo/learning project, but when other people are touching the project or you're trying to build a business, you have to answer for why your project was so special that it needed its own ad hoc framework. As opposed to, say, a framework with real documentat…

Gatekeeping much?

Re: What I wish I knew about React

#300

Post by partyboat1586 »

iainmerrick wrote: post #295
partyboat1586 wrote: post #251

Earlier quoted context omitted.

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. If I'm coding in a style that works fine on web, and also works fine in native code, but is slow in React Native, then I'd suggest I'm not the one doing it wrong, it's React Native itself. This way layout changes are smaller p…

There are no benchmarks I know of, it's accepted wisdom that React Native is faster than mobile web even when not optimised and comes close to native when optimised. That has always seemed self evident to me but maybe it's time someone did some benchmarks.

I think the reason RN is faster is because mobile browsers have to support decades of crufty CSS in their layout engines while native layout engines are much more lean and ripe for optimisation. React Native uses Yoga layout engine so there may actually be benchmarks available on that.

Post reply on HN