Live data from Hacker News

What I wish I knew about React

bitsofco.de

71–80 of 301 posts

Re: What I wish I knew about React

#71
post #19
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.

Classes in React are confusing because they aren't actually classes, just something shoehorned into classes. For example you wouldn't write your initialization code in the constructor, you would do it in componentDidMount. Classes in React generate false expectations.

Yeah but how is that different from any other UI framework?

onCreate/onStart/onResume and onComponentDidMount, onPause/onStop/onDestroy and onComponentWillUnmount are basically the same. Be it Android, Swing, or Qt, everywhere it's the same pattern.

React is the first framework which actually feels like UI development on the web, not anymore like JS spaghetti.

In fact, having internal state, externally given props, exposing events, and being declared through markup is exactly the same between React, Android or Qt.

The only thing React brought to the table was allowing you to basically just recreate the children every time something changed, and it'd diff automatically.

For us native devs this thread is hilarious, because it's just JS decs complaining over things we've always done

Re: What I wish I knew about React

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

What is wrong with Swing?

Coz I use it every day, and despite many little deficiencies, it still compares well to other cross-platform toolkits.

Re: What I wish I knew about React

#73

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…

Yes. That's the other way of expressing the distinction between frameworks and libraries.

And I think most people do use React as a framework. (But I could be underestimating those who use it in the second way, of course).

Re: What I wish I knew about React

#74
post #63

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

I can agree. I'd take a bit of SSR and JS + jQuery any day over big and heavy JS frameworks.

Even if I'd write the backend as an API without no SSR, I would prefer to write the frontend in HTML + CSS + vanilla JS + jQuery. It feels more intuitive to me as there are no abstractions to complicate things, no opinionated framework to force me do things its predefined way.

Re: What I wish I knew about React

#75
post #35

Earlier quoted context omitted.

I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?

Maybe something like svelte?

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

Re: What I wish I knew about React

#76
post #56

Earlier quoted context omitted.

Ending up with HoC on top of HoC is also an extremely salient point. While it's not strictly required, the structure of larger React projects highly encourages you to create or use non-visual higher order components to manage connections to state stores, APIs etc - or make use of the Context API to achieve the same result. In both cases, you end up with non-UI wrapper components to provide the plumbing in a tree of c…

Higher order components haven't really been a thing since hooks were introduced though.

True, but it's important to remember hooks were only released about a year ago - many large projects in existence before then will either not have migrated or be in a state of partial migration.

I'm glad they're putting the effort into making the API simpler and easier to use to address some of those concerns, but React itself has been around for seven years now - the vast majority of existing developments will have been started using versions of React created before hooks were introduced.

Re: What I wish I knew about React

#77
post #17
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…

> It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app. This is why I stick with Vue. One tag later you're good to go, and all of the extra stuff (like .vue files) isn't necessary to use the framework. It's a godsend. I can't imagine how many hours I've lost to obscure webpack errors before switching.

Done that. My manager finds it so good when he can hot-fix issue.

Just that some third party plugins are written in es6, it would be cumbersome if you need to support ie11 in a enterprise setting.

Also if you have quite a lot of vue components to load, it would take longer time than compile first with webpack in http1.

Re: What I wish I knew about React

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

It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.

You don't need a bundler. All the major browsers will run ES6 modules these days (https://caniuse.com/#feat=es6-module and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...). We use bundlers because we still target older browsers and a lot of library code isn't in a format that works in browsers yet (and probably never will be in a lot of cases).

Re: What I wish I knew about React

#80
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 am suspect of any argument that says React is better or worse than jQuery. The sign will depend on what problem you are trying to solve.

React and optionally react-redux is more complex in itself, but it is really trying to tame app complexity you'd get with lots a jQuery sprinkled around. With react, you can reason about the state of the app, and know the current view is calculated by a (hopefully!) pure function f that maps state to the view.

Don't really see the issue with HOCs. I am not seeing why they are a terrible idea. I think they are quite elegant actually.

SSR I might have to agree with you. I haven't yet understood why it is needed honestly. Is it SEO or something? Or is it speed of deep linking into a 'page' of your SPA.

As for the compilation steps - meh. This sort of stuff is done a lot on the back end in larger projects too - pre compilation steps and wat not. It's not a big deal with a bit of webpack watching.

Post reply on HN