Hacker News Reader

I've written quite a lot of F# code for the web over the last few years. Most of the time things just work as long as you don't use overly specific .NET BCL stuff.

We had issues with Dates. Implementing a custom 'ZonedDateTime' type with native implementations for both target platforms (JS and .NET) was straight forward.

Other than that there are a few gotchas when doing 'advanced' stuff:

- Fable does not support 'Array2D', 'Array3D', ... - Fable allows the use of ints but you have to know that at runtime they all are floats. - Fable does not support FSharp Quotations. - Fable does not support the full reflection API.

More here: https://fable.io/docs/dotnet/compatibility.html

Would definitely recommend F# for both backend and frontend. It's been a joy.

ClojureScript is in a weird boat because of a constant background tension in goals of the Clojure community, where on the one hand Clojure proclaims that it is a "hosted language" and as such there shouldn't be an expectation of consistent semantics across different hosts, but on the other hand devs really like consistent semantics if the language doesn't change. So the Clojure community has kind of settled on cljc files as an indication of "works on all hosts in the way you would expect" even though that's not any part of the guarantee that a cljc file provides in any documentation anywhere (it gives you reader conditionals and that's it). Basically ClojureScript isn't really sure whether those "caveats" are bugs or features and neither is the Clojure community at large.

More broadly they aren't sure whether causing "libraries and in-house code alike to break in weird ways" on different hosts is a bad thing (some folks would probably take issue with the word "break").

On the whole however these projects can go very well. I've seen e.g. ScalaJS and Scala backend projects work very well. They're a lot less leaky than you would think. The vast majority of code just works. In particular, there are clean lines between what is supported by the abstraction and what isn't, and the latter doesn't affect the former, so in that sense the abstraction is pretty tight and not leaky. And the major win isn't so much the familiar language part as it is the ability to share code and definitions. It's really powerful to change a line somewhere deep in your backend and have all the places you need to make a change all the way out to the frontend UI automatically laid out for you.

That said the big misconception, and where the abstraction is incomplete if not leaky, is that these languages allow you to disregard the runtimes of secondary targets. No compile-to-JS language I know of has successfully done away with the need to understand the HTML/CSS/Javascript stack. And that indeed is extra complexity that should give pause to developers.

But RE "cause libraries and in-house code alike to break in weird ways" generally does not seem to be the case for these compile-to-JS languages.

I'm only passingly familiar myself, so I might be off here-- but F# already has that sort of feel and experience, where it has some of its own ways of doing things despite integrating into the .NET runtime.

In other words, the language designers and users are already used to understanding corner cases and integrations into ecosystems that are different.

Interesting point! I haven't used F# so I assumed it was pretty "native" to the .NET runtime

Still- I have to wonder about things like concurrency, which is perhaps the most obvious limitation of targeting the JS runtime

There are some caveats they outline for the usual async stuff[1], but at a cursory glance, it's not that bad. Thanks to F#'s computation expressions, .NET async code and Fable.Promise code look almost identical.[2]

1: https://fable.io/docs/dotnet/compatibility.html#Caveats-II

2: https://stackoverflow.com/a/54451205/4099287

My suggestion is to use async in F# code by default. Use task for certain heavy server code on .NET and promise for JS interaction, where required. Async mostly works everywhere.

Is there some sort of (for lack of a better term) Monad Transformer that lets you mix `async` and `promise` in the same computation expression?

Computation Expressions are implemented using a class under the hood so you could probably build one with appropriate overloads.

There’s a function that Fable provides to turn a promise into an async, so mix and match isn’t a huge challenge anyway.

Yeah, I'm just trying to avoid having to throw the adapters on each line. Just like fable supports any thenable, it'd be cool if async/task could be treated as a thenable.

F# is certainly a .NET language depending on the lens with which you view it. The object system and lots of its semantics are the way they are because that's how .NET works. However, a surprisingly large amount of this stuff is translatable and makes sense with a JS runtime instead. The fable authors have managed to thread the needle just right so that it more or less "feels right".

The reason I'm bullish on Fable (and Feliz) is that in my experience the challenge in writing a modern web application is dealing with state, especially when API calls are involved. With Fable I save a lot of time (and bugs!) in that, so I'm okay with spending more time integrating with javascript libraries.

In my experience you can achieve the same functionalities with a lot less complexity in Fable + Feliz than the equivalent typescript stack.

People would rather write a compiler than write js. Ridiculous.

Er, yes? Compilers are brilliant fun.

It just shows how terrible JS as a language itself.

That doesn’t strike me as being ridiculous at all

- Shared language for server and client has its advantages.

- F# has some significant advantages over JavaScript (and TypeScript).