| Liveview / livewire |
Just testing a few Liveview / livewire implementations with morphdom. So far seems like a great way to avoid JS build complications. Only thing is the round trip to the server, serving via sockets (from what I can tell with phoenix liveview at least) and rendering back HTML as opposed to JSON, which could be an issue for non web based apps.
Anyone used it much?
Practical guide to IgnitedCMS - Book coming soon, www.ignitedcms.com
I've used Livewire on a couple of projects. I think it works pretty good for admin areas, once you get used to thinking that way. From what I've seen Pheonix Liveview is probably more optimized than Laravel LiveWire.
My take is that for a website that just needs some simple interactions Livewire can work pretty well. But you miss out on some of the more advanced UX experiences. And, as users are spending more on more time in apps, I feel they're starting to expect that app-like experience more and more from their websites. So many large websites have jumped on board the Javascript train for frontends I've come to the conclusion that trying to keep everything in PHP is great for simple sites, but at a certain point you just can't provide the experience users and clients are often looking for. I had started to work on a Livewire-like implementation for Bonfire before I decided that my personal project(s) needed a better UI. I use React at the day job, but my current personal project is in Svelte. Still exploring that. To sum up (too late, I know  ) Llivewire-like code definitely has a place, but I think we shouldn't be too beholden to staying within PHP and should definitely take the time to learn other front-end tools. Then the job is deciding which is the best resource to use when.
(08-01-2022, 01:48 PM)kilishan Wrote: I've used Livewire on a couple of projects. I think it works pretty good for admin areas, once you get used to thinking that way. From what I've seen Pheonix Liveview is probably more optimized than Laravel LiveWire. Great points, it's funny because I'm coming from the tail end of the SPA honeymoon period, after working with Angular, react, svelte, and eventually diving into Elm. (My personal opinion if I had to choose, Elm would come out top but it has much too low of an adoption point to invest time into.) The trouble is, I have no other conclusion to draw except the SPA way of life, is utterly maddening, especially when you take into account the webpack / vite builds, SSR, and state management, so liveview looks very promising. As elixir is made for this I'd imagine it would have better performance. But I mean, there is that issue of injecting html directly into the dom, and having another AST to do the dom parsing, which is a non trivial topic. I'm not sure how Caleb Porzio, is doing the implementation but I did hear he was using either using websockets, or just vanilla ajax with debouncing. It is definitely an interesting one. I'm starting to encounter issues with sprinkling vue components on the frontend but then passing that post data back to the backend.
Practical guide to IgnitedCMS - Book coming soon, www.ignitedcms.com
Oh I totally get it. For Bonfire I wanted to keep things as simple as possible so that I didn't have to deal with all of the complexities of the Javascript world. I opted to use Caleb's Alpine and then htmx. it has worked out pretty well for keeping it simple and keeping me sane lol.
I also agree the SPA world has some serious drawbacks. That's one reason I'm looking into SvelteKit at the moment, since the creator thinks he's gotten something with the best of both worlds. Still too young in that project to know for sure, though. Part of me still wonders if very carefully combining livewire with some JS components mixed in would be a good middle ground. As for LiveWire - you might be interested in his video series on recreating a simple version of Livewire. I've watched about 1/2 of it. Pretty interesting and mostly straightforward from what I've seen, though I'm sure the production version is much more complex by now.
@ignitedcms and @kilishan ,
I still haven't made the move from Bootstrap integrated into CI as my frontend. I've seriously thought about using Vue or Angular or React as my frontend but I've really not had a good reason to make the move yet. I've thought about using a templating system but even that doesn't interest me. What is the real benefit?
The benefit is a reactive workflow that is data centric. The real issue is when you're making components and having to pass and manage state. Angular / react / svelte, can't really be used other than as SPAs (*not technically entirely true), so you need the full build process - that involves node.
Whereas vue, alpine, htmx (as mentioned by Kilishan) and to a lesser extend (hyperscript  ) can be used as sprinkles to manipulate the dom. https://www.ignitedcms.com/videos/crud-builder For example, consider you have a complex interface, such as one in the video I've linked above. If you were to use jquery or vanilla javascript, you'd have to dive into the dom, store the result, do something then update. Whereas with a reactive js framework, you just update a value in a json array, and bam, that's it. I doubt I could have created my crud builder in jquery without it being way too verbose and difficult to read. Jeffery way, although the video is quite old, does a fairly good primer pitch. But once you get into components that is when all hell breaks loose, so you might actually be better off without it haha. https://www.youtube.com/watch?v=Y05uRiks...EfuCITvr_3 Also what we're talking about is how tech stacks are wanting to offload that frontend interactivity onto the backend, and that is where livewire /liveview comes into play.
Practical guide to IgnitedCMS - Book coming soon, www.ignitedcms.com
I think some of these architecture decisions that determine just how complex an application will become should depend on the resources and risk tolerance of a project's customer.
For "enterprise" customers, scalability and adherence to "best practices" are often primary decision points. For many of these types of projects, the skillset and associated hourly spend on the developers is often not a primary consideration, as they are likely to be using agencies to supply their dev talent. On the other hand, professional integrity dictates that for small customers who may not have huge revenue streams, building a system that is easily supported by garde- variety php devs after you get hit by a bus, should be a primary consideration. I guess what I'm saying is that, often times, our architecture decisions about which option is the "best" approach should be driven by customer needs. The "Which ajax solution is best for my project?" discussion is of huge interest to me, by the way. Thanks to @ignitedcms for starting the thread!! -Z (Using CodeIgniter since 1.x)
What about @lonnieezell Cellular project?
https://github.com/lonnieezell/cellular It seams promising and a great addition to Codeigniter framework. |
| Welcome Guest, Not a member yet? Register Sign In |
