Seeking Experiences with Phoenix, LiveView, and Elixir for Solo Developers and Small Teams

Phoenix Forum Chat / Discussions
,
1

Hello everyone,

I’m reaching out to gather insights from those who have experience using Phoenix, LiveView, and Elixir, particularly as solo developers, indie hackers, or members of small teams.

Background:

I’ve been developing with React, Nextjs, JavaScript & TypeScript, and Laravel. While these tools are powerful & have good DX, I’ve been experiencing significant JavaScript fatigue. The rapid change and frequent paradigm shifts in the JavaScript ecosystem make it challenging to stay up to date. I often find myself fiddling around with techs instead of building meaningful apps.

What I’m Looking For:

I’m considering transitioning to Elixir with Phoenix and LiveView to enhance my productivity and reduce complexity. The idea of server driven UI and websockets with the erlang vm is appealing. I’m interested in hearing about:

  • Your experiences using this stack in small teams or solo projects.
  • How it has impacted your productivity and development workflow.
  • Any challenges you’ve faced and how you addressed them.
  • Comparisons to other stacks you’ve used in terms of simplicity and efficiency.
  • How it compares to other frameworks like rails laravel & django

Why This Matters:

My goal is to find a technology stack that allows me to concentrate on delivering features and value, rather than managing intricate configurations. The “batteries-included” philosophy of Phoenix and the real-time capabilities of LiveView seem promising.

I would greatly appreciate your insights, experiences, and any resources or advice you can share.

Thank you in advance! :heart:

6 Likes
2

Hi Zeinot,

I’ve mostly been solo/indie over the last 10 years and went all-in on Elixir 6 years ago. A particularity is that I monitor & maintain things long-term. This means that I still maintain Django & Laravel apps that I initially wrote or took-over more than 6 years ago. Elixir is a whole other developer experience. There’s less pre-built stuff, but I’ve found you mostly don’t need it and the library ecosystem is of very high quality.

My switch to Elixir has been invaluable to me. It brought a massive churn reduction and complexity reduction while allowing to think in terms of systems rather than in terms of web apps.

My first production Elixir project was done in anger, in very harsh conditions time-wise with an incompressible political-related deadline, burning midnight oil. It had a few features that heavily relied on Phoenix channels at the time. Today it is still online and the client asks me for new features roughly every 3 weeks.

Despite the initial project done in a rush, without prior Phoenix code organization habits, it has been very easy to maintain it. I was already fully sold on FP before this project but it proved easy to refactor, extend, and change over those 6 years. Sure, I wouldn’t organize things the same way today, but it’s not a big problem either and I do not bump in hardships.

Now I’m going all-in on Liveview too after a decade of mostly Vue. Liveview builds on the peace of mind I’ve found with Elixir and brings that to the UI side. I see it as a kind of server-side Elm and actively try to keep it as pure as possible so it is easy to test and refactor too. I don’t want to reproduce Vue or React in Elixir. Despite that, I have a lot of very interactive views (mostly building collaborative real-time document editors).

One of the best things Liveview brings me is effortless headless rendering, or replayable UIs. Since all my state is pure and independent of Liveview (which is only a transport for events that trigger state updates and rendering mechanism), and my UI state loosely applies Event Sourcing principles, it means I can also script my UIs or develop “bots” that use them without ever connecting to a socket, since the final rendered UI is just a pure projection of a stream of events. So I can build this stream of events from, say, a CLI app, and render it through Liveview afterwards. Just like a web user would do.

My livelihood comes from Elixir now, so virtually all my money is where my mouth is :slight_smile: .

10 Likes
3

I would consider building the front-end in React and back-end in Elixir in your place.

Elixir/Erlang is excellent at building back-ends or things like APIs, proxies etc., because it’s excellent at I/O. And much of the back-end code is I/O - talking to database, waiting/receiving the data from user/database/external sources, manipulating it and streaming back to the client.

Channels work really good, if you like GraphQL there’s Absinthe, you can build Swagger/REST APIs and marry it very nicely with SWR and/or other API clients.

You will know a big chunk of your stack already, and can introduce Elixir in a limited scope, in a way that will also let you replace it if you decide this is actually not your favourite environment.

I found that going “full stack Elixir” can be hard on developers. There’s a lot of new things to learn, a lot of them are/were moving very fast, and are different to what you know. Ecto is excellent, for example, but it’s different to any ORM you may have worked with. LiveView is also different and translating concepts from React to it may be a misleading approach and one that will likely result in problems, because it simply works differently.

