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

111–120 of 301 posts

Re: What I wish I knew about React

#111

Post by osdiab »

smt88 wrote: post #43
dvt wrote: 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…

> 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. I think everything in this sentence is incorrect. jQuery started out as syntactic sugar to smooth over the cumbersome and inconsistent DOM manipulation APIs in various browsers. No one ever seriously says React is a replacement for jQuery. It was a replacement spag…

Agreed with this - I think it all stems from the browser standards issue, which to me is a general issue about distributing control. It’s design by consensus, which naturally takes a long time, and forces updates to web standards to be conservative and backwards compatible in perpetuity to support every random stakeholder, which is a great recipe for a bloated and abused platform.

So at the core I chalk the situation up to people problems, not technical ones.

Re: What I wish I knew about React

#112

Post by 7777fps »

ddek wrote: post #108
7777fps wrote: post #68

Earlier quoted context omitted.

But that's great until it isn't. You can design all the declarative things you want, but someone will eventually come up with a requirement that doesn't appear to fit a declarative structure, such as an event that fires 2 seconds after something else happens. And so to resolve that you can construct state machines with transition states to get back to a declarative model, but those state machines can quickly become a…

I can call ‘setTimeout’ from the component? I honestly don’t see the issue with your example. I’d use an event handler to work out when something happened. This would set the timeout, and the handle would be stored as a ref. I’d have a use effect hook to clean up the timer, so when the component is unmounted the timeout is cleared. What’s the issue here?

It's no longer declarative as soon as you've done that though; it's still a break in the declarative paradigm.

Re: What I wish I knew about React

#113

Post by baddox »

osdiab wrote: post #30
dvt wrote: 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 personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my…

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 most complex app-style web sites are already going to need some global state management similar to Redux, where data fetched from the network is stored not in local React component state but in a global store, and when you have that (as well as a JS router, something else you’ll probably be needing anyway), the React SSR story really isn’t that crazy at all.

Re: What I wish I knew about React

#114

Post by osdiab »

capableweb wrote: post #53
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…

You seem to confuse "normal" with "required". dvt (correctly) states that "it's normal now to have like 3-4 compilation/transpilation" which is indeed true for most React codebases (open source and not) I've came across. In fact, I don't think I've come across a single React application that is seriously built without using JSX and without a bundler (like including react.js in the beginning of HTML). While not requir…

People who use React tend to want to use modern browser capabilities - and anyone who does will need transpilation because browsers have different API support - the cost of not having an all-controlling monopoly.

People developing on other platforms love to complain about the build tools on the web, but those same people only have the luxury of simpler build pipelines because they have greater control over the machines their code will be run on.

I don’t see React as having caused this problem in any way (feel free to include React via a script tag from a CDN and worry about the compatibility of your code yourself), and I also don’t see this as a problem that will go away any time soon for web development.

That all said, I do think it’s getting better - all the major browsers have switched to be auto-updating, so it’s feasible for many projects to drop support for IE altogether and only support ES6; if you manage your CSS in JS, you don’t need to downcompile languages like SCSS; the two of those together mitigates a lot of the need for sophisticated build tools.

Re: What I wish I knew about React

#115

Post by jsjw7sbw »

runawaybottle wrote: post #103
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…

A whole lot of people use it at work and witnessed valid criticisms. It’s not like we’re going to have the knives out when React/Angular is new. Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase. HN…

We rewrote our frontend in hooks and graphql 1 year ago. Hooks are fine, but graphql is a messy time sink for our usecase.

Re: What I wish I knew about React

#116

Post by baddox »

dvt wrote: post #44
osdiab wrote: post #30

Earlier quoted context omitted.

I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my…

> I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. Respectfully, that's not at all what HTML is supposed to be, but even so, as it turns out, sometime…

I don’t understand. Prop drilling or global state libraries like Redux don’t change the fact that the HTML of your site is a function of its inputs. Those are just two different ways to implement this concept of the HTML being a function of inputs.

Use your example of the icon that’s green if you’re authenticated. With React (regardless of whether you’re prop drilling or using something like Redux and context), you just update your state with isAuthenticated: true and the changes to green. There should only be one way to set that Boolean, and the icon will update regardless of where that Boolean is set. That’s all that’s meant by this concept of HTML being a function of inputs.

Re: What I wish I knew about React

#117

Post by conmigo »

prodave wrote: 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 hooks is that it's overruling the const type declaration:

  const [count, setCount] = useState(0);
You think count is a const? Not with hooks, because hooks are f!@#ng with your core language rules! And all those React + Hooks + Typescript fanatics that live in their type safe bubble fail to even notice it! Even Typescript doesn't complain about it.. Hooks make React a f'ing joke, they've given Dan way too much freedom at FB, IMAO.

Re: What I wish I knew about React

#118

Post by baddox »

ivan_gammel wrote: post #94
osdiab wrote: post #65

Earlier quoted context omitted.

What do you think HTML is for? If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not use React. If you’re using the web as an application delivery platform that works cross platform without installs and instant updates, then HTML is the base of your UI framework, and as such it helps to have predictability that frameworks like React offer. Re s…

Let’s put it straight: HTML is a Hypertext Markup Language by definition, it’s not an application UI markup language. We are living in a very confused world where inappropriate standard is used just because nothing better got sufficiently big market share. ES, TS, CSS, all the libraries and frameworks in the ecosystem are all just attempts to make the whale fly. For last 20 years we should have been focusing on build…

It would be a strange choice to not use the best tool for the job because one of the acronyms that’s related to that tool stands for something that for historical reasons doesn’t precisely describe the job.

Re: What I wish I knew about React

#119

Post by tannhaeuser »

osdiab wrote: post #65
dvt wrote: post #44

Earlier quoted context omitted.

> I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. Respectfully, that's not at all what HTML is supposed to be, but even so, as it turns out, sometime…

What do you think HTML is for? If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not use React. If you’re using the web as an application delivery platform that works cross platform without installs and instant updates, then HTML is the base of your UI framework, and as such it helps to have predictability that frameworks like React offer. Re s…

> using the web as an application delivery platform that works cross platform

Therein lies the problem, understandable as it is. If you're using React (or any other modern UI/MVw/whatever for that matter), you're still describing your app as mutating a grossly inappropriate scene graph of divs and spans held together with CSS tricks when your conceptual model is probably more adequately represented in terms of panels, fields, and canvases. On top of that, you pick about the weakest language out there, and over the course of decades, morph it into becoming more like a real programming language with runtime type info, accidental async patterns, decorators, compilation pipelines and whatnot, giving up the two benefits that JavaScript has, namely ubiquity and running OOTB on browsers by simple page reloading.

Re: What I wish I knew about React

#120

Post by baddox »

capableweb wrote: post #53
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…

You seem to confuse "normal" with "required". dvt (correctly) states that "it's normal now to have like 3-4 compilation/transpilation" which is indeed true for most React codebases (open source and not) I've came across. In fact, I don't think I've come across a single React application that is seriously built without using JSX and without a bundler (like including react.js in the beginning of HTML). While not requir…

Couldn’t that simply be because bundlers/compilers are really nice and that’s why people choose to use them despite the fact that they’re optional?
Post reply on HN