FRP and Sodium javascript

angelman 2016-12-01 23:51:17 UTC #1

Hello! I'm reading through the book "Functional Reactive Programming" and am really enjoying the style its written in. I'm curious about chapter 6, though. It's the chapter on FRP on the web.

It compares a few javascript libraries to Sodium but since there's now a typescript/javascript port of Sodium, I wonder if sticking with Sodium for web based applications would be best or if there is some other advantages in using the other libraries?

the-real-blackh 2016-12-02 01:55:45 UTC #2

Yes - as the author of Sodium and the book... The advantage of Sodium from my point of view is the one I'm claiming in the book - that it's compositional. You'll need to ask someone else if you want a less biased answer.

The advantage of other libraries is that they're more mature and have better integration, more widely known, etc.

I wrote the book before I had implemented Sodium for Javascript. If I had been able to, I would have based the book on Sodium for Javascript instead of for Java.

Steve

graforlock 2016-12-02 22:00:23 UTC #3

Edit: Had to edit my post to really convey what i meant!

TDLR: Web development can be done very well with functional things Sodium + Ramda + Hyperscript and throw Immutable at it if you want.

For instance, inferior paradigms, like React, are completely incompatible with Sodium and Reactive programming in general. Sad, that is to say.... So you can forget about integrating it with it, and things alike. But its fine, React and alike (they are very popular now) really sucks and will be completely gone in a year or so (I truly believe so, and I am a React developer). It is, paradigm-wise, OOP, but OOP in the state where Java was fifteen years ago, I am not even joking.

You can compare different FRP paradigms but thats about it. It, most of the times , isn't compatible with regular state machine architectures.

The power of FRP in Sodium is explicit simplicity. It is very clean.

Main problem is that FRP isn't that popular. People are afraid of Functional Programming, literally, and that is why. Nothing functional has gained enough traction. Not even RxJs, neither did Elm. Lets look at Ramda, even though its much better than lodash/underscore, its never gained that much attention. Its sad because lenses and everything else in it - are beautiful. This is the nature of a problem.

But Its gonna get there, though.

MVC is now dead, but for how long its been alive? And how religiously its been followed since 1970s ? Very very very....

Bonus material: http://staltz.com/dont-react/#/

Rarely anything thats really popular these days is actually better. Rarely does it solve problem in a better way.

angelman 2016-12-03 17:05:09 UTC #4

Yeah, when I first heard about FRP, React was gaining popularity and I gave it a look, thinking it was FRP. It was interesting but I felt something was off and it wasn't until the FRP book by Mr. Blackheath that I realized what more I needed to learn.

graforlock 2016-12-03 19:55:43 UTC #5

Name is very deceiving, that is why. The problem is much the same as with Angular 1, there is a state machine container and its the main feature of the framework (for Angular, it was $scope and $rootScope).

Then, people quickly realise that something is inherently wrong with it, and try to avoid it like fire, running in all kinds of trouble; they then create some nasty hacks and workarounds like Redux to not use this.state at all or in case of Angular, signify that $scope use is dangerous / frowned upon. This is what happens when state is a passive property but not a stream flow. Same issues, same problems, other than, React poses even more, like providers is pain, and so they had to go full monkey style, implementing another hacks like Saga for side-effects.

So in the end, all of this is trying hard to resemble Elm, but it is not Elm, and the underlying paradigm is different: like trying to build a solid high tower on a foundation made of cake, it flops, a lot.