Q&A with Chris McCord & José Valim
summary
Phoenix and LiveView roadmap prioritizes concrete fixes: LiveView needs slots for components and a component messaging abstraction before 1.0 to support reusable libraries and inter-component communication; tooling focuses on faster, stable builds (esbuild as a long‑term portable default) and reduced compile‑time overhead caused by implicit imports; presence uses a CRDT merge that can be optimized for speed; community help in docs, small PRs and evangelism grows adoption; the new Elixir tooling work targets editor-aware features; the numbat mascot is for numerical Elixir projects.
AI-written summary · about
chapters (15)
- 0:00Start
- 0:44Where did the Phoenix name come from?
- 2:52Most regrettable decisions so far with Phoenix or Live View?
- 4:30Where did the Elixir name come from?
- 6:33What's missing in Live View for it to be 1.0?
- 9:11How do you prioritize work, open source and your private life?
- 13:17Do you talk with other web framework authors? Who do you draw inspiration from?
- 14:43Machine learning related graphic that was recently shared on Twitter
- 19:40Rails is baking in support for import maps, will Phoenix get something similar?
- 24:45What thing in Elixir and Phoenix is frustrating but isn't a top priority?
- 32:00How do you feel about DSLs around testing?
- 38:56What can the community do to improve the growth of Elixir and Phoenix?
- 42:52Phoenix and Elixir roadmap? What's coming in the next year or so?
- 52:52Top 3 anti-patterns that developers use when working with Phoenix?
- 59:57Biggest improvements you'd like to see in the Phoenix ecosystem? Static types?
related talks
19mUpdate from the Phoenix Team
30mTales of Using Phoenix LiveView at an Early Stage Startup
24mLiveView and Web Components
35mKeynote: Fireside Chat on LiveView, (...)
39mBeyond Liveview: Real Time Features With Liveview
01h 13mKeynote: Phoenix LiveView - Interactive Apps without Javascript
40mThe Power & Performance of Phoenix LiveView
44mWhat's new in LiveView