Live data from Hacker News

What I wish I knew about React

bitsofco.de

141–150 of 301 posts

Re: What I wish I knew about React

#141
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.)

Really? I would have put C++ and Java near the top of the “most ridiculed languages” list.

Re: What I wish I knew about React

#142

Earlier quoted context omitted.

Wow, posts like these provide real counterweight to my desire to write open source software.

I don't see anything wrong in negative critique when needed, it's a crucial part of journalism. And there is no need to drop your desire for writing open-source because of criticism on React hooks. Keep it real.

There is a difference between critique and attacking people.

Re: What I wish I knew about React

#143
post #131
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…

HN is a pretty hateful place in general.

I'm not sure if the stuff I see in HN threads qualify as hard feelings. They are more like jabs, prods, cheap shots, demands, begs and lots of bikeshedding with a smither of useful information here and there. I do appreciate the fact that they try to discourage the reddit style of rimshotting.

Re: What I wish I knew about React

#144
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…

Does this article qualify as 'hate' though? The author acknolwdges that he's new to react and is simply pointing out two things that he found challenging. Nothing surprising. Infact, I don't understand why the article is so highly upvoted.

I don't think the author is a "he".

Re: What I wish I knew about React

#145
post #8

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior. "Everything an HTML tag" is an insane mantra…

I understand this is an opinionated comment, but I thought I'd reply because IMO there's some conflation here regarding what "React" is.

> As author points out, what in the world does a tag even do?

This is not "React". This API was Apollo's decision, but just like you see libraries that lean heavily in the "everything is a component" direction, others don't. I personally use and like React quite a bit, but find this heavy use of HOCs in some 3rd party APIs a little weird.

> And everyone just bought into it because the guys at Facebook must be really smart.

Facebook builds and uses Relay which doesn't do this, which doesn't use HOCs like these ones Apollo does.

> The lifecycle hooks are just confusing and unnecessary.

It's fair to call them confusing if you feel that way, but I don't think you can say they're objectively unnecessary. They've all come pretty handy at some point or another in my use of React. Learning the lifecycle of a React component allows you to effectively integrate it with libraries that were never built with React in mind— I've used D3 + React extensively and and being able to do different D3 operations at different points in the component lifecycle makes it all work seamlessly.

> they change every few versions (so old code will inevitably break on new React versions).

Do they? React is pretty good about backwards-compatibility as far as I have seen. Wasn't the last breaking change with the release of 16, like 2-3 years ago? They also tend to make code-mods available to automatically migrate things, which can come in pretty handy.

> Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.

I do miss this too (although it hasn't gone away!), but this is not endemic to React. It is really is a traded-off to make when choosing to make a site rendered by JS (with all the advantages and disadvantages it brings) or the server (ditto).

Re: What I wish I knew about React

#146

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…

Hmm, did the React team themselves sell it as a library specifically as in "not a framework"? I do remember them specifically calling it responsible for "just" the view layer, but I also seem to recall someone on the React team (I might be wrong there) distinguishing the two as "a framework calls your code, whereas your code calls a library", where React is squarely the former. (Other than `React.render()`, I guess.)

Re: What I wish I knew about React

#147
post #2

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

Hooks are just a dirty hack, but sold very well. Internally in React the state of a hook is being kept and updated when you call the set function, kinda similar to vtables and context in OOP. There is no other way to do this AFAIK. It only mimics functional programming, and that's why you see the restrictions about hooks, you cannot use them outside React, cannot nest, etc.. What's maybe the most stupid thing about h…

Hooks don't change the meaning of const. The whole render function is re-run each time something is modified. There is ZERO internal mutation going on in render functions.

I suggest researching and learning how something actually works before calling someone else's work a "dirty hack" or "f'ing joke".

(And afaik hooks were Sebastian Markbage's idea... f'ing genius if you ask me)

Re: What I wish I knew about React

#148
post #63

The more I read about React, the happier I am to use VanilaJS alongside SSR and web components friendly frameworks.

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.

Re: What I wish I knew about React

#150

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.

That's perfectly possible in React; I've done that to great satisfaction in a number of projects :)
Post reply on HN