> Liveview is incredibly straightforward.

I don't agree. One of the keynotes from the 2023 ElixirConf was Chris McCord (one of the principle developers of LiveView) describing how it is almost 1.0 [1]. One thing that made me laugh a bit was him emphasizing how much Javascript he's had to write (he was referencing the fact that there is an internal community meme that you can achieve such incredible behaviors without writing Javascript). His quip was "because I wrote it all". I wonder if you asked him "was it straightforward?" what do you think his answer would be?

There are a lot of videos of people talking about how they managed to write something in LiveView. Here is one from 2022 "How I built a block based editor in LiveView" [2]. That is a good one to see how non-trivial tasks can be difficult in LiveView, describing a few times how he had to fight with it to get it to kinda-sorta do what he wanted. Certainly this man will achieve his goal since he is smart and motivated, but his description of his journey does not lead me to a conclusion of "this is incredibly straightforward".

This is impressive tech no doubt, but it is far from clear it is currently reliable enough to stake a startup on. Another tangential issue I have with LiveView is the obvious requirement for a persistent socket connection ... which leads me to wonder how one would approach local-first type developments. Again, certainly possible but definitely not straightforward.

1. https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeS...

2. https://www.youtube.com/watch?v=7yZwxsG7tVs

LiveView is optional though and IMO is still overused for tasks that would be better accomplished with client side JS.

Where this gets messy is mixing LiveView and client side JS, and I need to experiment further with this (or find people who have).

I suspect that you might be right about using LiveView for things that are traditionally full, rich client side JS apps.

However, it is absolutely awesome for the "slightly javascript" case of a lot of UIs. Two examples, from my work:

Forms with "live" display of validation errors, using one single set of validation on the backend, rather than the duplicated frontend and backend having to match. It's completely trivial to implement with LiveView.

Status displays - We built some development hardware based on a Xilinx Zynq FPGA (FPGA + ARM running Linux) and used LiveView to report a lot of the hardware state - primarily the status of all of the registers. A little fiddling with HTML+CSS for the register widget, but then everything else could not have been easier - render your widget once per register, and rerun that whole thing any time pubsub provides an updated register value.

This isn't really contextualizing the problem space well imo. How many companies exclusively used react pre-1.0? How many people using the "straight forward" vueJS had ever read the source code to understand the internals?

When someone says that liveview is straightforward, they aren't comparing it to stable backend languages that almost exclusively run on one operating system and one architecture and they certainly aren't referring to the many hacks every JS library incorporates to make the library more useful.

I think we have different definitions of straightforward. Liveview is straightforward to use because of Chris mccords effort and his good taste in software design and how a genserver is a good framework for state management.

I find LiveView either straightforward or a bit complicated, compared to other solutions, depending on the exact use cases. It's not necessarily easy initially to grow you own way to properly handle some scenarios, and some people can find the mental switch not that easy (but in general, it has been very useful to me!).