7 ms·

Show HN: LiveViewJS – TypeScript back end for LiveView Apps (Phoenix LiveView)

146 points by floodfx 5y ago

Author here. I really love the programming paradigm behind by Phoenix LiveView applications and wanted to expand the ecosystem to include programmers like myself that love Typescript. In summary, LiveViewJS reuses all the Phoenix client code and implemented a new backend in Typescript to handle client events and send back updates. Lots more detail and examples in the repo. Would love any questions and/or feedback. Thanks!

benburton 5y ago
Looked interesting. Thought I would take a deep dive. README references a video behind a subscription paywall? I'm out.
- floodfx 5y ago
  > (This video by Pragmatic Studio does an amazing job of explaining how LiveView works.) I believe you are referencing this line from the README? FWIW - they have a free "starter course" which includes that video. I started on the free course and upgraded because I got a ton of value out of it and they are a small company doing great work. To be clear, LiveViewJS has no affiliation with Pragmatic Studio. I am just a fan. :)
deleted 5y ago
[deleted]
darnfish 5y ago
Reminds me a little of https://github.com/calderajs/caldera-react https://github.com/calderajs/caldera-react
- floodfx 5y ago
  Cool. LiveViewJS (and Phoenix LiveView) renders the initial HTML over HTTP but then connect to the server via a persistent web socket connection. Client events (clicks, form updates, blur/focus events, key events, etc) are then sent over the socket which kicks off a server-side state updates and rendering with only the diffs sent back over the web socket. These diffs are then merged with the existing dom. (Maybe TMI here but wanted to be clear this isn't just server-side rendering over HTTP.)
  - forgotmyoldacc 5y ago
    It sounds like you're describing the same thing: https://github.com/calderajs/caldera-react https://github.com/calderajs/caldera-react > Think of it as the Node.js analog to Phoenix LiveView — all of the application logic (including rendering) runs on the server, and DOM updates are sent to the client in real-time.
    - floodfx 5y ago
      Gotcha. I read the README and it wasn't clear to me that this is how Caldera works. Sorry about that. I'll add that the API for implementing components in LiveViewJS follows the Phoenix API (mount => handleParams => handleEvent => render) rather than the React API.
- justinmcp 5y ago
  I made (no longer working on it); https://github.com/justinmcp/taper https://github.com/justinmcp/taper, which is essentially, react + "redux on server" - so still rendering on client, but logic in server. It's definitely an interesting space to explore, I will take a look @ caldera, seems like an interesting project!
prophesi 5y ago
This is really cool! So basically instead of using LiveEEX templates, you can write it like a SPA with Typescript?
- floodfx 5y ago
  Yes but more than that you don't write any Elixir / Phoenix code. Check out the examples in the repo to see some code.
hartator 5y ago
Any live demos to play with? Good work.
- floodfx 5y ago
  Hey hartator. I don't have deployed but there is a `npm run examples` that starts up a local server with nine different examples of various complexity (code in `src/examples`). Also there is a separate repo using LiveViewJS to implement a TodoMVC application - https://github.com/floodfx/todomvc-liveviewjs https://github.com/floodfx/todomvc-liveviewjs.
searchableguy 5y ago
How is the performance and scaling story compared to live view? Live view works so well because of elixir and BEAM. The same model may not translate well to other languages depending on their concurrency and recovery pattern. There are also many optimizations in BEAM for keeping latency consistent over throughout alone which is important for live view applications. I also wonder if it will be possible to have push only live view application. One of the reasons for this is you can use server events instead of sockets. It would be cool for building visualization or showing metrics from backend. Awesome job all around. I love the examples folder.
- floodfx 5y ago
  Thanks for checking it out searchableguy. Tbh, I haven't run any performance/scaling tests just yet. :) I certainly don't expect it to be as performant or scale as well as BEAM right now and agree with your point that BEAM is particularly well suited for this paradigm. That said, I think there are other server technologies to back LiveViewJS apps that may be able to scale out and perform just as well as BEAM including: Redis and DynamoDB. I plan to experiment with these in the near future. Additionally, a big motivation for me was that I wanted to write apps in a language that I am very productive in (namely Typescript) which also has a large ecosystem and larger population of developers. Lastly, in terms of other languages that I think could be well suited for this paradigm, Golang stands out (with channels and goroutines) but I haven't experimented with that yet.
  - mrkurt 5y ago
    It's going to be hard to get close to BEAMs scaling story. I think you could build something on top of, like, nats.io and get similar scaling semantics. But centralized DBs are brittle for this kind of platform. Redis and DynamoDB are great ... just not for this. This is extreme and maybe true. The best way to make TypeScript scale like BEAM might be to build a TypeScript -> Beam compiler. :D
    - floodfx 5y ago
      Agree that BEAM is great and very scalable. I guess I disagree with the notion that Redis and DynamoDB are "centralized" and "brittle". Rather both are distributed, robust, and, I would add, battle-tested. I do like the idea of a Typescript to BEAM compiler but that is beyond my capabilities and interests. Maybe someone lurking here could do that?
tbranyen 5y ago
Hi floodfx, we should chat at some point if you're on slack/discord/etc. I'm building something extremely similar and there's potential opportunity to share some code/learnings. Personally I feel this design paradigm is the real web 3.0. My project is https://diffhtml.org/ https://diffhtml.org/ and I have started experimenting with middleware to bridge to server and client workers: https://github.com/tbranyen/diffhtml/pull/251 https://github.com/tbranyen/diffhtml/pull/251. For the server worker, it uses a WebSocket to ferry the VDOM diff patches, custom events, and property access/function calls. A big goal is to allow synchronous "main thread" access from workers, including on the server-side. This would allow you to write your UI code as if you were a client side app. It does this the same way as partytown using a SharedArrayBuffer and Atomics. You can see demo source code here: https://gist.github.com/tbranyen/2f5be81cfb7b3aa1bb443c8ef13f43a4 https://gist.github.com/tbranyen/2f5be81cfb7b3aa1bb443c8ef13.... I've also toyed around with hot reloading components without the need for a pre-processor like Babel, and the results are hugely promising. Stateful live UI updates from saving a component file to seeing in the browser without all the fuss with complex build steps is liberating. I'm probably a few months out from having a usable beta, but I'm going to follow your project closely. Thanks for sharing!
- floodfx 5y ago
  hey tbranyen - happy to chat. my discord account is same as my handle here. :) Nice work on diffhtml!
