Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

Are they pure? I don't think JS has any way to guarantee referential transparency, though of course the use of a virtual DOM can mitigate side effects by having well-defined behavior.

Furthermore, the input-process-output model can hardly warrant being called "functional" in of itself, unless you really want to overload the term.

The React way of independent handlers that trigger events which incrementally calculate state and update views, is, in fact, quite similar to how Smalltalk UI paradigms work, right down to the installation of an event handler resembling a message send operation.

If you don't believe me, check out the Morphic framework that Self uses to implement its environment UI. The similarities are striking: http://handbook.selflanguage.org/current/morphic.html

View on HN

If they are not pure, you are literally making an error (as the framework states they are supposed to be pure).

input-process-output is how pure functional languages (such as Haskell) deal with imperative coding. You push the imperative part to the top of the call stack and try to keep the rest of the computation pure.

JavaScript inherited quite a bit from Smalltalk, so you will find similarities like these in JS in general.

Flux supplements the standard React bubbling of events up the chain of components with a simpler, singular flow, making it even more functional.

That sounds like a try-hard simplification. Input-process-output is pretty much a generic metaphor for programming in general. I don't think React has anything like monadic encapsulation (not that a language like JS can conveniently accommodate it). You're observing a few high-level properties of a given paradigm and extrapolating an inferred architecture solely from those points.

In fact, you're equivocating the entire management and abstraction of mutable state as an inherently "functional" thing, which it is not. OO is just as much capable of factoring state as a virtual resource that you explicitly make transitions to and from and transparently or visibly share increments across object boundaries, as this is exactly what e.g. Self does with Morphic, right down to the same event handler structure. Just because one is a lambda and the other is called a method doesn't make a huge difference.

I'm saying that just about all of React's insights were done previously almost verbatim in thoroughly object-oriented environments. That some FP evangelists have a kneejerk hatred for it doesn't mean the mental gymnastics for insisting one over the other is necessary. They can be complementary.

I haven't used Morphic in years (and I used it in Squeak). While you're right that Morphic shares some things in common with React, the fundamental difference is that when a composite morph receives an event and needs to change, it has to explicitly pass messages to all of its submorphs to transition them to the next state. With React you simply throw out the old subtree and replace it with a new one. This is similar to how drawOn: works, except that throwing out and re-instantiating your submorphs for every drawOn: is expensive and loses UI state. React gives you this abstraction.

Additionally I'm not sure where you're getting this "JS can't be functional" opinion from. Just because it doesn't give you compile-time or runtime guarantees, or because the syntax may be more clunky, doesn't mean you can't get these benefits by convention.

Additionally I'm not sure where you're getting this "JS can't be functional" opinion from.

I never said this. I was talking more about the React architecture, specifically.

Though in general there is this phenomenon to grasp at any similarities and start espousing how functional a particular language/framework/library is, as if for street cred.

But I haven't written that input-process-output equals functional. I just pointed out that the React model allows for a larger piece of the code to be functional, in exactly the same way it's done, say, in Haskell. This has nothing to do with monads. Monads are used for the imperative, stateful code that is pushed to the top of the call stack, the bit which is partially managed by React for you (by calling the render method).

I would also never claim that React invented any of this. It just popularized this more declarative approach for building Web UIs

I thought your analogy was spot on. In React, the view is reduced down to a functional projection of the model - rather than being a complicated set of state interaction patterns (eg. mvc,mvvm). The React framework then handles the real DOM update - in the same way that a Monadic IO computation is not executed directly - but instead is passed to the Haskell IO runtime to be executed.

Reply on news.ycombinator.com