The future of web software is HTML over WebSockets

If you want to do requests in parallel, http 2 and 3 can do them just fine. If it’s sequential, you won’t see a huge difference between something on websockets and http/1.1.

The only thing you can save are a few header bytes. And it’s up to you how many headers you use

For comparison's sake:

- [LivewWire] Caleb (creator of LiveWire) made 1,000+ commits and added 200k lines of code from Jan 2019 to Feb 2021

- [LiveView] Chris (creator of LV) made 700+ commits and added 80k lines of code from Oct 2018 to Feb 2021

- [LiveView] Jose (creator of Elixir) made 450+ commits and added 25k lines of code from Oct 2018 to Feb 2021

There's even more contributors to LV (207) overall than LiveWire (145) which is interesting because LiveWire is 3x more popular based on GitHub stars.

From that you could say that LiveView has more manpower than LiveWire since Caleb wrote all of that code himself in a shorter amount of time while 2 people are main contributors to LV.

Plus at the same time Caleb wrote a huge amount of practical documentation (focused on building features), created lots of screencasts where you build features you would expect to see in most apps (data tables, etc.) and started a podcast around LiveWire. And on top of all of that he created AlpineJS at the same time.

> LiveWire builds on Laravel which is a massively popular framework on a massively popular language, Laravel itself using components from Symfony that is basically the backend framework with the most contributors in the world.

At a fundamental level it feels like the creator of LiveWire is investing in creating a tool that helps developers build applications better and faster. I think that stems from Laravel giving off a sense of developer productivity for building apps, but don't forget that library creators are making these decisions.

I never really got that same impression from working with Phoenix or LiveView. I think it caters towards a completely different type of developer than myself which is why I struggle so much using it. It always felt like instead of showing you how to do something, it makes you figure it out yourself.

> But LiveView may hit 1.0 this year :)

That would be nice to see but I'm not sure how much of a difference that will make in the short term. In the short term going 1.0 is really just deciding to tag a commit. If Chris and Jose plan to write another book to use LV that could still be over a year or 2 out unless they've been writing it in private, or if they re-write the documentation that's also another long journey.

Neither of them really strike me as the screencast type either. When they do create videos they do an excellent job at explaining things tho. Really wish they did more of them to be honest. But yeah, these things take time. I don't know what their schedules are like too so maybe it's not even fair to compare LV vs LiveWire in terms of how fast the library is being built. Maybe Chris and Jose only work on Phoenix and LV for 2-3 hours a week where as Caleb is working on his stuff full time.

Where Rails with “live view” tooling would work really well is building CRUD heavy sass apps that don’t need a persistent connection, just want really fast page refreshes and/or partial updates.

The work the basecamp team did on Hey seems to be a good illustration of that.

Because this won't respect HTTP caching and you'll end up sending way more data than you need. Best instead to just send up URI and `GET/DELETE` verbs to indicate intent. I wrote about this: https://github.com/krainboltgreene/pubway.js#pubway

Actually every HTTP benefit is a reason why you wouldn't want to send resources over websocket. What if the websocket connection is slower than changes to the resource? Instead of simply telling the client what to fetch, you just gave them stale data.