- deleted 5y ago
  [deleted]
pawelduda 5y ago
I think the main reason original LiveView is so great is that it fits really well into the Erlang/Elixir/Phoenix ecosystem. Love to see the idea spreading though!
- floodfx 5y ago
  Agreed on both fronts! I think there could be any number of different back-ends for Phoenix apps not just Elixir (Phoenix) and Typescript (LiveViewJS). One insight I had as I was building this is that Phoenix apps are actually based on a wire protocol and if that protocol was well-documented, you could see lots of different implementations across any number of languages. Would love to chat with Phoenix folks about that if interested...
sph 5y ago
Javascript is like Ice 9, it turns everything it touches into Ice 9. LiveView was invented not to have to deal with Javascript-powered SPA architectures and client-side coding in general, because JS is ass, and here's LiveViewJS to convert to Javascript a technology invented not to deal with Javascript. Gary Bernhardt warned us, yet no one listened. shakes fist at cloud https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- spondyl 5y ago
  For anyone curious about Ice 9: https://en.wikipedia.org/wiki/Cat%27s_Cradle https://en.wikipedia.org/wiki/Cat%27s_Cradle > Ice-nine is an alternative structure of water that is solid at room temperature and acts as a seed crystal upon contact with ordinary liquid water, causing that liquid water to instantly transform into more ice-nine. A substance called ice-9, with basically the same properties, makes a passing appearance in the visual novel Zero Escape: Nine Hours, Nine Persons, Nine Doors if you haven't heard of the book but remember the term from somewhere else. Admittedly, that's where I first learned about it but that said, there is a real substance called Ice IX but it isn't as interesting https://en.wikipedia.org/wiki/Ice_IX https://en.wikipedia.org/wiki/Ice_IX
- floodfx 5y ago
  I can see you are angry and don't like JS. Perhaps you might be less angry if you look at the project and see that it is not an SPA architecture nor does it require or encourage client-side coding in general? Maybe instead of shaking your fist, you might just celebrate the fact that we live in amazing times where even JS programmers can enjoy the LiveView programming paradigm! :)
  - spion 5y ago
    I'm a mostly-JS engineer for 12+ years. JS sucks and could learn a lot from ecosystems like Elixir (and Rust). We should fix the suck first.
  - fouc 5y ago
    I'm not sure that comparing JS to a potentially catastrophic substance with the capability to destroy all life on Earth implies that OP is angry about JS. It could be a tongue-in-cheek comparison.
