Can you expand on what you mean by "it's 'opinionated' macro based module generation is a hindrance to building a more typical api based http service"?
It was pretty interesting to see Floki get a lot faster and Meeseeks actually get a little slower with OTP 21. I'll enjoy figuring out why. I hope to get a chance to work on the OTP 21 performance of Meeseeks before too long.
On the plus side there were some nice memory improvements for Meeseeks in OTP 21.
Meeseeks's speed difference with Floki is not that significant, and my initial findings are they've leveled out even more with OTP 21, sometimes even swinging in favor of Floki.
The better handling of malformed HTML by default is the much bigger deal.
(If you're asking about what flavor of Javascript I use) I just use plain JS for the bits of JS I need, but nothing I have been working on needs a heavy front-end.
There's not really an Elixir equivalent of Clojurescript to Clojure (there is an Elixirscript, but it's a work in progress and I'm curious whether it can ever capture the nice experience of using the Erlang VM). I've seen interest in the Elixir community in Elm and Bucklescript(OCaml) and other compiled-to-js languages, but I think a lot of people just use JS.
I came to Elixir from Clojure and was not a big fan of Elixir's syntax, but I've found that after a while it mostly fades into the background (much in the same way that Clojure's parens do).
The language and Erlang's virtual machine are generally a joy to work with, and I have no regrets pushing past the syntax.
For the sake of accuracy there was also some stuff in there about a conflict between first-class functions and the type system, and some stuff about errors being easy-to-ignore return values.
I've only recently started using ClojureScript with any intensity, but at the moment I agree with the author that the experience has been neither fun nor productive.
I don't necessarily feel that this is a problem with the language (though the current macro system doesn't seem simple or easy) but rather that this is a problem with the youth of the language.
The Closure compiler seems like a wonderful thing, but you really want to be able to use advanced compilation and that makes interop with other libraries... confusing (at least while you're getting started). This makes it a lot harder to just jump in and get started by calling on host (Javascript) libraries to get stuff done. Combine this with the fact that there aren't so many pure ClojureScript libraries and wrapper-libraries available (relatively speaking), and productivity is a bit stunted.
All of that said, I think ClojureScript has as much potential as Clojure on the JVM and I look forward to things improving as the ecosystem matures. It is wonderful to write Clojure and control the client, and I think that those people who can fight their way through (what I found to be) the unfortunately steep getting-started curve will have a hard time going back to vanilla JS.
Obviously we would not rather pay. The internet is the bastion of free (beer) information/stuff-that-can-be-transferred-electronically, and I think a great percentage of users prefer said free-ness.
All the same, I am more and more convinced that subscription funded, high-quality digital content production is the correct path for the future.