Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hooks: React’s Do-Notation

devanshj.me

Post reply on HN
Print view View original

21–30 of 80 posts

Re: Hooks: React’s Do-Notation

#21

Post by ovao »

blindseer wrote: post #3

I'm not well versed in React so only clicked into this article out of mild curiosity. If anyone is interested in discussing the non-technical aspects of this submission, please continue reading this comment :) What do people think of the foray of these blog posts with embedded javascript components? It appears that this a nice way to provide interactive explanation on subjects. I think this post does a nice job. That…

I had some issues with re-scrolling here on Safari, but not too bad. Probably a minor fix.

Re: Hooks: React’s Do-Notation

#22

Post by westoncb »

makotech221 wrote: post #19
westoncb wrote: post #17

Earlier quoted context omitted.

> do you really need all this to make a UI This only makes sense for a very narrow conception of the range of UI problems. If your UI is just a basic form or trivially reflecting database structure in a CRUD app, then you would have little to no need for React. If you were to try building e.g. the full Gmail UI and make the attempt with e.g. document.querySelector (or jquery) and again with React you would have a pai…

Unfortunately for your argument, Gmail was far superior before the big 'app' rewrite.

If my argument were that the new version of Gmail was better than the old one, and if the old version being "far superior" had some objective grounding—then you might be on to something.

But that wasn't my argument at all. Gmail isn't even written with React. And if it were it would still be irrelevant: I'm not arguing "writing a program in React means it will be a good and well-designed program"; I'm saying if you write the same complex program twice, once with built-in browser APIs and once with React, you will on average find that the React implementation is far quicker to write, more concise, fewer bugs, and so on.

Re: Hooks: React’s Do-Notation

#23

Post by eyelidlessness »

akdor1154 wrote: post #20

My first boss had an often repeated mantra in code reviews: "akdor, don't fight the damn language!" If you're using Python, write with Python concepts. In C#, write C#. In F#, write F#. Etc etc. React has many many great ideas. But they are perpetually fighting the language. Here we have a great demonstration of stuff that is built in to any ml-legacy language being hacked into js in a way that the transformation hap…

Which is all good and well, but the language is fighting the language. If you don’t believe me, just look at active tc39 proposals. JavaScript is increasingly becoming a compilation target and writing it idiomatically is increasingly a mishmash of preferences.

Re: Hooks: React’s Do-Notation

#24

Post by eyelidlessness »

bigyikes wrote: post #2

The author discusses the sequential leaps towards functional programming: from mixins, to HOCs, to render props, and finally to hooks. I’m very comfortable with hooks, but I’m not much of a functional programmer beyond that. So my question is: what is the next step in this progression? What is after hooks?

I would highly recommend learning Clojure. Hooks will feel familiar to reference types and the rest is a really good introduction to FP without being absolutist about it.

Re: Hooks: React’s Do-Notation

#25

Post by mdoms »

westoncb wrote: post #22
makotech221 wrote: post #19

Earlier quoted context omitted.

Unfortunately for your argument, Gmail was far superior before the big 'app' rewrite.

If my argument were that the new version of Gmail was better than the old one, and if the old version being "far superior" had some objective grounding—then you might be on to something. But that wasn't my argument at all. Gmail isn't even written with React. And if it were it would still be irrelevant: I'm not arguing "writing a program in React means it will be a good and well-designed program"; I'm saying if you w…

> if you write the same complex program twice, once with built-in browser APIs and once with React

That's a false dichotomy.

Re: Hooks: React’s Do-Notation

#26

Post by jaredcwhite »

React has hooks because React's "classes" were pretty crappy…partially due to crappy OOP in general in previous eras of ECMAScript. But instead of actually making their syntactical sugar better as JS' native OOP paradigm improved, they went the opposite direction. After having to use them in a large React codebase for years now, I still can't stand them.

For a look at a UI library that actually rocks precisely because it embraces OOP and the native object graph of the DOM, check out Lit. It takes everything that's awesome about browser-native web components, then simply adds some fabulous DX on top for reactive re-rendering upon prop updates. I've never used a UI library in my life that's meshed with my brain better than Lit. I'll take a good Lit-based web component class any day over React.

Re: Hooks: React’s Do-Notation

#27

Post by ovao »

mdoms wrote: post #9

Sometimes I look at what's going on in React land and just want to ask these developers, do you really need all this to make a UI? Really? Are you sure? Are you making things better?

There isn’t actually a whole lot of “this” in this —- from an API surface viewpoint, most UI frameworks (React included) are fairly minimal sets of abstractions. The benefit is more along the software development axis of homogenization than anything else.

Re: Hooks: React’s Do-Notation

#28

Post by westoncb »

mdoms wrote: post #25
westoncb wrote: post #22

Earlier quoted context omitted.

If my argument were that the new version of Gmail was better than the old one, and if the old version being "far superior" had some objective grounding—then you might be on to something. But that wasn't my argument at all. Gmail isn't even written with React. And if it were it would still be irrelevant: I'm not arguing "writing a program in React means it will be a good and well-designed program"; I'm saying if you w…

> if you write the same complex program twice, once with built-in browser APIs and once with React That's a false dichotomy.

I suppose one might arise if I were claiming those were the only two options. But on a closer re-reading you'll easily find that's not the case.

Re: Hooks: React’s Do-Notation

#29

Post by dwaltrip »

ovao wrote: post #21
blindseer wrote: post #3

I'm not well versed in React so only clicked into this article out of mild curiosity. If anyone is interested in discussing the non-technical aspects of this submission, please continue reading this comment :) What do people think of the foray of these blog posts with embedded javascript components? It appears that this a nice way to provide interactive explanation on subjects. I think this post does a nice job. That…

I had some issues with re-scrolling here on Safari, but not too bad. Probably a minor fix.

The latter half of the article had some quite bad scrolling problems for me on mobile safari.

Re: Hooks: React’s Do-Notation

#30

Post by paldepind2 »

eru wrote: post #10

> Well actually this is not an aphormism, it's not even a propositional statement, because “X is a monad” is just math-speak for “X is composable”, just like “Y is a functor” is math-speak for “Y is mappable”. Nah. Monads are one relatively special way to compose stuff. And monads don't even compose very well. To give example: the weaker applicative functors (to use Haskell's terminology) compose much better. https:/…

I agree. If anything in math can be said to mean “X is composable” I would say that that statement is “X is the arrows of a category”.
Post reply on HN