c13e
Ryan Carniato (creator of SolidJS) holds popular weekly streams where he dives deep into latest advances in frontend frameworks, occasionally with the creator/core team.
This week’s stream was with the creator of LiveViewJS (I know, quite confusing/odd name choice) which is a port of Phoenix Liveview to NodeJS/Deno.
Overall, stream went well and it’s great to see more implementations and awareness of Liveview in general spreading and getting positive reception in different communities.
That said, this being NodeJS, much of the power that makes Phoenix Liveview unique building on top of Phoenix channels and Erlang VM could not be showcased on the stream, which would have addressed questions some folks had around scalability and other misconceptions about maintaining stateful connections.
If any of the LiveView core team are interested in doing a Phoenix-specific stream, feel free to shoot Ryan (https://twitter.com/RyanCarniato) a DM, he did seem open to something like that (@chrismccord gets mentioned toward the end of the pairing session) and he has done streams on frameworks in non-JS languages like Rust before
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
D4no0
People use liveview to avoid having to deal with js …
Sometimes I wonder what is inside of people’s head who are obsessed in implementing all they can in js.
lud
Well JS is quite powerful and that is the language they know, so…
If you accept to work with NodeJS then why not implement all the solutions with it. I mean, there is a strong tradition of doing everything on the BEAM too. One language to rule them out. JS people have the chance that they also have all the frontend stuff included.
D4no0
God forbid you learn a new language or technology, better reinvent the wheel.
dorgan
On one hand it’s nice to see it exist because it feels like the idea is being validated.
On the other hand it’s a bit disappointing because what makes liveview so easy to work with is the beam and OTP, and the author explicitly says “I don’t want to learn Elixir at all” so I don’t know how to feel about it.
Block a liveview in that js version and see what happens.
Cruz
I watched the live interview thinking that Ryan was going to interview Chris. My confusion came from the name Donnie Flood decided to give his library: LiveViewJS. I ended up watching the entire interview. It was interesting and Donnie seems like a really smart and nice guy. I just wish he had given a more distinct name to his library. LiveViewJS is too close to LiveView.JS. It will cause confusion to members of both the Node/JS and Elixir communities.
BartOtten
Not sure how the JS community handles those things or if they even care.
His email address is at his Github profile. Maybe simply ask him to rename the thing?
sodapopcan
@BartOtten Doesn’t look promising: Name conflict · Issue #113 · floodfx/liveviewjs · GitHub
I was very annoyed by the name but also ended up watching the whole interview (well, listened to it) and was actually quite good. The name does make sense in the end since it’s actually using [Phoenix] LiveView’s JS wholesale and he’s aiming to do a 1-for-1 JS implementation of LiveView (only, of course, without BEAM features). I still think the name stinks, though. I also echo sentiments here where it’s great that this shows the idea is receiving validation outside the Elixir community—the interviewer talks in the beginning how he wrote off [Phoenix] LiveView but by the end of the interview ended up coming around to the idea and really dug into it. I think it’s kind of lame when people “just don’t want to learn another language” but at the same time, I get it very much so.
Another take-away from the video is the perception that [Phoenix] LiveView is just about “not writing JS” is much more prolific than I thought. I don’t think [Phoenix] LiveView is not about writing JS at all, it’s about not writing unnecessary JS. As someone who actually enjoys writing JS when it’s called for, I think hooks are done so well, and Chris+co often encourage us to use them. I don’t know quite how to finish this though but ya, I think it’s too bad this stigma proliferated like it did.
Anyway, I highly recommend watching the video, especially the part where the interviewer starts digging into how liveview.js (ie, the file that’s included in our Phoenix projects, not LiveViewJS) works.
derek-zhou
Right on. It is about returning to the root of the original JS, casual scripting with fun and instant gratification.
BartOtten
Guess he didn’t write his reason for closing the issue using TypeScript…
Error: reason is undefined
Classic JS