interactivecode 5y ago
I always thought the react programming model could solve most criticisms perfectly with a built in liveview style server part
flessner 5y ago
I tried Phoenix LiveView recently and it feels really refreshing. In comparison to Svelte (my preferred tool usually) it feels oddly similar like it occupies the same idea with a completely different execution. I personally prefer JS over Elixir and having everything in one language also makes everything easier... maybe there is also a future to fuse some of these concepts into Svelte (I will have to experiment :D )
- floodfx 5y ago
  Hi flessner - I am a big Svelte fan myself! (And prefer JS/TS over Elixir.) Would love to see what you come up with in terms of fusing LiveViewJS / Svelte concepts. LMK if I can be helpful.
- pablodavila 5y ago
  I want to use Elixir more for my side projects but it's honestly really easy to get going with services like Vercel or Netlify and SvelteKit. Also coming from Next.js and SvelteKit, I got kind of used to the file-based routing and it creates some friction for me when trying to use Phoenix. I want to contribute some sort of guide to the community for people coming from JS metaframeworks, rather than Rails/MVC frameworks, but I feel like I need to use Phoenix more first. I'm just about finished with Sophie and Bruce's book!
  - floodfx 5y ago
    I'd highly recommend Pragmatic Studio's Phoenix LiveView Course - https://pragmaticstudio.com/phoenix-liveview https://pragmaticstudio.com/phoenix-liveview I wrote LiveViewJS while taking this course believe it or not.
lucis 5y ago
I appreciate projects like this, as LiveView brings some amazing solutions to the game, but I'd guess that even if it was "feature-complete", I would still miss the so many great stuff about the BEAM/Elixir. Although, the safety of Typescript is the only thing that stops me from building my next hobbie/side-project with Elixir. After you get the benefits from the type system (specially in the TS ecosystem), it's hard to go back. Looking forward to see where the project goes!
- floodfx 5y ago
  Sounds like you've got some pretty good experience with both Typescript and Elixir. LiveViewJS could definitely benefit from that type of experience if you'd be interested in helping? I am definitely not an Elixir / Phoenix expert.
xtlc 5y ago
There is htmx: www.htmx.org. maybe also a good source for ideas.
deleted 5y ago
[deleted]
aloukissas 5y ago
Elixir and TS fan here: curious, what would be the use for this, aside of what looks like a very interesting project? The main strength of LV is that is sits on top of the BEAM and OTP which makes it very suitable to scale predictably. Other frameworks have tried to do that (Hotwire or something for Rails iirc), but they lack the benefits of the BEAM. Epic job though!
- floodfx 5y ago
  Hey thanks aloukissas! > what would be the use for this Ideally, to write LiveView applications in Typescript. :) This is early in development but as I mentioned above I think there are server technologies like DynamoDB and Redis that I plan to explore for scalable data stores.
deleted 5y ago
[deleted]

146 points by floodfx 5y ago

benburton 5y ago

Looked interesting. Thought I would take a deep dive. README references a video behind a subscription paywall? I'm out.

floodfx 5y ago
> (This video by Pragmatic Studio does an amazing job of explaining how LiveView works.) I believe you are referencing this line from the README? FWIW - they have a free "starter course" which includes that video. I started on the free course and upgraded because I got a ton of value out of it and they are a small company doing great work. To be clear, LiveViewJS has no affiliation with Pragmatic Studio. I am just a fan. :)

deleted 5y ago

[deleted]

darnfish 5y ago

Reminds me a little of https://github.com/calderajs/caldera-react https://github.com/calderajs/caldera-react

