Live data from Hacker News

How to deal with dirty side effects in your pure functional JavaScript

jrsinclair.com

1–10 of 38 posts

Re: How to deal with dirty side effects in your pure functional JavaScript

#2
As long as JS lacks partial application and the ability to define infix operators (for monadic `bind`, etc), it's always going to be ugly. Not that JS would be a good language for that to begin with. We need a serious functional language that compiles to WASM.

Re: How to deal with dirty side effects in your pure functional JavaScript

#5
post #2

As long as JS lacks partial application and the ability to define infix operators (for monadic `bind`, etc), it's always going to be ugly. Not that JS would be a good language for that to begin with. We need a serious functional language that compiles to WASM.

> We need a serious functional language that compiles to WASM.

Aren't there already a few? OCaml?

What's "serious" in this context?

Re: How to deal with dirty side effects in your pure functional JavaScript

#6
Pure functions have of course a lot of benefits - if the goal is computing a value. However, why would you even want to compose an interactive application (in javascript) fully out of pure functions?

E.g., suppose you have an SPA that pulls data from a number of Rest endpoints, then does some transforms on that data, produces some HTML and eventually updates the page DOM accordingly.

It makes sense model the "transform" and "produce HTML" steps as pure functions, because they are effectively side-effect free calculations. I think it might also make sense to cheat and treat the Rest calls as pure functions, because this will let you find out quickly in which order you should do them and which of them you can run in parallel.

But why would you want to model the eventual update step itself as a pure function?

Post reply on HN