41–50 of 158 posts
For someone not in the web dev space, this looks like an interesting way to get started. If one has Python and Rust experience, what would be a recommended "first principles" path to get started in understanding web development with LiveView and Svelte?
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…
Either way it'll probably take about two hours to have your first rudimentary Phoenix chat application loaded in a browser if you follow some guides and tinker around a bit.
> There is a (literal) speed of light limitation with this approach: your server can only be so close to your users. The next step is to compile your server to WebAssembly and ship it to your clients. You can then use it to optimistically render responses while waiting for the real server to return. Sounds a little crazy, but we've actually pulled it off for a project, and its magic.
For someone not in the web dev space, this looks like an interesting way to get started. If one has Python and Rust experience, what would be a recommended "first principles" path to get started in understanding web development with LiveView and Svelte?
But then that approach has almost nothing to do with svelte or any other SPA tool so that is something else you’d have to learn.
Personally I’d start with either Phoenix and avoid any SPA tools until you get really comfortable and have hit the boundaries of what is possible with Phoenix. Or alternatively, I’d start with sveltekit and not think about Phoenix and save exploring that for another time.
Phoenix is super cool, but I’d suggest starting with SvelteKit, as you can build full stack apps and the same principles apply if you want to move to react or vue or anything else.
Earlier quoted context omitted.
I never used ASP.net so I cannot offer a comparison about what is "better" but your assumption is correct that diffs are through a WS and merged client-side. What this has resulted in is actual order of magnitude of implementation time reduction over the crazier SPA complexity available today. Less time to build, less cost to the company, less bugs in the long run, and a single place to manage and reason about state.…
But isn't there a delay in UI responses because of latency then?
I've wanted something like this for Vue/React too with LiveView, because then you get access to this massive ecosystem of great components to put in your phoenix apps while still utilizing LiveView. (the LiveView component ecosystem is tiny). So maybe this can be the start of a general bridge that can bridge LV with React or Vue components too? And make it easy to put these in a page and interact with LV events, etc.
The only big downside is you also need to setup server side React rendering for the initial load if you care about SEO.
Maybe I should dig it up and post it in a gist somewhere (I don't want to maintain an open source library for it).
> There is a (literal) speed of light limitation with this approach: your server can only be so close to your users. The next step is to compile your server to WebAssembly and ship it to your clients. You can then use it to optimistically render responses while waiting for the real server to return. Sounds a little crazy, but we've actually pulled it off for a project, and its magic.
> There is a (literal) speed of light limitation with this approach: your server can only be so close to your users. The next step is to compile your server to WebAssembly and ship it to your clients. You can then use it to optimistically render responses while waiting for the real server to return. Sounds a little crazy, but we've actually pulled it off for a project, and its magic.
Why wouldn't you just use a Service Worker for this?
Kind of similar to the content of this article, I wish people were more upfront with their reasoning. Doing something because "it's rad" is definitely fine by me!
> There is a (literal) speed of light limitation with this approach: your server can only be so close to your users. The next step is to compile your server to WebAssembly and ship it to your clients. You can then use it to optimistically render responses while waiting for the real server to return. Sounds a little crazy, but we've actually pulled it off for a project, and its magic.