floodfx 5y ago
Cool. LiveViewJS (and Phoenix LiveView) renders the initial HTML over HTTP but then connect to the server via a persistent web socket connection. Client events (clicks, form updates, blur/focus events, key events, etc) are then sent over the socket which kicks off a server-side state updates and rendering with only the diffs sent back over the web socket. These diffs are then merged with the existing dom. (Maybe TMI here but wanted to be clear this isn't just server-side rendering over HTTP.)
- forgotmyoldacc 5y ago
  It sounds like you're describing the same thing: https://github.com/calderajs/caldera-react https://github.com/calderajs/caldera-react > Think of it as the Node.js analog to Phoenix LiveView — all of the application logic (including rendering) runs on the server, and DOM updates are sent to the client in real-time.
  - floodfx 5y ago
    Gotcha. I read the README and it wasn't clear to me that this is how Caldera works. Sorry about that. I'll add that the API for implementing components in LiveViewJS follows the Phoenix API (mount => handleParams => handleEvent => render) rather than the React API.
justinmcp 5y ago
I made (no longer working on it); https://github.com/justinmcp/taper https://github.com/justinmcp/taper, which is essentially, react + "redux on server" - so still rendering on client, but logic in server. It's definitely an interesting space to explore, I will take a look @ caldera, seems like an interesting project!

prophesi 5y ago

This is really cool! So basically instead of using LiveEEX templates, you can write it like a SPA with Typescript?

floodfx 5y ago
Yes but more than that you don't write any Elixir / Phoenix code. Check out the examples in the repo to see some code.

hartator 5y ago

Any live demos to play with? Good work.

floodfx 5y ago
Hey hartator. I don't have deployed but there is a `npm run examples` that starts up a local server with nine different examples of various complexity (code in `src/examples`). Also there is a separate repo using LiveViewJS to implement a TodoMVC application - https://github.com/floodfx/todomvc-liveviewjs https://github.com/floodfx/todomvc-liveviewjs.

searchableguy 5y ago

How is the performance and scaling story compared to live view? Live view works so well because of elixir and BEAM. The same model may not translate well to other languages depending on their concurrency and recovery pattern. There are also many optimizations in BEAM for keeping latency consistent over throughout alone which is important for live view applications. I also wonder if it will be possible to have push only live view application. One of the reasons for this is you can use server events instead of sockets. It would be cool for building visualization or showing metrics from backend. Awesome job all around. I love the examples folder.

floodfx 5y ago
Thanks for checking it out searchableguy. Tbh, I haven't run any performance/scaling tests just yet. :) I certainly don't expect it to be as performant or scale as well as BEAM right now and agree with your point that BEAM is particularly well suited for this paradigm. That said, I think there are other server technologies to back LiveViewJS apps that may be able to scale out and perform just as well as BEAM including: Redis and DynamoDB. I plan to experiment with these in the near future. Additionally, a big motivation for me was that I wanted to write apps in a language that I am very productive in (namely Typescript) which also has a large ecosystem and larger population of developers. Lastly, in terms of other languages that I think could be well suited for this paradigm, Golang stands out (with channels and goroutines) but I haven't experimented with that yet.
- mrkurt 5y ago
  It's going to be hard to get close to BEAMs scaling story. I think you could build something on top of, like, nats.io and get similar scaling semantics. But centralized DBs are brittle for this kind of platform. Redis and DynamoDB are great ... just not for this. This is extreme and maybe true. The best way to make TypeScript scale like BEAM might be to build a TypeScript -> Beam compiler. :D
  - floodfx 5y ago
    Agree that BEAM is great and very scalable. I guess I disagree with the notion that Redis and DynamoDB are "centralized" and "brittle". Rather both are distributed, robust, and, I would add, battle-tested. I do like the idea of a Typescript to BEAM compiler but that is beyond my capabilities and interests. Maybe someone lurking here could do that?

tbranyen 5y ago

Hi floodfx, we should chat at some point if you're on slack/discord/etc. I'm building something extremely similar and there's potential opportunity to share some code/learnings. Personally I feel this design paradigm is the real web 3.0. My project is https://diffhtml.org/ https://diffhtml.org/ and I have started experimenting with middleware to bridge to server and client workers: https://github.com/tbranyen/diffhtml/pull/251 https://github.com/tbranyen/diffhtml/pull/251. For the server worker, it uses a WebSocket to ferry the VDOM diff patches, custom events, and property access/function calls. A big goal is to allow synchronous "main thread" access from workers, including on the server-side. This would allow you to write your UI code as if you were a client side app. It does this the same way as partytown using a SharedArrayBuffer and Atomics. You can see demo source code here: https://gist.github.com/tbranyen/2f5be81cfb7b3aa1bb443c8ef13f43a4 https://gist.github.com/tbranyen/2f5be81cfb7b3aa1bb443c8ef13.... I've also toyed around with hot reloading components without the need for a pre-processor like Babel, and the results are hugely promising. Stateful live UI updates from saving a component file to seeing in the browser without all the fuss with complex build steps is liberating. I'm probably a few months out from having a usable beta, but I'm going to follow your project closely. Thanks for sharing!

floodfx 5y ago
hey tbranyen - happy to chat. my discord account is same as my handle here. :) Nice work on diffhtml!
deleted 5y ago
[deleted]

pawelduda 5y ago

I think the main reason original LiveView is so great is that it fits really well into the Erlang/Elixir/Phoenix ecosystem. Love to see the idea spreading though!

floodfx 5y ago
Agreed on both fronts! I think there could be any number of different back-ends for Phoenix apps not just Elixir (Phoenix) and Typescript (LiveViewJS). One insight I had as I was building this is that Phoenix apps are actually based on a wire protocol and if that protocol was well-documented, you could see lots of different implementations across any number of languages. Would love to chat with Phoenix folks about that if interested...

sph 5y ago

