Right. It uses JS but you don’t write any. Or very little. Or in a custom DSL/framework.
I don't see the point of going back to full server side, you have to scale more with more users.
The only benefit would be if it all worked without running JS in browsers, but it doesn't.
And no, same hassle, same money spent. Thought about from the start server-side rendered pages are almost as cacheable as API responses will be. If you can't cache you're in for a world of expense at scale whichever way you go.
I would much rather scale out my REST/Graph/RPC API instead of having to scale out a WS API.
You can make it work when JS is disabled as well, you fall back to rendering regular HTML. It does require a little extra work, but it’s not insurmountable (e.g. using @conn instead of @socket).
>you have to scale more with more users
I might opt for additional optimizations once it gets bigger, but I’m not too worried about scaling Erlang processes.