11–20 of 224 posts
I'm building a startup in my free hours using Phoenix Liveview. I can ship features in hours vs days thanks to the simplicity liveview gives me. ZERO react/JS nonsense. I back to writing server side rendered templates with for-free reactivity. Give it a try it's very productive
Speaking as an amateur programmer, is this like Laravel's livewire or intertiajs with inline blade component? (but in Elixir). Or is this something else?
This makes sense to me. Views always seemed a like unnecessary boilerplate to me. Better to keep all the code together in one module, and just import common functions. On the other hand, I don't typically like defining the template in a sigil, unless it's a really small one, so I probably won't do that much.
I agree in the case of HTML rendering, but I write a lot of JSON APIs and putting the JSON definition in the View has been very pleasant. It didn't say in OP, but how does this change an API? Maybe a `GreetJSON` instead of `GreetHTML`?
I'm building a startup in my free hours using Phoenix Liveview. I can ship features in hours vs days thanks to the simplicity liveview gives me. ZERO react/JS nonsense. I back to writing server side rendered templates with for-free reactivity. Give it a try it's very productive
The downside as I understand it is the extra work to manage UX for connections with high latency and/or going offline, correct?
High latency isn't an issue if you do it correctly by using the loading classes and what not so that the user knows they are waiting for some data to load. It's pretty much identical to a typical React SPA that has to show loading indicators while waiting for a JSON call to complete.
Phoenix.View is replaced by Phoenix.Component:
> With Phoenix.LiveView, Phoenix.View has been replaced by Phoenix.Component. Phoenix.Component is capable of embedding templates on disk as functions components, using the embed_templates function.
More on hexdocs.
People using Phoenix Liveview -- how do you serve native apps relying on the same backend?
Otherwise, part of the initial value-prop of LiveView is that if you don't need multiple frontends and you don't need offline support--which a whole lot of apps don't--then LiveView drastically simplifies your stack while still delivering "SPA-like" speed.
People using Phoenix Liveview -- how do you serve native apps relying on the same backend?
- We went hard on components and it's made building UI's easy. In fact I wrote a test library to make component testing easier.
- Live view is so easy with a good component library. I'm not a designer, but with snappy interactions and easy to use components, it's not hard to get something that's exciting.
- Elixir is a very nice language to write distributed systems in. Functional in all the right places plus it has OTP.
- The community is full of very senior people who freely answer your noob questions.
- On-boarding people has gone well. The syntax is friendly enough that experienced engineers grasp the basics, leaving functional programming and OTP left to discover.
So can we refer to LiveView’s counterpart as DeadView, now?
I have no links but click around https://elixirforum.com and you'll see referencing "dead views" often enough.