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

231–240 of 301 posts

Re: What I wish I knew about React

#231

Post by hombre_fatal »

jarym wrote: post #199
koonsolo wrote: post #174

Earlier quoted context omitted.

React introduced a whole new way of writing GUI's. I come from a game development background, and there we had Immediate GUI's for some time now ( https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutor... ). React basically translates this concept to the web, and does some optimizations to not rebuild the entire DOM from scratch, and only rebuild when state changes and not every frame. Writing a 'render functio…

React introduced this concept ‘to you’ perhaps but it wasn’t the first. The framework I used has been doing this in the very early 2000s. Don’t get me wrong it has a lot to like about it - but the only revolution is that Facebook’s might propelled this in the minds of developers all over.

Just curious, which framework are you referring to?

Every time I see someone claim such a thing, it's usually only distantly related. Like it too has a render() function.

I mean, you can find old FRP phd/whitepapers but I don't think they prohibit you from ever saying "$X introduced $concept" without a disclaimer that it wasn't the first. So if you're going to insist, then why not share some prior art for the discussion?

Re: What I wish I knew about React

#232

Post by derryrover »

sametmax wrote: post #151
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've been coding and training people in react for a while now, and here is my experience: - if you learned react by yourself years ago, you had to go through a lot of pain: the doc was terrible, the ecosystem a moving flaky target and conventions were not established. Things are better today, but it's not something you forget. Somebody starting react in 2018, and with create-react-app, will feel much happier. - if yo…

Best summary of the state of react I have read so far after programming with it for 2 years. You should write an article about it!

Stuff like this is rarely part of the sales pitch for any framework. You only find out after being locked in neck deep. Still from all the browser gui frameworks I think react is the safest choice.

Why? Well it is reliable and scalable enough and create-react-app makes the whole experience acceptable. It will not get you into trouble. Choosing any of its non-mainstream competitors might get you into deep shit if the project fails. Choosing any of its mainstream competitors like Vue or Angular seems like not a big improvement over react (if it even is) and will make you go into defensive mode anytime a junior dev knows that feature x would have been easier to implement in react.

Re: What I wish I knew about React

#233

Post by Zarel »

_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…

TypeScript annotations can also be put into comments. I like TypeScript's approach (JSDoc) better, actually, because it's how you'd want to annotate them even if you didn't have a typechecker, anyway.

Although I still hit enough annoyances that I'd go straight to `.ts` files for my next project.

Re: What I wish I knew about React

#234

Post by Zarel »

zdragnar wrote: post #228
akie wrote: post #219

Earlier quoted context omitted.

What if most of TypeScript is embedded into the next version of JavaScript, as happened with Coffeescript?

Typescript offers almost no runtime behavior. With a few exceptions, everything is stripped out, and it only offers to transpile modern JS features to older browsers. CoffeeScript was all about an alternate syntax for runtime behavior. JS isn't going to get compile time anything. There was an attempt at adding "strong mode" by one of the google / chrome teams iirc and that went nowhere.

All I really wanted was to allow type annotations in JavaScript. So you wouldn't need a compile step while running (JavaScript would just ignore the type signatures), but TypeScript could check it whenever. I believe this is the approach Python uses.

I think there were discussions of doing that at some point, but it seems to have gone nowhere.

Re: What I wish I knew about React

#235

Post by mikewhy »

gregkerzhner wrote: post #206
WiseWeasel wrote: post #188

Earlier quoted context omitted.

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…

I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest. For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manuall…

> For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it.

Apollo is for GraphQL. I'm not sure why you'd try to use it's internal caching system to add local application stuff. Note that using Apollo does not stop you from continuing to use Redux.

> The Query component can be fine for simple use cases, but it still ties your API calls directly to your component.

This is what hooks aim to solve.

Re: What I wish I knew about React

#236

Post by mikewhy »

ng12 wrote: post #214
iainmerrick wrote: post #178

Earlier quoted context omitted.

I disagree. I think that's like saying C++ doesn't actually have classes, it's just syntactic sugar around structs of function pointers. It may be technically correct , but C++ and now JS have a "class" keyword for a reason, and that's to steer you towards organising your code into classes which operate in certain ways. In both languages you can avoid using classes, sure, or abuse classes in various ways. But fundame…

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 mounted".

Re: What I wish I knew about React

#237

Post by cambalache »

gitgud wrote: post #193
Kiro wrote: post #131

Earlier quoted context omitted.

HN is a pretty hateful place in general.

If you're coming from Reddit, Imgur or YouTube it seems like hate, but I've found it's simply a lack of humor... Any jokes, memes or puns are frowned upon the community 99% of the time. I suppose it's considered redundant or not-constructive...

That is true, but it not just the lack the humor, it is the pretentiousness and the faux-politeness.

Re: What I wish I knew about React

#238

Post by [deleted] »

dbbk wrote: post #205
have_faith wrote: post #172

Earlier quoted context omitted.

I think the number of concepts that need to be understood to be an efficient React developer has grown over the years just enough that it has become slightly frustrating to learn. It is still presented as a very simple small surface area framework but there's a lot of subtly with how many new concepts need to be understood now like hooks as an example. I think it just crossed a threshold and became less intuitive and…

The useEffect example in this article to me is ludicrous. It makes absolutely no sense just looking at it.

[deleted]

Re: What I wish I knew about React

#239

Post by wtmt »

fit2rule wrote: post #136
kreetx wrote: post #102

Earlier quoted context omitted.

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

http://lobste.rs is a good starting point. Not as much hate there..

Related question: Does it still require hanging around and waiting for an invite to create an account? If yes, then I’m not going to try again and waste my time.

Re: What I wish I knew about React

#240

Post by Zarel »

test1235 wrote: post #140
sunaurus wrote: post #33

Earlier quoted context omitted.

> "Everything an HTML tag" is an insane mantra to have. I don't think this is a React mantra at all. Maybe "everything is a function" would be a modern React mantra? Seeing how React code is mostly hooks and components, and both are nowadays generally written as functions. JSX is not even required when writing React, by the way. It's just syntactic sugar. > It's crazy to me that it's normal now to have like 3-4 compi…

>JSX is not required to use React Everyone keeps repeating this, but looking at a pile of 'createElement' calls is so much harder to read than just looking at a page of html.

There are a lot of libraries to it more readable:

https://blog.bloomca.me/2019/02/23/alternatives-to-jsx.html

If you don't want to use any of them, convention is to use:

    const h = React.createElement;
I don't know of anyone who actually uses `React.createElement` directly.

Personally, with all the other things needing a transpile step (TypeScript, and support for older browsers), I've just gotten used to having one in every project nowadays.

Post reply on HN