Once you master Elixir back-end and want to try doing more you always can on this or another project, but my advice is do not go all in at first, take small steps.

9 Likes
4

I cannot agree more. A progressive transition to full stack elixir allows to acclimate to the VM and language step by step.

3 Likes
5

While I don’t have experience on being self-employed as @Lucassifoni , I have worked most of my career in very small companies where I was mostly solo developing from prototypes to full-fledged business solutions, some that were across 3+ technological stacks.

When it comes to your classical stack, such as a web interface + a database for data storage, I don’t think there are any solutions that can beat phoenix and ecto, be it for MVPs or for very big projects (I can attest as I had the luck to work on one of the biggest phoenix project). If we are to compare with rails, which phoenix was heavily inspired from, it has all the positive aspects when it comes to productivity without the more obscure drawbacks that are part of ruby, that start to creep in slowly when your project starts to grow. Generally speaking I think that immutability, lack of classes and fault-tolerance are the secret behind the success of phoenix and elixir itself and it’s something that cannot be replicated by other frameworks that lack these features.

As for liveview, I can say without thinking twice that this is the goto technology for small companies and solo developers, but… you need to understand its limitations and that it’s not a good fit for every project. I have refactored personally some projects that were built in angular+elixir (http api) and I can say that afterwards we could deliver new features 5x faster with less developers, and overall folk was much happier as the project became much simpler to manage and deploy. Notably all the liveview projects I’ve worked with were oriented to business folk that doesn’t care about shiny UI and animations. This is an important factor to keep in mind and if you need a frontend that relies on a lot of logic (let’s say you want a image editor in a browser) then liveview is a terrible choice and you will have a horrible time with it.

If we speak about challenges, @hubertlepicki has very good points. If you are coming from the world of classes and mutability, you will need to invest time to rewire your brain, there is simply no other way around it if you want to get good results out of phoenix and elixir. As someone who is active on this forum, there are countless people that come here and demand features from their favorite ecosystems, those features in most cases are not needed or expressed differently, so keep this in mind when you are frustrated that something doesn’t work as you expect.

7 Likes
6

I also think the transition to “full stack elixir” is not necessarily the goal here. The goal is to build excellent software I guess, that makes money.

React is really good. It may be the best tool for the job depending on the use case.

1 Like
7

That is the usual story of the rewrites. I did my share of rewrites, and I actually think they’re useful but their main advantage is that you start clean, with clear business requirements that do not change during the development and you can avoid the issues and errors the previous team or maybe even yourself made during the original project development.

4 Likes
8

That was not the case. One of the rewrite was done to a never released prototype that didn’t have any new requirements while it was developed. The main slowdown points were coming from the fact that it took a huge amount of time to come with correct API contracts and maintain them and also from the division between developers that were strictly doing frontend and backend, it’s hard to synchronize development of features as the amount of time it takes to ship them can vary drastically. While such concerns are trivial for medium to big companies, for a small company having that edge of efficiency can mean the difference between a successful project and a failed one.

I would beg to differ. No matter how good react is these days, the fact that you use a 2 stack setup involves a big amount of complexity when it comes both to development and deployment, that becomes a very valid concern if you are solo. If your project is fit for liveview, there is simply no world where a 2 stack setup beats it in terms of productivity.

4 Likes
9

That’s likely true, if you know LiveView and your app is not doing anything that would require too crazy with JavaScript/WASM as it can get hairy if it does.

There’s another consideration these days. Remember years ago, when I was building mostly in Ruby, we were building API at the same time as we were building controllers. If you’re building an app that separates client side and server side, you are building an API.

That API may be private at first just for the JS to use, but it can be useful in the future. This was quite rarely the case up until recently in my experience.

I am currently doing a 2nd round of “let’s expose our app to ChatGPT”, as in 2nd app. First try was meh, as the app didn’t have the API. We’re building now a MCP server for the client that exposes the API to Claude (no ChatGPT support yet but hoping it’ll change in months if not weeks), and it’s super sweet. Basically we have the API (GraphQL in this case) and we’re exposing it as tools and resources via MCP and the end result hopefully will be that our users can hook up their LLMs to the app and 100% of the app functionality will be available this way.

I think everyone who decided to separate UI from API will be doing something similar if they see the value in giving agents/llms access to their app.

3 Likes
10

