infernu VS penrose

Or maybe a sound type system can only be achieved either by limiting JavaScript or with a different language that compiles to JavaScript?

Very constrained. Since "constraints liberate, liberties constrain", as Bjarnason said. Inspired by Golang's minimalism, and Elm's guardrails. For learnability and maintainability. Since discipline doesn't scale (obligatory xkcd: with too much power, and the wrong nudges, all it takes is a moment of laziness/crunch-time to corrupt a strong foundation), and a complex language affords nerd-sniping kinds of puzzles, and bikeshedding and idiomatic analysis-paralysis. Counter-inspired by Haskell. The virtue of functional programming is that it subtracts features that are too-powerful/footguns (compared to OOP), namely: mutation & side-effects. The language designers should take care of and standardize all the idiomacy (natural modes of expression in the language). "Inside every big ugly language there is a small beautiful language trying to come out." -- sinelaw. The language should assume the developer is an unexperienced, lazy, (immediately) forgetful, and habitual creature. As long as software development is done by mere humans. This assumption sets the bar (the worst case), and is a good principle for DX, as well as UX. The constrained nature of the language should allow for quick learning and proficiency. Complexity should lie in the system and domain, not the language. When the language restricts what can be done, it's easier to understand what was done (a smaller space of possibilities reduces ambiguity and increases predictability, which gives speed for everyone, at a small initial learning cost). The language should avoid Pit of Despair programming, and leave the programmer in the Pit of Success: where its rules encourage you to write correct code in the first place. Inspired by Eric Lippert, but also by Rust.

I know, but I'm using GHCJS so I'm pretty much stuck with it (and using different compiler versions for development builds (which are native executables) and production doesn't seem like a good idea). There is hope though https://github.com/ghcjs/ghcjs/commits/ghc-8.10

Other than that, I ran into a GHCJS and Miso bug, but they weren't too hard to solve.

There are a bunch of open branches. And yes, there is ghcjs support in haskell.nix, see this comment.

Default branch on ghcjs github is 8.6. 8.10 is a wip with commit from around a month ago.

When I compile the ghc-8.8 branch locally, I get a number of test failures from the test suite. I'm not sure exactly how to fix them and they aren't currently my highest hobby priority.

https://gitlab.com/platonic/shpadoinkle/-/issues/29 https://gitlab.com/platonic/shpadoinkle/-/issues/100 https://gitlab.com/fresheyeball/Compactable/-/issues/3 https://github.com/ghcjs/ghcjs/issues/775

In theory it is possible to write applications that run in the web browser in Java or C# or C++. There are compilers to compile Java to JavaScript or C++ to JavaScript/WebAssembly and a C# runtime that runs in the browser. In practice these technologies are very niche and only used for very few applications. The Cardano Wallet Daedalus is written in JavaScript even though most of the software for Cardano is written in Haskell and there exists a Haskell to JavaScript compiler. Ask yourself why. The reason is that Haskell developers are not used to writing web applications and there is no big library ecosystem for writing web applications in Haskell.

https://github.com/ghcjs/ghcjs