Show HN: LiveViewJS – TypeScript back end for LiveView Apps (Phoenix LiveView) | Hacker News Reader

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

github.com

146 pointsfloodfx43 comments

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!

Open articleView on HN

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...

For anyone curious about Ice 9: 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

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! :)

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.

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.

Well they did say "JS is ass". Happy to give them them the benefit of the doubt but I appreciate more obvious supportive commentary.

I am not angry, it was tongue in cheek and an opportunity to share more Gary Bernhardt with the world, but JS is indeed ass.

What a great video.

I used to agree with him but in 2022 we're still using yavascript and it's only getting better.

I have no doubt at some point we will get optional static types and even TypeScript will become obsolete like CoffeScript did.

The difference is that Ice-Nine turns all water into Ice-Nine. Whereas more javascript projects doesn't mean fewer not-javascript projects (except inasmuch as people who like javascript are busy doing javascript things instead of other things).

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.

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.

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

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?

They're not brittle when running -- they're brittle if/when there's a failure.

Bringing a Redis cluster back up is either "start each node in exactly the right order", "wait 10+ minutes", or "establish quorum yourself". Ten minutes can be a really long time in production.

I've been working on a Go implementation if you fancy trying it out

https://github.com/jfyne/live

Very cool. I noticed you are writing your own client libraries? Curious if you've tried using the Phoenix client libraries? LiveViewJS uses the same libraries as a Phoenix LiveView app on the front-end.

I'll join your discord and we can chat more...

I love typescript too. Any plan to support deno?

I think deno may work out of the box with --compat flag but i haven't tried it.

I have not tried Deno and not my highest priority. I've added to the issues in Github. If you try it, would be great to update that issue with your results!

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!

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.

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

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.)

It sounds like you're describing the same thing: 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.

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.

I made (no longer working on it); 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!

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/ and I have started experimenting with middleware to bridge to server and client workers: 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/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!

hey tbranyen - happy to chat. my discord account is same as my handle here. :)

Nice work on diffhtml!

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!

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...

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 )

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.

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!

I'd highly recommend Pragmatic Studio's Phoenix LiveView Course - https://pragmaticstudio.com/phoenix-liveview

I wrote LiveViewJS while taking this course believe it or not.

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!

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.

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

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

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

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

Any live demos to play with? Good work.

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.

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

> (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. :)

Reply on news.ycombinator.com