21–30 of 158 posts
In my app, I use reusable Stimulus controllers alongside LiveView, and it works seamlessly as well.
On a general note, while it's a pleasure to build with LiveView, the more I use it in real-life scenarios, the more I realize the benefits of stateless HTTP frameworks like Hotwire, which feel more performant and resilient to reconnections, and avoid the need to place more servers close to users for stability.
I created LiveSvelte, let me know if you have any questions :)
Is there any reason you can think of to still use JS Hooks if using LiveSvelte?
I've been looking at Bun to see if it would help but it's still unclear to me.
Heex rendering is just way faster.
If you don't care about SSR for certain components (for example modals, they don't need SSR generally), then I don't see a clear advantage for hooks.
If you like Svelte (I do) you're probably going to find sveltekit to be a lot simpler and more useful.
Generally speaking this is the model I’ve always been wanted to build apps in. Event oriented, bidirectional realtime updates with server, ordered events, local and remote state... I didn’t know about LiveView and never used erlang-family languages, but definitely they’re onto something. The traditional request-response model is many times causing a lot of subtle problems with consistency and staleness. A wishful (pr…
> I hope the next decade will be oriented around integrating stateful message-oriented (reactive?) programming into the mainstream full stack Also known as MVC before Rails decided to redefine the term.
Nice solution! In my app, I use reusable Stimulus controllers alongside LiveView, and it works seamlessly as well. On a general note, while it's a pleasure to build with LiveView, the more I use it in real-life scenarios, the more I realize the benefits of stateless HTTP frameworks like Hotwire, which feel more performant and resilient to reconnections, and avoid the need to place more servers close to users for stab…
Unfortunately, Stimulus doesn’t actually provide an elegant way to keep state on the client. “A stimulus application’s state lives as attributes in the DOM.” This means that it’s not better than vanilla JS or jQuery.
Edit: I haven’t used Stimulus for a real project; it’s possible their values and change callbacks are a better experience than I originally imagined.
Nice solution! In my app, I use reusable Stimulus controllers alongside LiveView, and it works seamlessly as well. On a general note, while it's a pleasure to build with LiveView, the more I use it in real-life scenarios, the more I realize the benefits of stateless HTTP frameworks like Hotwire, which feel more performant and resilient to reconnections, and avoid the need to place more servers close to users for stab…
My production app has no more than 200 lines of JS, and I could probably get rid of a couple Stimulus controllers. Live View is that good. I also made a very hacky Stimulus-Live View hook adapter, so my Stimulus controller can send events directly to the LV process.
EDIT: Live View does not require you to run geo-distributed servers at all, unless you have bought into the fly.io kool aid a little too much. And it deals with disconnections beautifully. I didn't even have to do anything to support zero-downtime updates. The client loses connection to the WebSocket and reconnects to the new version, restores the state, all that out of the box automatically. What more do you need?
So instead of managing state on the client, you manage state on the client and the server? That doesn't seem like an improvement, even if it saves you from having to build yet another API.
It is just a new generation rediscovering ColdFusion, Web Forms, JSF, PHP, Spring, Rails...
The difference between traditional technologies that render HTML server-side and LiveView, is a persistent connection to the server which allows it to re-render templates in response to server-side events and patch client-side HTML without writing any Javascript.
I am not familiar with LiveView, so I'm curious. Looks like it processes UI actions server side. So, are all client interactions sent through the websocket? I remember years/decades ago we used to do that with ASP.NET, where every single component interaction was handled by the server. How is this different / better?
Some people think it's kind of nice to have one programming language for everything, including queues, cache, database queries, client layout, business logic.