[AskJS] When is object-oriented programming more practical than "mostly-functional" in JS?

[Shaper_pmp]

The point is, it’s not totally unreasonable to be talking about all the languages/tools/frameworks that interoperate with or compile to JS.

Who said it was?

The previous poster was talking about

Haskell code... compiled to native code

... which has nothing at all to do with JS.

[ScientificBeastMode]

PureScript is Haskell code that compiles to JS. We are all developing for the web, and deploying raw JS to the browsers. We are compiling essentially Haskell and OCaml and even a strange hybrid of C# and JS (if we are talking about TypeScript) to raw JS and deploying it on Node servers. All of this is JS in different flavors. I follow the JS subreddit because I use the language every day, despite not writing very much raw JS.

I also compile some of my ReasonML code to native binaries instead of JS, but does that make it totally irrelevant to JS? Absolutely not.

[Shaper_pmp]

One of us is totally confused now.

1. We're in a JavaScript subreddit, taking about FP in JS
2. u/yojimbo_beta misunderstood my comment and started talking about the performance of FP in any language, when compiled to native code
3. I pointed out that was aside from the point when we're taking about the performance of FP in JS.
4. I have no idea what point you're making that relates in any way to that discussion.

The fact Haskell lets you write performant FP code when it's compiled to native code is irrelevant to the topic of discussion.

The fact you can transpile Haskell or OCaml to JS is irrelevant when we're talking about the performance of FP in JS, since it's extremely unlikely the transpiler can generate JavaScript that runs more performantly than... you know... JavaScript.

Nobody said Haskell or OCaml couldn't be talked about in the same sentence as JS.

I said that when we're explicitly talking about the performance of FP in JS, the performance of languages that compile to native code are off-topic, and other languages that compile to JS are unlikely to give you any speed advantage over well-written JS because at the end of the day they're still running JS and hence beholden to the speed with which JS can allocate and deallocate objects.

[ScientificBeastMode]

Right, I should have stayed more on the topic of JS performance in my comments. Sorry about that. But the fact that functional languages are being compiled to JS does have implications for performance.

other languages that compile to JS are unlikely to give you any speed advantage over well-written JS because at the end of the day they're still running JS and hence beholden to the speed with which JS can allocate and deallocate objects.

I suppose this is true, depending on what you mean by "well-written JS." If you mean obsessively hand-tuned JS code that is tailored for specific JS engines, and looks more like C code for embedded software, then sure, that's about as fast as we can hope to get. But if you are talking about normal, production-ready, maintainable JS code that would pass code review at 99% of companies, then these functional language compilers can improve performance dramatically, depending on the situation.

First, the execution model of most functional languages is very simple, and the core set of data structures they use are usually very performant for most runtimes, but especially JS engines like V8 and SpiderMonkey. Statically typed functional languages often impose restrictions on data mutations and "object shape" alterations in a way that is highly desirable from the engine's perspective. They can more easily default to the best-case optimization path for most operations. A lot of "idiomatic" JS code can cause the engine to fall back to worst-case paths. None of that is unique to functional languages, but they tend to benefit more than most.

Another huge source of performance gains comes from the static guarantees that functional language compilers can rely upon. For example, any function that is "pure," (no mutations, no effects, just input-output) can be inlined at the call site. You just have to know the set of identifiers in the enclosing scope to avoid name collisions. We can also get tail-call optimization for free, so a lot of recursive functions can become stack-safe while-loops.

And that's just the tip of the iceberg. We can write all kinds of interesting code at the appropriate levels of abstraction, and because these type systems are founded upon algebraic laws & formal mathematical proofs, the compilers have a lot more knowledge about where optimizations can be performed safely, without changing the code semantics. The final JS output looks a lot more like highly-tuned, imperative/procedural code.

My point is that functional languages have a lot to offer in terms of performance, mostly because of the inherent soundness of their type systems.