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

71–80 of 80 posts

Re: Hooks: React’s Do-Notation

#71

Post by dbbk »

thaumasiotes wrote: post #31
eyelidlessness wrote: post #23

Earlier quoted context omitted.

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.

> JavaScript is increasingly becoming a compilation target JavaScript is the browser's machine code; having it as a compilation target makes at least as much sense as having an Intel chip as a compilation target.

Wouldn't it make more sense to have WebAssembly as a compilation target?

Re: Hooks: React’s Do-Notation

#72

Post by dbbk »

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?

As someone working on a project management app, complete with gantt chart functionality... yes.

Re: Hooks: React’s Do-Notation

#73

Post by stephen »

Really interesting to see the various examples/incarnations the author went through to illustrate his point. Very well done.

I must admit I like his aphorism: "If you're honest while making your code better, you will inevitably end up making it functional".

Although I would tongue-in-cheek add a suffix of "...you will inevitably end up making it functional, but stop once you start making everything a monad". :-D

I feel like FP purists hold "...and now it's a monad!" as an forgone conclusion / must be achieved end state. ...which, I did enough Scala for comprehensions (and now JS promises) that I believe I basically "get" monads, but so far I've not seen the light about the differences between "good enough" lazy abstractions (JS promises) and "Shalt Follow All Of the Rules" real monad abstractions, other than the latter end up letting you (sorry, tongue-in-cheek) write even more obtuse Haskell?...

Re: Hooks: React’s Do-Notation

#74

Post by dorfsmay »

dbbk wrote: post #71
thaumasiotes wrote: post #31

Earlier quoted context omitted.

> JavaScript is increasingly becoming a compilation target JavaScript is the browser's machine code; having it as a compilation target makes at least as much sense as having an Intel chip as a compilation target.

Wouldn't it make more sense to have WebAssembly as a compilation target?

Once it has access to the DOM, sure

Re: Hooks: React’s Do-Notation

#75

Post by root_axis »

captainmuon wrote: post #47

I really don't like hooks, because they are so magic. The old class based way of doing things was much more explicit. At least, hooks should take some kind of "context" and "name" parameters so that they are in spirit a pure function. Then you could also call them in loops and if blocks without problems. Actually, class-based components have some annoying magic, too. The type of the object you create when you write `…

Hooks are more explicit for the uninitiated. Understanding the semantic meaning of when arbitrary method names are invoked throughout the component render cycle requires more investment in react's documentation than intuiting the logic of imperative function calls like "setState" in the body of functional component.

Re: Hooks: React’s Do-Notation

#76

Post by kimi »

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?

Go have a look at what Elixir is doing with LiveViews ....

The fatal flaw of React is that there are two states - client and server. Very often two different languages. Two different teams. Long and painful build. And in any case, you cannot trust the client. In 99.99% of the use cases - apart from extreme scale and full page renders - a LiveWiev will be more than enough, at 1/20 of the complexity and development time.

And yes, we use React.

Re: Hooks: React’s Do-Notation

#77

Post by dimgl »

rezonant wrote: post #38
dimgl wrote: post #14

Earlier quoted context omitted.

This article is a bit long-winded. I don't reason about React at all like the author of this blogpost. Using React with hooks is dead simple, and getting a React app running takes minutes.

Minutes to build, years to unspaghettify

This is true of all projects that scale uncontrollably

Re: Hooks: React’s Do-Notation

#78

Post by eru »

paldepind2 wrote: post #30
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”.

Maybe.

I'd say there are many different notions of composability. It's partially a matter of taste to elevate one of them to be The One and Only Composability.

But only partially. Partially there are also somewhat objective notions, or at least notions shared between different subjects, of why one thing is more properly composable than another.

Eg it's pretty uncontroversial to say that a program build out of functions composes 'better' than one build from loops and mutable variables.

From a wider point of view the problem with monad composability is exactly that they require a special kind of composability on their elements (join or bind), which makes them less composable with each other.

Re: Hooks: React’s Do-Notation

#79

Post by rezonant »

dimgl wrote: post #77
rezonant wrote: post #38

Earlier quoted context omitted.

Minutes to build, years to unspaghettify

This is true of all projects that scale uncontrollably

It is not true of all projects _to the same degree_. Highly conventional, opinionated systems have a higher learning curve but yield a more consistent result given developers with inconsistent skill levels and investment in architectural design of an application.

That is a fancy way to say: React gets new devs productive fast, and so it has tons of them available for work, but that comes at the cost of producing more spaghetti that more experienced devs inevitably have to clean up.

Re: Hooks: React’s Do-Notation

#80

Post by dimgl »

rezonant wrote: post #79
dimgl wrote: post #77

Earlier quoted context omitted.

This is true of all projects that scale uncontrollably

It is not true of all projects _to the same degree_. Highly conventional, opinionated systems have a higher learning curve but yield a more consistent result given developers with inconsistent skill levels and investment in architectural design of an application. That is a fancy way to say: React gets new devs productive fast, and so it has tons of them available for work, but that comes at the cost of producing more…

> Highly conventional, opinionated systems have a higher learning curve but yield a more consistent result given developers with inconsistent skill levels

This is highly debatable. A lot of conventional and opinionated systems have lots of under-the-hood magic that make it hard to reason about, even for experienced developers.

Post reply on HN