Javascript is like Ice 9, it turns everything it touches into Ice 9. LiveView was invented not to have to deal with Javascript-powered SPA architectures and client-side coding in general, because JS is ass, and here's LiveViewJS to convert to Javascript a technology invented not to deal with Javascript. Gary Bernhardt warned us, yet no one listened. shakes fist at cloud https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

spondyl 5y ago
For anyone curious about Ice 9: https://en.wikipedia.org/wiki/Cat%27s_Cradle https://en.wikipedia.org/wiki/Cat%27s_Cradle > Ice-nine is an alternative structure of water that is solid at room temperature and acts as a seed crystal upon contact with ordinary liquid water, causing that liquid water to instantly transform into more ice-nine. A substance called ice-9, with basically the same properties, makes a passing appearance in the visual novel Zero Escape: Nine Hours, Nine Persons, Nine Doors if you haven't heard of the book but remember the term from somewhere else. Admittedly, that's where I first learned about it but that said, there is a real substance called Ice IX but it isn't as interesting https://en.wikipedia.org/wiki/Ice_IX https://en.wikipedia.org/wiki/Ice_IX
floodfx 5y ago
I can see you are angry and don't like JS. Perhaps you might be less angry if you look at the project and see that it is not an SPA architecture nor does it require or encourage client-side coding in general? Maybe instead of shaking your fist, you might just celebrate the fact that we live in amazing times where even JS programmers can enjoy the LiveView programming paradigm! :)
- spion 5y ago
  I'm a mostly-JS engineer for 12+ years. JS sucks and could learn a lot from ecosystems like Elixir (and Rust). We should fix the suck first.
- fouc 5y ago
  I'm not sure that comparing JS to a potentially catastrophic substance with the capability to destroy all life on Earth implies that OP is angry about JS. It could be a tongue-in-cheek comparison.

interactivecode 5y ago

I always thought the react programming model could solve most criticisms perfectly with a built in liveview style server part

flessner 5y ago

I tried Phoenix LiveView recently and it feels really refreshing. In comparison to Svelte (my preferred tool usually) it feels oddly similar like it occupies the same idea with a completely different execution. I personally prefer JS over Elixir and having everything in one language also makes everything easier... maybe there is also a future to fuse some of these concepts into Svelte (I will have to experiment :D )

floodfx 5y ago
Hi flessner - I am a big Svelte fan myself! (And prefer JS/TS over Elixir.) Would love to see what you come up with in terms of fusing LiveViewJS / Svelte concepts. LMK if I can be helpful.
pablodavila 5y ago
I want to use Elixir more for my side projects but it's honestly really easy to get going with services like Vercel or Netlify and SvelteKit. Also coming from Next.js and SvelteKit, I got kind of used to the file-based routing and it creates some friction for me when trying to use Phoenix. I want to contribute some sort of guide to the community for people coming from JS metaframeworks, rather than Rails/MVC frameworks, but I feel like I need to use Phoenix more first. I'm just about finished with Sophie and Bruce's book!
- floodfx 5y ago
  I'd highly recommend Pragmatic Studio's Phoenix LiveView Course - https://pragmaticstudio.com/phoenix-liveview https://pragmaticstudio.com/phoenix-liveview I wrote LiveViewJS while taking this course believe it or not.

lucis 5y ago

I appreciate projects like this, as LiveView brings some amazing solutions to the game, but I'd guess that even if it was "feature-complete", I would still miss the so many great stuff about the BEAM/Elixir. Although, the safety of Typescript is the only thing that stops me from building my next hobbie/side-project with Elixir. After you get the benefits from the type system (specially in the TS ecosystem), it's hard to go back. Looking forward to see where the project goes!

floodfx 5y ago
Sounds like you've got some pretty good experience with both Typescript and Elixir. LiveViewJS could definitely benefit from that type of experience if you'd be interested in helping? I am definitely not an Elixir / Phoenix expert.

xtlc 5y ago

There is htmx: www.htmx.org. maybe also a good source for ideas.

deleted 5y ago

[deleted]

aloukissas 5y ago

Elixir and TS fan here: curious, what would be the use for this, aside of what looks like a very interesting project? The main strength of LV is that is sits on top of the BEAM and OTP which makes it very suitable to scale predictably. Other frameworks have tried to do that (Hotwire or something for Rails iirc), but they lack the benefits of the BEAM. Epic job though!

floodfx 5y ago
Hey thanks aloukissas! > what would be the use for this Ideally, to write LiveView applications in Typescript. :) This is early in development but as I mentioned above I think there are server technologies like DynamoDB and Redis that I plan to explore for scalable data stores.

deleted 5y ago

[deleted]