[egeozcan]

If you don't have the urge to jump off a hill when you see heavy pragmatism, Typescript is very popular and well maintained. My experience is only positive.

I was also wondering, does Blazor work with F#? That could also be an option. Not a front-end focused language but a front-end focused framework, so, there's that.

[pd-andy]

Oh yeah I knew I was forgetting one, F#/Fable seems really popular among F# devs, but it doesn't seem like it's picking up any traction for FE devs that aren't already in that community.

Typescript encourages and is generally more conducive to a different style of programming. That's OK (in fact, clearly it's more than OK given its popularity) but it's not really the sort of thing I want to be writing. I think it's worse if you commit to something like fp-ts or the fantasyland stuff, personally.

[johnday]

I truly believe TypeScript is the only true way forward for frontend web programming.

Now what we really need is a functional dialect which compiles to TypeScript...

[toastal]

TypeScript has a bunch of holes in it because it needs tight compatibility with JavaScript. While a pure functional style may be possible, it isn’t first-class or ergonomic or as expressive, and won't cut it for many. Are there first-class function composition infix operators? Is pattern matching algebraic data types often the easiest way to write code? Is IO managed? With a language like Elm and others in the ML family, functional style is the only game in town, not just the in-house convention, and it's easier to have people using a similar style if it’s ergonomic. Even if you’re willing to give up managed IO OCaml and Reason are going to suit this programmer better than TypeScript. I would not be surprised if a lot of the fp-ts crowd is merely tolerating this as a comprise.

[johnday]

I didn't say we should use Typescript, I was suggesting a FP dialect which compiles to typescript.

[cnasc]

> Now what we really need is a functional dialect which compiles to TypeScript...

Why would it be beneficial to have TS as an intermediate representation? It turns into JS anyway, and there are already statically typed functional languages that compile to JS.

[johnday]

It would massively simplify the job of proving the upper language more correct. It may also be possible to proxy the type system in order to make use of existing tooling.

[_0w8t]

TypeScript or Flow for that matter sucks at using functional style with immutable data types. There are ESLint plugins that allows to enforce immutability with plain JS objects, but still lack of syntactic sugar or union types makes the experience much worse then in functional languages.

[RobertKerans]

https://github.com/tc39/proposal-record-tuple

Only stage 2, so whether it'll get through to next stage is up in the air, will depend on interest (compare to Temporal which started fairly slow but has gained huge momentum recently and is now at stage 3 and engine testing level) but it's encouraging.

[johnday]

Perhaps what we need is a dialect which compiles to typescript and supports (or better, enforces) the immutability you suggest.

[sanatgersappa]

Yup. Try https://fsbolero.io/ . Follows the Elm Architecture.