The truth at hand is that this is most of the web apps on internet. One of the drawbacks that still need to be addressed about liveview is accessibility when it comes to slow connections or what we call optimistic UI, but this is a really complex problem that even big corporations struggle with, so it will take some time to get it right.

You never over-optimize for potential future use-cases, only if that is mandatory, hence why you should decide from day 1 if liveview is a good fit or not. It’s not smart to pay a constant penalty in the initial phase of the project, which is the most vulnerable one, just because something might be useful in the future. To add more to this, if you designed your project correctly and separated the concerns, adding the API is as simple as creating the controllers where you plug your already existing functions.

3 Likes
11

I recently made a similar move for most of the reasons you mentioned. I was previously working with nodejs and svelte over websockets.

I find the idea of LiveView really compelling and I think it’s impressive as a technology. Ultimately, I found that I wasn’t able to create the UX that I was looking for mainly around optimistic UI and navigating instantly. I made a proof of concept for optimistic UI but it felt clunky. If your apps are relatively simple and are shuttling data from forms to the backend then LiveView works nicely. Anything more akin to a true web app will require lots of work with JS hooks and JS commands to get a more interactive experience and avoid latency. As an aside, JS hooks need some DX love — I think the coming colocated hooks will help considerably here. So you’ll likely still be writing JS but without the conveniences you’re probably used to and you’ll also need to be aware of how they potentially interact with the state managed by the LiveView cycle.

In terms of productivity, there will be a learning curve. Some things will feel very familiar others quite foreign. But if you were writing mostly functional-style with js (not OOP) then a lot of things will click. If you like tailwind, then you’ll feel at home with css otherwise you’ll be fighting the defaults, though imo Phoenix should make tailwind opt-in rather than opt-out. To help accelerate UI components, I’d recommend checking out salad ui.

For now I’m pursuing Phoenix channels on the backend and SvelteKit SPA on the frontend. Though I think the addition of a few features in LiveView would make me reconsider in the future — namely, prefetching and a robust solution for true optimistic ui. I also have my eye on Hologram which I think could be an amazing DX without sacrificing UX but it’s not quite ready for prime time.

4 Likes
12

thanks a lot for the insights it’s really interesting to read :heart:

13

thanks for the insights

14

I have been learning a lot about LiveView, and to be honest, it is very easy to understand and integrate with my other UI components. I use Flowbite Pro and Tailwind Plus to speed up my UI work, and I found it pretty easy to integrate them with LiveView, thanks to JavaScript interop with hooks and similar features.

React is definitely more popular, and I’m a lot more comfortable using it because I already know it very well compared to LiveView. But I feel like the sooner I start learning and using LiveView, the better I’ll get at it.

I found liveview very intuitive mainly because it’s really similar to react and vue

The whole selling point that got me to want to pick up phoenix is the server driven UI approach, when i saw that demo by Chris McCord it blew my mind. I do find it really interesting the amount of free stuff you get from having a bidirectional line of communication between server & client instead of the typical rest approach

1 Like
15

thanks a lot

16

i don’t mind functional programming, i do find it very interesting; i found it to be very confusing the first time when i stumbled on the fact that in js arrays and objs and functions are references … a = b; if you change b and it’s an array or obj than a will change… i found that to be sooo confusing that it’s a default behavior… it shouldn’t be a default behavior, the mental modal of everything is immutable makes more sens to me, if i want something to change i’ll just reassign
i wish js had the pipe operator |>

1 Like
17

In my case it is the full stack aspect that makes me really interested

18

i agree

19

Here’s the thing: indeed most of my apps are essentially just forms, tables, and cards, plus some decent-looking marketing pages. Honestly, I could probably build all of them using a pure MVC framework without any frontend JavaScript or even something like HTMX, and they’d still work just fine.

That said, I do use React and similar tools because they make the user experience smoother, things like avoiding page refreshes or keeping scroll position really do add polish. My requirements are pretty simple overall, I’m a solo/indie developer, so I try to keep things as straightforward as possible.

20

c++, c#, java etc. share the same behavior when it comes to references to classes. For c++, this feature makes sense, as you are doing manual memory management, for other languages, this is an optimization that leaked into the application space, in reality it should have stayed at compiler/interpreter level.

I’ve trained newcomers coming to our industry and they also mentioned the exactly same thing. For people like me, that came from OOP languages like java/c#, it was a harder transition, as you need to shift the mentality at first to think in terms of data transformation, not sending commands to the computer.

1 Like