Notes and annotations for article PETAL: the end-to-end web stack

petal.md

• URL:: https://changelog.com/posts/petal-the-end-to-end-web-stack
• Related
  • [[Thinking Elixir Podcast]] episode: https://podcasts.nu/avsnitt/thinking-elixir-podcast/tailwind-css-alpinejs-and-liveview-with-patrick-thompson-4_Z2xj-ngo
  • [[Chris McCord]] article: https://dockyard.com/blog/2020/12/21/optimizing-user-experience-with-liveview
  • All the links in this article are useful.
• My takeaways
  • With [[elixir]] and [[phoenix]] the floor is low and the ceiling is basically non-existent.
  • I consider [[JavaScript]] to be highly overused as a web technology. Building what amounts to two entirely separate applications that must somehow coordinate state has always seemed insane to me. This is what an [[SPA]] approach is. It's been highly optimized and improved by tools like [[React]], but it still seems like overkill to me.
• [[annotations]]

  • Whatsapp has built with Erlang to great success running an enormous system on a very small crew. With Elixir, we see companies like Discord that are repeating that success.

  • Alpine.js is a JavaScript framework by Caleb Porzio who built Livewire for PHP (inspired by Phoenix LiveView of Elixir fame). It is built to work well when you need strictly client-side interactivity and these live server-side rendering solutions just won’t do. It should give you something more convenient than vanilla JavaScript while mostly staying out of the way. Patrick Thompson covered a lot of LiveView + Alpine.js in his ElixirConf talk. Chris McCord (of Phoenix fame) also covers some of this at DockYard. #Alpine.js

  • since Elixir/Erlang and the BEAM build on the actor model and have powerful facilities for managing in-memory state, events, and message passing… the actual implementation is absolutely outstanding

  • Like most things built by the Elixir and Phoenix teams, it is much better in execution than it has any right to be.

  • building an SPA is too much damn work for a lot of use-cases.

  • Now I like and enjoy Elixir. I also happen to think it is technically superior. That isn’t the most important thing in the world, but it makes me happy. I find it gives me more tools than any other stack I’ve ever worked in. It is a fairly common story that Ruby shops rebuild a system that was performing poorly in Ruby with Elixir and suddenly forget it exists because it never caused trouble again and only required a slice of the previous power to perform at the same pace. In his talk on crawling, Adam Mokan covers some of that ground.

  • Phoenix does your core web server work and basic rendering and forms. LiveView brings your system to the client and provides real-time interactivity for the 80-90% case. Alpine is there for the remaining 10-20% of high-touch interactivity. Tailwind CSS gives you the visual and styling baseline and tools you will need. This should give you all the power you need for a web application UI and all the way back to persisting data to a DB.

  • when your project grows the fun really begins. Because you can grow in this ecosystem like nowhere else

  • I think this stack has the potential to be quite approachable to new learners while not really setting any limits to future growth.

  • A traditional trade-off in high level dynamic languages such as Python, Node.js or Ruby is that you sacrifice performance for developer convenience and quick iteration. Elixir works at the same high level of abstraction but builds on very different fundamentals. The problem of distribution and concurrency is the primary bottleneck where these languages struggle. They generally attempt to tackle it with cooperative multitasking, which requires threading a needle of what kind of work can be done without delaying the time to yielding or you will impact other parts of the system. You can handle many requests in a concurrent non-parallel fashion. You run more instances for parallelism.

  • Elixir won’t beat C++ for performance in number crunching, just like other high-level languages won’t. But it is very well suited to long-running applications, concurrency, state management and distributed computing. And that’s what we do as backend web developers.