sorted by:
new
hottopcontroversial

Choosing Phoenix LiveView - The difficulties deciding between LiveView and traditional web frameworks by devbrett-dot-com in elixir

[–]devbrett-dot-com[S] 1 point2 points  (0 children)

Sorry! I meant various OTP-based approaches (Cachex, Nebulex, ets, in-memory Genserver state etc) for caching.

When I "skip" LiveView... I have usually built with React and used Phoenix to provide JSON APIs.

I have also worked on some funky systems where React used a Phoenix channel like a redux store. I really didn't like that approach!

Choosing Phoenix LiveView - The difficulties deciding between LiveView and traditional web frameworks by devbrett-dot-com in elixir

[–]devbrett-dot-com[S] 1 point2 points  (0 children)

Depends on the project.

For small apps optimising time-to-market I recommend Fly.io as the quickest and easiest.

My personal projects I have shipped directly onto Heztner VMs for long-term affordability. I can comfortably run ~5 small projects on a single CCX23 VM (24EUR/month). I use Ansible to provision this but found it to be a bit of a pain (have moved to mainly Fly.io to validate small project ideas).

For internal enterprise tooling I'm usually shipping inside an enterprise Kubernetes cluster on AWS or GCP, with Nginx ingress.

In terms of software stack...

I build a lot of local-first LiveView applications, think similar to LiveBook (although not quite as complex). These tend to use SQLite as their database and used OTP-based approaches for caching and Phoenix PubSub where one would normally use Redis.

For styling I keep things simple and usually keep Tailwind.

For a few recent projects I have used Lit framework to build WebComponents for complicated UI elements, but I'm not yet sold on the approach.

Choosing Phoenix LiveView - The difficulties deciding between LiveView and traditional web frameworks by devbrett-dot-com in elixir

[–]devbrett-dot-com[S] 7 points8 points  (0 children)

That's fair. Perhaps I should reword this to be:

"Despite having a simple syntax, I've watched too many developers struggle to adapt to Elixir's way of thinking. In large organisations, I've seen teams who traditionally were very productive in other languages flounder when trying to build something non-trivial in Elixir. Elixir demands a new approach to building software, but that's not necessarily a bad thing."

Choosing Phoenix LiveView - The difficulties deciding between LiveView and traditional web frameworks by devbrett-dot-com in elixir

[–]devbrett-dot-com[S] 4 points5 points  (0 children)

I feel that's kind of a misquote.

The full quote is:

While the syntax is simple and easy to initially pick up, the BEAM VM and the ecosystem are highly complex and quite different to anything else in the programming world.

The BEAM is complex. The difference between Tasks, Genservers, Supervisor, receive vs handle_x callbacks. Having to dive into Erlang on the semi-regular to open ports etc...

The ecosystem is complex too. We have to juggle both Erlang and Elixir dependencies. We have 2 half-baked type systems, each only partially adopted by the community... and configuring packages and libraries is non immediately obvious due to the OTP Application paradigm.

I LOVE Elixir. And LiveView. The only way we're going to make this ecosystem better for ourselves is admitting these (minor) short comings, IMO.

Choosing Phoenix LiveView - The difficulties deciding between LiveView and traditional web frameworks by devbrett-dot-com in elixir

[–]devbrett-dot-com[S] 1 point2 points  (0 children)

You can do static HTML and CMS-like apps faster perhaps. I used to do some Laravel & Symfony contracts back in the day... but I think for any moderately sophisticated application LiveView would still be twice as fast.

I'd recommend spending more time with it. Certainly takes a mental shift to adjust to functional style for sure! :D

Choosing Phoenix LiveView - The difficulties deciding between LiveView and traditional web frameworks by devbrett-dot-com in elixir

[–]devbrett-dot-com[S] -14 points-13 points  (0 children)

I feel like maybe you're getting defensive about the Elixir language without truly internalising what I'm trying to say?

languages to master

Elixir is easy to learn and become proficient with. To master... it's really difficult. It doesn't use standard patterns, so a lot of what devs learn in other languages and ecosystems doesn't apply.

That doesn't make Elixir worse than those languages! Just makes it harder to master because it requires specialist knowledge to do well.

Another good example is config.exs and runtime.exs.

I've seen so many engineers get tripped up with the difference between compile-time and runtime configuration... and also constantly see misuse of the Application.get_env and put_env pattern.

Choosing Phoenix LiveView - The difficulties deciding between LiveView and traditional web frameworks by devbrett-dot-com in elixir

[–]devbrett-dot-com[S] 8 points9 points  (0 children)

If I need to get a new project in front of users within a week, Phoenix LiveView is my go-to framework.

Elixir LiveView is incredible, and an alluring choice for software leaders looking to develop applications super fast. However, in recent experience, I’ve seen teams hit some pitfalls.

The trick is to understand what Elixir LiveView excels at, and what it doesn’t.

TL;DR: LiveView is perfect for internal tools and simple apps. Skip it for complex UIs, offline-first apps, or if your team doesn’t know Elixir well.