Build a real-time Twitter clone with LiveView and Phoenix 1.5

DHH was right about this stuff long ago in 2012 (mixing server side rendering with interactive JS frontends) even as the software wasn't quite there yet: https://signalvnoise.com/posts/3112-how-basecamp-next-got-to...

The other approach is SSR with React/Vue that hydrates on pageload with something like Next.js/Nuxt.js. https://nextjs.org/

But the Phoenix approach seems better for a more Railsy single framework approach (assuming you don't like writing the entire server side code in JS, which I do not). It's more cohesive and quicker to roll something out.

I currently do mostly Vue with Rails backends professionally but if it was from scratch or rearchitected with Elixir I'd seriously reconsider using full blown Liveview.

My only concern would be missing out on some UI libraries and pure size of community support. But I wouldn't miss getting rid of the super complicated JS tooling set ups I currently use (in addition to rails or trying to jam it through the asset pipeline via webpacker), in exchange for a more centralized approach. I've gotten a bit too used to maintaining the frontend almost separately from the server app and sometimes miss the simple days of being pure Rails.

One additional concern may be portability for mobile with React native. But that only applies to a subset of apps where reuse/cross platform makes sense. Still it was a big reason why these SPA style frameworks flourished like they did.

They hit a sweet spot. Enough rigor, enough limitation, at the language level, to force you to do things "the right way" for a broad swath of problems (there are certain problems they're poorly suited for), but enough simplicity and freedom to keep a minimal learning curve, and minimal runtime complexity to figure out issues.

The focus on fault tolerance also means once you learn to use the app structure, with supervisors, you mostly have just one concern for reliability ("how do I start this into a known, good, consistent state?"), rather than hundreds ("what happens if -this- fails? Or that? Or that other thing?").

Haskell and Scala both have a huge surface area to learn before you're productive, let alone anything approaching fault tolerant, and even after years of use, there's still a lot of hidden gotchas with them. I've seen teams take Erlang, and their very first project just...worked. None of their lessons learned caused production issues, and no weirdness; the three issues that made it to prod I can even think of were, variously, one that wasn't user facing (just a log entry indicating something wasn't handled right; supervisor took care of it), one where performance started to slow (and it was due to having written an O(N^2) algorithm accidentally, and not testing at higher loads than production), and one where a low level C driver made an unnecessary reverse DNS lookup that, when the caches flushed, caused things to hang, which became an issue when load increased, and which should have been circuit broken (but which instead caused a failover to another node).

I've never had that experience with another language. The ramp up time to productivity was longer, the production issues caused by us missing something about the language were more frequent, the production issues caused by us failing to expect or handle a failure condition were more frequent, etc.

That said, Elixir and Phoenix do raise the bar a little. Elixir has a larger surface than Erlang (only a few concepts, but a lot of ramifications when it comes to macros if you haven't used them in other languages), and Phoenix is reliant on a fair bit of magic so you need to read the docs and it may take a little bit of work to feel happy with things. But even when I knew nothing about it, picking it was easy because of the experience I had with Erlang.

and it uses uPlot [1][2] in the metrics panel :D

[1] https://news.ycombinator.com/item?id=21207132

[2] https://news.ycombinator.com/item?id=22567922