Article misses a comparison to newer frameworks like Remix which are server side driven
Server side, Remix does not hold a candle against Elixir.
LiveView Is Best with Svelte
151–158 of 158 posts
Re: LiveView Is Best with Svelte
#152Earlier quoted context omitted.
curious, what makes it better? asdf has always just worked for me, but this is the first time i’ve heard of mise, so i’m wondering what i’m potentially missing out on
The mise docs have a great comparison page: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html In personal experience, all of these have held true. Mise is just easier to use than asdf and I don't have to `asdf -h` every time I have to use it. The performance is significantly better and I can use mise exec in shebangs without sacrificing too much startup time. And it's easier to install because it's a SLSE. I wou…
Re: LiveView Is Best with Svelte
#153Earlier quoted context omitted.
The mise docs have a great comparison page: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html In personal experience, all of these have held true. Mise is just easier to use than asdf and I don't have to `asdf -h` every time I have to use it. The performance is significantly better and I can use mise exec in shebangs without sacrificing too much startup time. And it's easier to install because it's a SLSE. I wou…
Anyone who wants "nodejs latest:20" in their .tool-versions file is probably confused. The point of .tool-versions is to pin a particular version in your source control so you know your whole team is on the same version in that branch. Getting the latest revision whenever you install means pointless drift.
Either way, I don't think many people are checking in tool-versions files. Most JS templates specify a range of node versions they work on and leave it to you to specify which one. I don't think this is unusual for most other languages I use, like ruby.
Re: LiveView Is Best with Svelte
#154Earlier quoted context omitted.
It's never that simple. In web applications there's always these types of states: * States that the client needs to keep track of * States that the server needs to keep track of Then on top of those there's two more kinds of states that overlap but they're not quite the same thing: * States that only need to exist in memory (i.e. transient) * States that need to persist between sessions There's a seemingly infinite n…
Interesting. What kind of app was it? How did you decide whether the server needed to keep track it? I’m assuming that was predetermined? What about new requirements, which would need to be tracked by the server? Could the app deal with this dynamically without code changes?
(Note: Company no longer exists so it is unmaintained, fork at will =)
It's been so long since I've looked at the code but I did write excellent documentation, most of which is generated from docstrings. Example:
https://github.com/liftoff/GateOne/blob/master/gateone/core/...
You can read the documentation here:
https://liftoff.github.io/GateOne/
If you look at the bookmarks plugin you can see an example of how I performed this style of clientserver synchronization using an Update Sequence Number (USN):
https://github.com/liftoff/GateOne/blob/6ae1d01f7fe21e2703bd...
After the web client connects to the websocket all the plugin's `init()` methods are called and the bookmarks plugin's javascript file calls `userLoginSync()`:
https://github.com/liftoff/GateOne/blob/6ae1d01f7fe21e2703bd...
It sends the current USN (which is retrieved from `localStorage`) to the server (the routing is quite sophisticated... Just know that the message ends up going to the correct function =) and if it's different from the USN on the server the server will send an updated list of bookmarks to the client at which point the client will take care of that via its own handler:
https://github.com/liftoff/GateOne/blob/6ae1d01f7fe21e2703bd...
If you examine the bookmarks.js from top to bottom (it's not THAT long) you should get the gist of where and how various states are stored. That plugin mostly deals with stuff in `localStorage` but if you poke around in Gate One you'll see vastly more sophisticated state synchronization and state update routines at work.
Re: LiveView Is Best with Svelte
#155Earlier quoted context omitted.
Anyone who wants "nodejs latest:20" in their .tool-versions file is probably confused. The point of .tool-versions is to pin a particular version in your source control so you know your whole team is on the same version in that branch. Getting the latest revision whenever you install means pointless drift.
Are you really sensitive to the minor/patch versions of node? I don't think it should make a difference whether you're using 20.9 or 20.12, and to me to that would be a bigger red flag. Either way, I don't think many people are checking in tool-versions files. Most JS templates specify a range of node versions they work on and leave it to you to specify which one. I don't think this is unusual for most other language…
Re: LiveView Is Best with Svelte
#156I honestly don’t understand how’s this different from react server components with nextjs but with less features? It seems like the same thing but with an even clearer border between server/client components and therefore missing all the optimizations (like streaming). Like islands architecture but made out of different technologies, is my understanding correct ? I would appreciate some feedback :)
LiveView has streaming. I would argue that if you're stuck in the React way of thinking about application design then it's not worth trying to sell you on what LiveView is doing. But there are multiple case studies out there showing that it results in far less build times than React for no compromise on user experience.
Re: LiveView Is Best with Svelte
#157Essentially, it works the same as Blazor Server. Or am I wrong?
Re: LiveView Is Best with Svelte
#158Earlier quoted context omitted.
I can see the next big thing coming: no latency! Render in client! :)
Seems maybe messy to have templating in the client but I'd take a look if someone has done it.