I don't think you can apply the same principles to OO and FP but in terms of refactoring, my experience is that pure functional code is a joy to test and maintain. Small pure functions (again functions can only be pure functions, otherwise you're really talking about procedures), are by their nature easy to test, compose, cache, parallelise and pipeline. If that sounds bad to you, then fair enough.
I personally found F# to be a decent alternative to Elm for small browser apps with Fable, Elmish/Feliz, Feliz.Plotly etc.
You can generate typed interfaces for any libs you're missing which have a typescript interface using ts2fable, that's the kind of pragmatic tooling you need if you're veering off the well-trodden path in commercial development. Ionide in VSCode is excellent (though not perfect) and the compilation times are decent.
In terms of community (which is not unimportant when it's that small) even the compiler gitter folks were super helpful when I had some reflection questions. Overall I'd use it again for small browser apps, for backend I guess it depends on your company and domain.
It's true that it's easier to write and arguably harder to read code when types are not specified, or at least it's handy for public interfaces between modules. Luckily this is easy to do and often done:
It's the same deal with Haskell, you don't HAVE to specify the types of your code but it can help check your assumptions as to what the compiler is inferring. I've frankly found that a more frequent issue in Haskell because of pervasive use of Monads and other higher-order constructs.
Flash still powers Youtube for most users, Silverlight for Netflix and Unity's plugin is required for most 3D games on Chrome's Marketplace (not sure where else to look for successful HTML5 games).
There are actually several other casual gaming startups in Hamburg e.g. Bigpoint GmbH which followed a more American model of growing as fast as possible and selling out early, so I don't think it's a German/European thing necessarily. Given one of Jimdo's competitors Wix is IPOing this year after an enormous marketing spend, it doesn't seem industry niche-specific either. (Disclosure: I work at Jimdo, feel free to ask me anything)
The author claims that C has "an order of magnitude more expressiveness" than assembly with no basis for the statement, but ok. He then throws all the "compile-to-JS" languages together even specifically mentioning Sibilant which has macros.
If there is another 10x expressivity gain to be had by adding any language feature then surely macros are it.
"It's been a year since we've filed for bankruptcy and we're still there." - I work in a company that strives to follow such a model, and it honestly struggles to achieve the kind of efficiency most companies take for granted. I dearly hope it doesn't lead to that end, but from what I can see it's a distinct possibility.
"An implementation may set limits on the size of texts that it accepts. " - How does that "support" streaming?
My argument is that most people don't need it most of the time (I can't prove this). It's also NOT a protocol designed for streaming. As regards API design, it's a matter of taste but my preference and that of many others who use python, as we can see with the popularity of requests, Flask, is that an API should be designed for simplicity for the common use cases rather than for absolute completeness.
I'm not saying don't expose a low-level API full of BufferedReaders, JSONParserCursors, but don't force it on me to parse a tiny JSON document of known length.
It is perfectly acceptable to design a library with a simplified, restricted interface that covers the majority of use cases, but not all. e.g. requests vs urllib2 For me, that's a win for common sense. I have never even considered streaming JSON.
The lack of streaming support should be a clue that the OP needs to look at whether what he's attempting is even sensible or could be better served by a different transport protocol with built in streaming support.