Creator of Phoenix here. I was delightfully surprised to see Phoenix as most loved on the survey since I forgot SO survey was a thing this year. So we can rule out some coordinated voting effort. Truthfully, while we’re still a smaller community, the folks that find us tend to love us and stick around.

Thanks Chris.

Phoenix revitalized my interest in programming at a time when I was so frustrated by the state of things that I was ready to change careers.

On year 3 of a startup I cofounded in 2019. A lot of our success dealing with scaling and reliability for our users come directly from how well designed phoenix is. Channels and OTP power some of our killer features and I wouldn't envy someone trying to replicate what we have with javascript or go.

Some people say ecto is limited. I love that it lets sql be sql. It lets me think of the solution in sql and write that sql almost directly in elixir with better ergonomics (being able to make a subquery a separate variable that I join into is a HUGE improvement over raw sql). Those uses of fragment can easily just be turned into macros that integrate cleanly into ecto when I use them enough.

Thanks for one of the best developer experiences I ever worked with. when I have a side project, I'll be trying fly.io and I've already recommended it to other founders. We be using it if it was at its current state in 2020.

I've been using it for almost 6 years and I've found that the dev experience is fantastic and improving. That's why I stuck with it even after winding down the startup that pushed me to learn Elixir.

For 95% of web apps, I'd say Phoenix is the best option these days. It just solves a whole class of problems that send users of RoR and JS frameworks reaching for Redis, Sidekiq, etc. It's also great in terms of debuggability, which I'm now seeing in a project I've taken over that has immense technical debt.

As far as community buzz, I'd say it's been a slow, gradual growth. There have been more books, conferences and podcasts than I'd have expected for the size of the community, but it's still a fairly young and niche language.

The biggest weakness is lack of 3rd-party support. E.g., Stripe documentation will leave you hanging if you don't use a language they've written a client for: https://stripe.com/docs/payments/checkout/fulfill-orders

What are you doing to handle replication among nodes? There's still a great reason to reach for Redis for caching and messaging despite using Elixir: when the Application crashes, the state is gone.

As for Stripe, some client developers have been code-generating their client with mixed success. ExAws, however, is essential.

replication is built in to mnesia and your "app" crashing really shouldn't be taking down the entire OTP on your local machine, so ETS would persist on a single node

When you’re running in a highly-distributed environment, your instances can go away for reasons other than OTP crashing – say, you’re being rescheduled onto a new node. Am I missing context here?

That's not a risk unique to Erlang or Mnesia. There's all sorts of reasons nodes may fail, some where data persisted on that node is temporarily unavailable (network, power, cabling, OS/application fault, etc), some where it is permanently unavailable (storage failure, node reassigned, operator error, confiscation, etc).

In my experience, Mnesia works best if you can ensure an orderly sequence of online nodes, but unless you use ram_copies tables, the data is persisted to disc, with journaling, so it's recoverable as long as you have an orderly sequence of nodes in general.

By orderly sequence, I mean that you don't lose access to a node thatis the sole holder of data. On hard provisioned systems, two geoseparated pairs of two nodes should be more than sufficient, but don't get them all storage from the same batch and turn on everything at once. You might want to add a fifth node somewhere if you want to pursue a majority transaction setup. If your nodes are more ephemeral, you probably want three (or more?) per location so you have a better chance of data migration within the location. If you can provision network storage with good persistance forecasts, you could look into storing snapshots (and maybe journals) there, but that's not an out of the box experience.

As much as possible, you want to put nodes that store redundant data in different failure domains; not in the same rack attached to the same switch and the same PDU. Of course, there's connectivity benefits of being close too, so you have to weigh the risks with the benefits.

"crash" in the context of elixir (to me) is about a part of a supervision tree - "let it crash"

Obviously running mnesia on an auto-scaling group makes about as much sense as running postgres on one.

So the missing context is ERTS, I suppose.

A lot of what's great about Phoenix is simply that it builds on top of Elixir, which is already great and which itself builds on top of Erlang/OTP, which is, too, already great; it's the "standing on the shoulders of giants" concept. The overlap between Phoenix devs and Elixir devs helps, too.

Phoenix ain't quite my cup of tea for the same reason Rails ain't my cup of tea: it's big, and it does little to hide that bigness. It's why, when I was doing web development on Elixir, I ended up gravitating to alternative frameworks (like Sugar - which, as a disclaimer, I'm a very inactive maintainer of), for the same reasons I tended to prefer Sinatra or Padrino over Rails. For most people, though, "bigness" ain't really a problem - and Phoenix does a really good job of being "Rails but actually good". At the end of the day, it's a solid choice that probably won't bite you in the ass, and that's what matters.

Phoenix is actually quite small if you look at the source and patterns. It would be interesting to compare to other frameworks. We get a lot for free from the platform, so even if you include Phoenix pubsub the feature set for size of the framework is going to be unmatched because of the process model and distributed runtime. Here’s an entire Phoenix app in 50 LOC https://gist.github.com/Gazler/b4e92e9ab7527c7e326f19856f8a9...

That's true. By the same virtue, though, Phoenix is big compared to most other Elixir web frameworks - which also get a lot for free from the platform (and even more for free from Plug). Of course you can ignore the vast majority of what Phoenix offers and churn out a 50-SLOC minimal example like that, but then why pull in an extra dependency when you could accomplish much of the same while just using Plug?

One of the things I like most about Phoenix is actually the size.

Rails significantly slows down Ruby, while adding a lot of value.

Phoenix has a negligible effect on Elixir performance, while adding a lot of value.

I don't think it's that really. Phoenix pushes a lot of things (especially expensive metaprogramming) to compile-time. For ruby to handle those sorts of things inherently adds cpu time.

I don't super love Phoenix, because a lot of it's metaprogramming stuff "breaks" elixir conventions, but I have to admit, I've done some really strange things with it and never worried about sleeping at night.

After using Liveview it’s very hard for me to go back to normal full stack development, the separation between frontend and backend with some rest api seems so arbitrary to me. Especially with doing anything realtime, with your custom websocket protocols, sagas etc.

I’ve been consulting with a few startups and it’s crazy to see how much effort is duplicated and coordination needed even in cases where there’s no public api necessary.

ATM I’m working on a few side projects and I’m enjoying being able to build all of the functionality necessary alone without reaching for anything outside elixir+postgres.

The biggest issue is a pretty steep learning curve and lack of beginner friendly documentation, lots of tinkering and code reading is necessary when starting.

LiveView is kind of magical when it works. Where I struggle with it is the constant need to decide between implementing UX logic directly in LiveView or implementing it purely on the client side via the JS helpers. Sometimes you really want the logic on the client side for latency reasons, but then you lose the ability to test it properly (unless you resort to Cypress or something like that).

Generally speaking, if it can be done in the client, it should be done in the client.

Phoenix.LiveView.JS aims to tackle the obvious cases but it also documents a pattern that I tend to use a lot in my apps: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...

The pattern above has a benefit that the dispatch still comes from Phoenix, so you are not relying on IDs or query selectors to attach functionality. You can see how we use it in Livebook here: https://github.com/livebook-dev/livebook/blob/main/assets/js.... However, if the callbacks get too complex, then you may indeed want to test them via headless browsers.

Hey Jose, funny to see there answering phoenix questions on a Saturday. Since we're discussing JS, are there any official plans to expose pushing events to the backend directly from JS? What I've been doing (and seen others do) is to assign a hook to a global window variable in the mounted callback, but that seems very hacky.

Is there any reasons why that should be avoided or why you don't want to expose a proper API for that?

You can do it using JS.push from the linked page. You can also use execJS to execute any JS event, including push, from anywhere. I am not sure if this helps though. :)

Yes indeed, my natural preference is to do it on the client – but then I can't figure out a way to unit test the behavior. I don't particularly love React overall, but it does make it easy to write tests for client-side UX logic without needing to use headless browsers. This is a fairly big deal, as headless browser tests are slow and cumbersome.

> Where I struggle with it is the constant need to decide between implementing UX logic directly in LiveView or implementing it purely on the client side via the JS helpers.

Welcome to the world of distributed systems. Who owns what piece of state is the perennial difficulty that has plagued developers forever.

You are right though, responsive testability suck with liveview (and honestly just about any be+fe system). I don't see why in the long run it shouldn't be possible to shove a JavaScript engine into the VM (I played around with doing this with mozjs for a bit -- may come back to it) and use it to store a dom for testing.

after 8 years as a nodejs developer, elixir's concurrency and parrallelism toolkit is lightyears ahead. sagas, promises, channels.. Its all a joke compared to what elixir offers.

Phoenix gives me a network synced crdta backed data structures, multicluster websocket support with long polling fallback, supervision trees with long lived processes and a descent pubsub system out of the box. we've gone 2 years in production and haven't needed redis or rabbitmq yet. its allowed us to focus on delivering features without drowning in infrastructure.

For me the most depressing thing has been - once I've seen the OTP library and everything elixir (well, erlang) provides, I've realized we've figured out most of the things like 30 years ago and have kept reinventing the wheel constantly, just because of not looking back and checking has it been solved already. Erlang's introspection tooling is better than 99% of what the market offers now as an expensive SaaS.

> it’s crazy to see how much effort is duplicated and coordination needed even in cases where there’s no public api necessary.

Probably because they decided to use microservices (read: distributed systems) for no God-loving reason.

Microservices aside, writing a web API so a single client can talk to a server is perverse in my books.

It's a distributed system either way.

Acknowledging that opens up a whole world of already thought through solutions to problems in distributed systems.

> with your custom websocket protocols, sagas etc.

What is meant by sagas in this context?

Something like https://redux-saga.js.org/, basically doing complex background workflows, something that feels like event-driven browser JS was not really built to do

Thanks

Can you elaborate a bit on the "steep learning curve" bit? What took the most time and what do you wish you'd known sooner?

Hey, big fan of AlchemistCamp! I'd say there's plenty of short snippets on specific functionality of phoenix, but not enough of content on how things fit together (what exactly do you use genservers for, where do you place things in a project, how do you organize your repo queries - do you pass objects or PKs around, how to refactor a complex function, how do nested livecomponents work and what happens to assigns when you route back, what's the difference between live_redirect, push_redirect, redirect etc.) These are the things off the top of my head that I've struggled with, and ultimately built something but in the back of my head I'm not REALLY sure if I did it correctly.

I've also really enjoyed Pragmatic Studio's course on OTP where they build a genserver from scratch, thay was eye opening, a few more in-depth courses would definitely be welcome.

Thanks for your kind words. I kinda got frustrated with my LiveView series since I started so early when it was in so much flux and have kinda been waiting for it to hit 1.0 before publishing more. One in every four episodes or so was an upgrade of the project and I kept getting incoming email from people trying to follow my series on newer library versions.

Agreed on Pragmatic Studio's course. It's probably my favorite video resource for OTP, my favorite overall resource being Saša Juric's book, Elixir in Action.

Is it possible to pack a liveview application for the app store (i.e with capacitor)?

I think you may be looking for this neat library: https://github.com/elixir-desktop/desktop

Although to be honest it boggles my that it's possible to accomplish this on iOS.

Yes, there are several. I don't have examples on hand, but elixirforum will find a few.

Does something like Storyboard exist for LiveView?

Yes! (well I'm assuming you mean Storyboard). There's a new project that accomplishes just that: https://github.com/phenixdigital/phx_live_storybook

Here's an analogy that I've been using lately that talks about why I love elixir.

When I wrote apps in other languages in the past, I felt like I was building a big skyscraper. Everything was sorta connected and it was difficult to add new doors into the project. I was sometimes limited to building something I wanted because the runtime just wouldn't allow it.

When I'm writing Elixir, it's like I'm building a city. Everything works in concert, but I could build a small building next to a skyscraper next to another building.

This is because of the runtime, not the language. It's easy to build self contained "apps" that are deployed with everything else but isolated. It let's me build the app I want rather than forcing me into a very specific way of building.

And just to be clear I'm not talking microservice, that would be like building multiple cities connected only by little roads.

I'm work shopping this analogy since it's not as clear and concise as I'd like :)

PS. I'm pretty active in the community and other private communities and didn't know about the survey. I would have a hard time imagining large scale survey orchestration given that.

My experience using channels in Go, was that I replicated state across "actors", similar to microservices (which is one of many problems that microservices have vs a monolith). Worse, this state is not in sync, so you end up worrying a lot about logical race conditions (if you're paranoid like me). I ended up still using channels, but a single message bus with a single threaded dispatch loop.

I am curious about if redundant state and state synchronization tends to be an issue in medium-to-large Elixir apps? If not, how does one design the component/actor hierarchy to avoid such issues?

You tend to not write concurrency in elixir. You tend to borrow concurrency from your libraries and frameworks, which usually are fairly buttoned down. Most websites are basically stateless data fetch/transformation agents, and even the stateful ones are usually one process. Why muck around with all that when your framework does the right thing for you out of the box?

I'm not super familiar with channels in Go, but one way to avoid the need to synchronize state in Elixir is to use ETS (Erlang Term Storage) which is a way to store data (terms) in memory.

If the state is in ETS than (optionally) any process on the node can read the state. Often this is paired with a single process that is allowed to update the state so that the state is always updated atomically. Often this pattern means that you don't need to distribute the same state to multiple processes, because instead they can just read the state they need from ETS (which is pretty fast/cheap).

I've worked on a variety of different size apps, but I haven't run into many issues with state synchronization yet. Generally, I try to keep data as close to its source of truth as I can. So if I need to synchronize state between actors, it would be to achieve a task and not to have duplicated data.

This could be an artifact of how I build systems. I have heard of some people that build really small actors and do a lot of data exchange. Without knowing details, I'd lean towards that being an anti-pattern.

So in Erlang (and I assume Elixir), the idiom is that the Process (Actor) holds the state. If you want to change the state, you send the Process a message, if you want to find out something about the state, you send the Process a message. You shouldn't be keeping the same state in multiple processes, because of all the problems you mention.

Sometimes you have requirements where it's hard to assign any given piece of state to a single actor though, that's going to be challenging in any language.

An ETS table (the OTP in-memory key/value database, more or less) is isomorphic with a Process that holds the data, although the reality is different. Mnesia if everything is done with transactions might be as well, although where I used mnesia, we did not use transactions and it was helpful to understand how the data flows between mnesia nodes, and when you might read outdated data.

Well each process has its own state, so if you needed to sync that you'd be storing it in mnesia, ets, or an external DB. Processes can watch and get messages about other processes if something were to succeed/fail.

The analogy makes sense if you’re implying that it’s a monodeploy of apps - all on the same “plot of land”.

I’ve never used the language, so no feedback to the value of the claim, but that metaphor does resonate.

We use phoenix for a few years or so, and it’s very decent. I disagree strongly with the crowd that says it’s the best thing since sliced bread, it’s, well, just a framework. It has the basics for oldschool mvc and real-time stuff, and for the rest you just write regular elixir code. It has some weird naming quirks and, to my taste, a bit too much macro magic but nothing that can’t be learned in a few days.

I don’t mean to downplay the humongous effort that goes into building any framework that doesn’t suck. Phoenix very much doesn’t suck. But it simply got all the basic right and then the true benefits come from it running in elixir/beam, which means you can skip all the job runners, redises, microservices etc.

I don’t know where you got the idea from that something is up with it. It’s chugging along great.

>I don’t mean to downplay the humongous effort that goes into building any framework that doesn’t suck.

I think you captured something I've been mulling about recently. The perception of software quality should be on an inverted scale, like incident severity where zero is the worst possible outcome. Software can't be better then "works well, has little accidental complexity". But it can be much worse than that. People rave about pieces of software that do their job and get out of the way because they're so rare, and not because they are magical unicorns that cook you breakfast and give you massages. But because they fulfill expectations at a reasonable cost.

Ah yes! I wrote a very extensive comment about phoenix vs django and forgot one of the biggest drawbacks of phoenix and ecto: the very very heavy macro usage. This is really problematic. When using Django and get an exception you can see the line that threw and (usually) understand the problem. When using phoenix if the error is on some macro related code, you are lost.

Also in Django you can easily follow the code to understand what's going on under the hood. This is not very easy in phoenix since macros are involved.

Don't get me wrong I understand that macros are used to make the code more ergonomic and avoid repeating stuff. However macros are so complicated and out of my league that I don't even try understanding them.

You should not need an IQ of 150 to understand a web framework. That's the reason phoenix w could never be widely adopted. People need a tool not a way to show off their intelligence.

While I agree that Ecto is macro heavy, I don’t agree with this assessment for Phoenix. Macros in Phoenix are mostly contained within the router and then Plug (which is a thin contract).

Perhaps there are other factors that make Phoenix harder to grasp in your experience but I hope pointing out that it may not be macros help peel some of the complexity away.

Furthermore, if you get a bad stacktrace in either Phoenix or Ecto, please open up a bug report. Macros should not and do not imply bad stacktraces. In a very simplistic way, you can think of the Elixir compiler as a huge macro, and it still strives for great error messages and stacktraces. Many Elixir building blocks are implemented with macros too, and we have great error messages and traces there, and we aim for the same in Ecto and Phoenix.

My history is that I'm probably one of the few people that did plug before Phoenix, and there are a few places where Phoenix can break your brain when you're coming to it... The organization (templates, views, controllers) is out of whack from what one "normally" does in elixir, and some of the "use X" to set defaults make it really hard to deviate from Phoenix back to what you would expect from elixir (Module.Alias.Alias => module/alias/alias) and some things are "basically impossible", like if you want to organize to Controllers.ABC instead of ABC.Controller.

Router helpers are also kind of a truck. It took me years to understand why you would want them and I still often just hardcode routes in the templates.

Some things in Phoenix are relatively hard if you want to have multiple endpoints in the same app without doing an umbrella.

On the other hand they say consistency is the hobgoblin of the small mind, so I might be guilty as charged in my quest for consistency

I was with until your unnecessary last comment, but I'll respond anyway.

Macros are a pretty important feature of Elixir that helped get it wider adoption. Without them, things become incredibly verbose. While I totally agree they can be hard to grok, there is absolutely nothing magical about them as they are expanded at compile-time. You can call `Macro.expand` on any AST and see the static code it generates.

Otherwise, with a good, well-documented framework like Phoenix, the majority of users should be able to just use it as-is without needing to show off their intelligence by diving into the underlying implementation ;) <3

PS, I've never had a problem when there's an error in a macro. The line in my app that failed is always in the stack-trace which is all I ever need to debug (though I do wish is drew my eye to it somehow).

I know about the verbosity, Erlang is notorious for that. I'd still prefer it over macros. Java is also very verbose, that wasn't a problem with it's adoption :)

Unfortunately for phoenix, when I started learning it I needed to rely on source code to understand some stuff. Trying to walk around the macro stuff was not a cool experience.

Also I did have some macro related errors most related to ecto and its syntax. See this article to understand the problem

https://www.spapas.net/2019/07/25/declarative-ecto-query-fil...

Ecto has its own, undocumented syntax. If people from the elixir irc (including the always helpful Jose Valim) wouldn't help me I'd be never be able to guess that thingie...

Quick feedback:

1. The blog post is great and it shows there is indeed complexity around dynamic filters. I would love to see a solution that tackles it all the way down to form rendering :)

2. All of the Ecto API/syntax used in the blog post is documented, afaik.

3. You mentioned in another comment that Ecto does not support associations in queries, but it does: `join: c in assoc(p, :comments)` and that takes care of the ON condition and anything else you configure.

Thank you for your kind words Jose, going all the way to the form (and table/list) rendering is the ideal for me and would greatly improve my phoenix experience!

Was that syntax documented 3 years ago? I don't really remember but definitely even if it was I couldn't find it. Also you should agree that it's non intuitive.

Finally, you are right about assoc, I don't use it because I prefer the left_join/on syntax but that's not a correct argument .

I'm not as much of a fan of the Elixir/Phoenix/LiveView stack like many here, so I'd like to respectfully share my experience.

First off, Phoenix fixes pretty much everything I didn't like about Ruby on Rails and when I need to write an API for a weekend side project that I need to turn out quickly, I'll choose it without question. If you want to use a convention-based framework that includes support for migrations and instant DB mapping, it works well. The documentation is excellent.

I personally would not choose it for a large enterprise codebase, or for something with a rich Ux that you can't control the designs for (ie. you have a Ux team that calls all the shots).

LiveView is interesting. I have found certain things overly difficult to do that are easy in the js-based frameworks. For instance, a UI that has a list of children that you want to add and remove in memory and then save at the end. Obviously you can do this, and I've done it a lot, but there are quirks with the interaction of changesets, ecto, and your form that make it tricky for newcomers. I think the tight coupling between changesets and the form gets strange as soon as the page gets complicated. Schemaless changesets work well for this, but this is more to add to the learning curve.

Understanding the interaction between LiveComponents and function components will be tricky for newcomers as soon as you are past trivial implementations. Knowing where the memory is stored and what a genserver is is super important, but not intuitive. Targeting a specific LiveComponent to receive events if you have one that has another as a child isn't intuitive. Unit testing a LiveComponent and a function component is pretty sweet, but there's a learning curve there and I ran into a few frustrating bugs that didn't help (they were fixed after a few weeks).

There's a lot of these examples. The interaction with client-side js has evolved a lot this year, but it's tricky in my opinion.

I have personally witnessed experienced, talented and smart Elixir developers struggle with LiveView. The learning curve is real.

I know Elixir people love this stuff deeply, but I don't think LiveView will win in the marketplace of ideas, even if Elixir and Phoenix gain traction. People who aren't already bought in to this stack won't be willing to build complex websites this way. I know Chris and Jose are reading this thread, and I have deep respect for their accomplishment and talent, but LiveView isn't going to be for me.

The pain points that you brought up (forms and live component exchange) are real and they are definitely in our radar.

For example, the new function components are meant to reduce the reliance on LiveComponent and ease the learning curve. We don’t have an answer for complex forms yet.

I truly think the programming model is solid and is the next step in building server driven interactive and real time applications. But we will definitely stumble here and there as we iron out the finer details. :) thanks for the feedback!

Good points but I do want to point out that LiveView is not yet at v1. As you said and see, Jose and Chris are listening :)

In the several years I’ve worked as a dev professionally I’ve seen the same pattern happen over and over again: a new tech/library/framework comes out that develops a very vocal fanbase, it manages to gain widespread adoption/traction, with time the warts come out, eventually some people sour on the technology and we get an uptick on “Why our team moved away from X”, some more informed than others.

I’ve seen it happen in various degrees to React, Docker, Microservices, Kubernetes, Rust and I’m sure I’m forgetting others.

Certain problems in software are so complex, that there’s no one size fits all solution. The problem with the early fanbase is that it tends to be a self-selecting group in one way or another. When you read someone’s anecdote that library/framework X “was a delight” you don’t always know for example that it was maybe used by a group of 3 devs for a startup pulling $50k in MRR. Will the same apply for you team that is 10x bigger? Maybe. The opposite can be true where you have some project get open sourced by a tech giant which gets adopted by smaller teams with very different needs or resources.

My point is, if you hear outsized praise for something it’s likely because it’s early in the hype cycle or it hasn’t seen enough wide adoption. No solution is perfect.

It’s better to take a look yourself since no one else will know your or your teams needs and preferences. This is where the buzz can come in handy. It can highlight new technologies worth trying out. You’ll usually learn something new in the process.

> I’ve seen it happen in various degrees to React, Docker, Microservices, Kubernetes, Rust and I’m sure I’m forgetting others.

MFC, vb3,4,5,6, entity framework (every version), OLE, COM, DCOM, ActiveX (all of which were basically the same thing), as2, as3, PureMVC, Cairngorm, Flex, asp, asp server controls, DAO, asp.net, php (and every php framework), Cold Fusion, CFCs, JSP, servelets, beans, spring, dojo, jQuery, ext, Google's JWC, backbone, moo tools, knockout, meteor, angular, angular (x), react

Just off the top of my head of hype trains I've ridden.

Now I'm all about simple.

Express + web components + postgres is the magic combination of simplicity, time to market, performance and community for me these days.

Why not use NestJS?

Phoenix / LiveView is a glimpse at what mainstream web development may look like in the future. Nowadays companies burn a lot of money to hire frontend and backend technology specialists, and making them work together productively is not a trivial task. Simplifying your stack can mitigate or solve many problems.

Any time I want to get a side project actually done, I'll use Phoenix + Live View. It's effective and efficient (from both a dev perspective, a server resources perspective, and a client load speed perspective). You don't have to worry about an API or setting up react etc but have enough interactivity to get your idea across.

I don't think it's any fanatical following, it looks like a lot of other people are in the same boat as me with it. It's just good and effective.

Perhaps worth mentioning that the Phoenix creator Chris McCord has written a number of posts on the Fly.io blog since he joined them a year ago (exactly a year today?): https://fly.io/blog/how-we-got-to-liveview/ https://fly.io/blog/how-safari-ruined-my-tuesday/ https://fly.io/blog/livebeats/ https://fly.io/blog/liveview-its-alive/

I guess that’s part of the reason why the Phoenix blog is less active?

I played with Elixir and Phoenix for about two years. I absolutely loved it. To be honest, Elixir wasn't my favorite, but I felt like Phoenix was everything Ruby on Rails ever set out to be.

I did find the documentation a little sparse at times, especially when dealing with heavily nested tables (or even just many_to_many relationships were cumbersome to work with).

Things like Plug, hex, pattern matching and so much more have stuck with me and I still miss them almost daily in my current stack.

elixir takes the operational characteristics of the beam, which are by historical serendipity very desirable for implementing http servers, sands the rough edges off erlang's tooling, and gives the language a syntactic facelift that is very comfortable and non-threatening for ruby-on-rails-generation webdevs

in a similar spirit, phoenix takes cowboy, an http server written in erlang that very competently exploits the above-mentioned operational characteristics, and slots it into a relatively well-thought-out, ergonomic elixir web framework

in summary, it appeals to “wow cool shiny clean low boilerplate” etc., but at the same time is built atop solid tech, & so doesn't shit the bed when you scale. similar vibe to why people fall in love clojure (or so i am told on that count)

Phoenix is pretty nice, but its (or Elixir's, rather) biggest weakness is the lack of static typing.

Yeah thats why I'm keeping one eyeball on Gleam[1] which is a 'statically-typed Erlang/Elixir', when that hits 1.0 that's when I will put down my F# SAFE stack stuff and give it a try.

[1] https://gleam.run/

Having written a fair bit of Elixir and Erlang code over the years, I don't feel like I miss static types much when I can readily pattern match on tagged tuples.

What is your experience with refactoring, especially a big project? This is where static typing helps a lot ihmo. Especially if you are in a startup like environment where things tend to change quickly.

Funny you ask that, since I have indeed refactored OTPCL (a sort of Erlang-flavored Tcl-flavored scripting/config language I've been on-and-off hacking on for the last couple years) multiple times now, namely to rewrite the parser and to rewrite how command exports work - so the commit history should reflect some of the pitfalls and boons I encountered.

I actually did pursue static typing (w/ type annotations and Dialyzer) at one point, but quickly lost interest, since it didn't really seem to add much. Having comprehensive tests, on the other hand, was crucial - especially since I could use pattern matching within those tests to make assertions about expected inputs and outputs.

I will say that there were bugs that compile-time type checking probably would've caught, but tests also readily caught them. The same can likely be said for current bugs. It's ultimately the same idea: validate that your code adheres to the expected API and behavior; only difference is that the validation happens in different places.

Pattern matching and structs get you 90% of the way there imo. And Elixir started emitting warnings if you try to access a field in a struct and it doesn't exist.

Having written Elixir code for about a year and coming from Go, I miss static types dearly and specs are not enough. I have to dive into the code to know what I'm working with locally. My largest frustration is all the unhandled errors and exceptions that will not have the required context when they finally crash some process. It is apparently uniodiomatic to capture details in structured logs.

AFAIK there was some posts by Jose Valim on twitter about static typing exploration, I think it was spurred on by their work with NX/Numbat (scientific Elixir libs).

Twitter wont let me view more than 3 tweets without making an account so I can't find it...

He talked about it at length at the most recent elixir conf eu : https://youtu.be/Jf5Hsa1KOc8 .But it might never materialise.

And that no one knows it. Unless you're prepared to do all the coding yourself or pay top dollar to recruit it's best to avoid exotic languages.

That's a bit of an oversimplification. If you're OK with remote, it's not hard to find Elixir devs. You can also start with just one or two senior people, and for the rest hire people with web experience (or whatever else is useful) in other languages.

There was a company hiring lots of Elixir devs that actually hired straight from bootcamps - I forgot the name unfortunately, they had an interview on the Elixir blog or Adopting Elixir book or somewhere like that...

I don't necessarily disagree with that sentiment, but you can also attract very good developers when you don't avoid exotic languages.

Channels are great, LiveView is good, Plugs are elegant, although one thing I don't quite like are Contexts. Actually a lot of its strength come from using Elixir & the Beam.

For everything else I still feel it's inferior to my other framework of choice Symfony (well ok ... maybe not regarding Ecto vs Doctrine, but "transparent" caching would have been nice).

> I don't quite like are Contexts

A while back I wrote a small guide on how to design your contexts and its queries for flexibility. Not sure if this will actually answer some on your issues with them.

https://elixirforum.com/t/a-design-pattern-for-more-flexible...

Yes it's not bad!

I guess I dislike the code that the context generator produces. A bit like the auth generator that forces you to commit code you didn't write and that is basically a mess to upgrade, and frankly not that great to modify to suit your needs.

I really dislike how the auth system is implemented, that it is only accessible with a generator.

I had a crappy auth system I wanted to migrate to it, I had to run the generator and try to update my code with the generated logic. Ugh, not fun.

But regarding contexts, they're just modules. Nothing mandates them, it's just a best practice to collect database functions in their own module, whatever the language. I've never used the context generator.

Having used Pheonix for one of my small failed startups in the past (failed because of the business, not because of the tech) - I loved every second of it. It was super easy to use and extremely quick to be productive. Ecto is a fantastic ORM, the OTP system is great to build on, and LiveView is magic. As a solo dev, it is a true isomorphic web dev experience with a nice clean language and structure to build in. Even tests work.

I just wish I could get a job in it.

I was a RoR developer for 5 years and have now worked on Phoenix apps for about 6 years.

The survey results have certainly gotta be at least a little selection bias, combined with Rails apps being on average older (and therefore more "legacy"). But on the other hand, for me Elixir and Phoenix really did clean up a lot of the pain points around Rails (performance, magic), while keeping the great things (developer experience, general structure), and adding some brand new stuff (channels).

LiveView is really interesting, but still a bit of an experiment, from my perspective. At least, I haven't had a chance to use it "in anger" in production yet, but am generally satisfied with my "Phoenix as a better Rails" apps.

How do you feel about Hotwire in comparison (or someone else)?

We’ve used Phoenix for 5 years for an important internal project in a large tech company. We don’t do a ton with Phoenix itself, it’s just a simple MVC web app for managing a more complicated Elixir thing. No Liveview or even Ecto, for instance. But it has worked just fine.

We push Elixir to its absolute limits, though, and after years of being on call for a production Elixir system, I’m still totally in love with it. Plenty of experience with Ruby, Python, PHP, Java. Elixir is a game changer. If I build basically anything in the future it will be in Elixir. And it will probably need some kind of web interface, so that will definitely be Phoenix.

What do you mean by pushing it to the limit? And do you have any insight of what’s it’s like to be on call with Elixir? From what I saw it has many great tools to debug problem. Also the “it never crashes” is quite appealing.

Pushing it in terms of performance and complexity. We have high QPS and need low latency, a few milliseconds to do a lot of work. Baseline performance of nice idiomatic Elixir is good enough mostly for general business logic. Tools like Recon help you find bottlenecks. You can move state off heap into ETS to reduce GC, or share a public ETS table to eliminate inter-process communication. You can dynamically recompile a module at runtime when configuration changes. You can move really hot loops into NIFs. These are all relatively easy once you know how and really good at eliminating bottlenecks.

On call is great. Tail latency (p99.9 and up) is great, much better than Java, due to per-process vs stop-the-world GC. Remote console is a superpower, lets you debug in production. Minor flakiness tends to get handled silently be supervised processes crashing and getting restarted. Elixir stuff just pages us much, much less than other languages.

I'm one of the 3 maintainers of the French open-data transportation access point (at https://transport.data.gouv.fr/?locale=en), which runs on top of Elixir & Phoenix.

I'm not a big fan of surveys and I'm not sure I've responded to this one actually, but: my current feeling around Phoenix is that it will be my go-to framework for anything web related for the years to come, but also Elixir will be, for larger topics (ML, embedded, data-viz, scripting, etc).

There are a number of important points (to my taste) that comes out of my use of Elixir & Phoenix :

- the maintenance story has been quite good (maintenance work is one of my main line of work since year 2k, I have used many stacks, including Java, .Net, RubyOnRails etc). Upgrades and refactoring & moving code around has been quite easy overall, once you get the stuff right (using Mox etc).

- Phoenix, Ecto & Elixir are a good "generalist web framework" for a lot of use

- Compared to some stacks (non-evented Ruby & Python, for instance), having a part of your app work as a proxy for domain-specific uses, is not a problem, and does not even require you to split that part from the main app (example at https://github.com/etalab/transport-site/tree/master/apps/un..., where we proxy/cache GTFS-RT protobuf & SIRI XML feeds behind rules, adding rate-limiting & hiding target server authentication schemes)

- Similarly, anything real-time is at least initially trivial. For instance, creating this real-time view of moving vehicles (https://transport.data.gouv.fr/explore) with 70+ GTFS-RT feeds has been quite easy (PR at https://github.com/etalab/transport-site/pull/2224). The server side is like "EventMachine done right", and the live updates are broadcasted to each client via web socket. No extra server (e.g. AnyCable) or anything is needed.

From a perf/ops POV, the amount of topics you do not even have to think about is quite important, which is very nice.

Overall I can see myself sticking to this stack for the next 15 years or so, without much worries (I've been coding since 1984 as a kid, so I have a good idea to know when to keep a framework around or not :P)

Thank you for all this. Did you have any pain point? Lack of libraries or something so far?

Phoenix (and similar projects, but this is the best I tried), are what things are supposed to be like. React etc are depressingly overly complex for the programmer imho. I mean I made very large (because it's more popular so more people want it) react/react native applications and I made large-ish phoenix & laravel livewire applications. There is simply no comparison in the experience as far as i'm concerned. Sure there are negatives to the Phoenix approach, but nothing can make up for the productivity you gain.

Could you elaborate on differences between Liveview and Livewire from your point of view? The Elixir/Phoenix seems to be much more suited to this approach because of websockets. PHP/Laravel have to do everything through http requests and it seems it would be limiting? If the Livewire approach worked well it would be theoretically possible to use it in pretty much any system that speaks http (RoR already also has hotwire).

I am mostly curious if i should try Livewire for next smaller project.

It's an odd way to judge the success of a project based on number of recent blog posts or whatever.

In general Elixir is a bit more quiet that way, but that doesn't go to say its not nice to use.

I questioned neither success nor usability.

(Apparent) activity of a project relative to how active the overall space is seems like a decent metric to look at.

Ther weirdest thing about Elixir projects like Phoenix is that they don’t rewrite them changing things needlessly every generation, instead something about the language and decisions made causes things to be very stable. You might see this as a lack of activity but they really have worked on great new features with every release.

Phoenix is really lovely, I’ve been using Absinthe the GraphQL add on and it’s been awesome and for the first time I’m starting to play with channels and web sockets which are really so well done and so scalable. The only thing I’d really like is types and better introspection support in my editor but pattern matching often can be used to simulate runtime duck typing to a certain extent protecting you even if your program will still compile.

Maybe worth trying it out as Elixir and Phoenix are quite simple compared to a lot of magic you’ll see in OOP programming languages.

>something about the language and decisions made causes things to be very stable

We should never underestimate the value of building on solid foundations. This may not be as intuitive with software as with, say, buildings. But it's just as true. Start with a language slapped together quickly and you end up with tonnes of unnecessary headaches down the line. Start with one built around the main problem it's trying to solve, with a lot of foresight and early improvements built in, and you eliminate whole classes of problems.

Reminds me of this twitter thread from Jose yesterday:

> I keep reading the false dichotomy that languages/frameworks either evolve (and therefore break code) or stagnate (and are stable) while there is plenty of evidence in both old (C#, Erlang, etc) and new (Rust, Go, Elixir, etc) that you can evolve without breaking code. [1/4]

https://twitter.com/josevalim/status/1560552538004389890

Linus Torvalds has a simple demand: don’t break userspace.

It’s hard work, but breaking changes should be rare. As a happy C# dev, very rarely is anything broken over here. Some obscure changes were made for the upgrade to 4.8 and .NET 5.0 but there are significant benefits.

LiveView, which of course isn’t exactly Phoenix but is closely related, changed a great deal late last year. These were welcome changes but they were significant.

I would also look at

https://trends.google.com/trends/explore?date=today%205-y&ge...

I think LiveView has taken a lot of effort off the main Phoenix project.

You have no idea how much Express.js sucks on larger projects. A pain in the ass.

How so?

Lots of reasons:

- Code cleanliness: their code almost looks like code golfing. Hard to debug.

- Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues.

- Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/bench...

- Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy.

- WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io.

- WebSocket pub/sub: built-in with uWebSockets.js

There are better alternatives like the following:

- https://www.fastify.io/

- https://github.com/uNetworking/uWebSockets.js

- https://github.com/kartikk221/hyper-express

Zero predefined structure

Thoughts on Nest.js?

Nest.js uses express.js and socket.io underneath.

uWebSockets.js beats both on performance benchmarks. In fact it beats everything based on Node's built-in http module, such as fastify, hapi, koa.

https://github.com/uNetworking/uWebSockets.js

I will trade ease of use over performance everyday. I can code in Rust but Rails or NestJS can work just fine.

The last time I try to play with it, I got stuck on 2 things that seem basic:

- Couldn’t serve a static folder! Like I had a folder of js/img that I wanted to serve as is, didn’t want to transform into anything, it was super difficult to do.

- Couldn’t find an easy way to inspect or debug a live pipe.

It was a while ago so maybe things have improved a lot. However it kind of left a sour taste in my mouth when asking for help, I was told static folder is not really the scope of the framework and things in the like.

In your generated `my_app_web/endpoint.ex` there is a plug that will serve static contents from your `priv/static` directory:

https://github.com/phoenixframework/phoenix/blob/master/inst...

This points to a function in `my_app_web.ex` which specifies which paths it will serve:

https://github.com/phoenixframework/phoenix/blob/master/inst...

So you can either copy your js and image folders to `priv/static/assets` and they will be available as `localhost:port/assets/js/somefile.js` etc. OR you can add `js` to the list of paths to serve in app_name_web.ex and copy your js files to `priv/static/js` and access them at `localhost:port/js/somefile.js`.

I like it but coming with experience in Rails there isn’t the depth of hex packages to choose from and I don’t know if I’d call Ecto an ORM for a couple reasons. Well, there aren’t objects and Ecto gives you a blueprint to write DB code, you still need to write all of the actual code yourself for anything beyond a simple model structure.

Unless I’ve misunderstood things a bit. Thats part of the issue is the docs feel obtuse (maybe its me), like very common things you want to do are buried somewhere and use different terminology than I would think. I understand the approach isn’t the same as Rails which is very opinionated about how to do things but I wish their were a set of opinionated guides on how to do things of medium complexity. Like complex forms, views representing normalized data from a half-dozen tables that have relationships.

Phoenix is amazing

The only reason it isn't dethroning RoR is because it will take some time before the ecosystem of plugs can catch up to the amazing ecosystem of gems

Meanwhile, plenty of gems have gone abandoned.

That may be true, but not to a degree where it affects the overall landscape of which framework is going to help you get your product/iteration up and running faster

All I can say is that after 15+ years of web development, when I started using Elixir and Phoenix a few years ago they brought me a joy I had lost in recent years. Is it at times frustrating that the community is smaller, and there is less official support from companies? Sure. But I wouldn't say it has been a real problem for us yet to be honest.

LiveView itself is an interesting concept and while we do use it in production daily for almost 2 years, I'm not yet convinced it's really better than having the frontend be React (or whichever you prefer). It has grown quickly and become much more useful than it started out as.

Ecto in my opinion is the thing I would miss most were I to switch to something else.

I chose my current employer because I had the option to choose an Elixir/Phoenix stack. In addition, I managed to get another senior developer to join me and leave his secure quasi-government job because of Elixir as well.

I'm using django for more than 10 years, phoenix for like 4. I consider myself experienced in both frameworks. I wanted to write some blog post about my experience with them, but never found the time.

In any case, Phoenix is a fine (niche) framework but can't really be compared to a masterpiece like Django:

* Phoenix, probably because of its influences from the ruby world is using some concept called "generators". Using the generator it will generate (sometimes a lot) source code files that will implement some functionality. For example, let's suppose you create a new schema (similar to the django model concept). You can use the generator so it will automagically create code for the schema file, its migratinons, some crud forms and even tests. This works fine until you need add another field to your schema, or you need to rename a field or just do a small mistake! Then you'll need to do some very error-prone and boring work. Compare this to the way that Django uses the Model to generate everything from that using class inheritance and composition, without the need to write any code. Also notice that the phoenix generators can't understand relations and you need to edit the schema and migration files by hand to properly add references.

* No auto-migraton support. That's that. If you add a field to a schema you need to edit the migrtion file yourself. Django automagically understands the changes and will generate the migration file.

* This generator thing unfortunately has influenced various other stuff from phoenix, like authentication (you use generators to create some kind of authentication code which then you need to edit). Again, compare this to the elegance of Django using the authentication backends. Also you use generators for presence, channels, whatever...

* The "ORM" (which is not really an ORM it's more or less a way to talk to the DB called ecto) is miles behind the Django ORM. It doesn't support any andvanced stuff, you need to do the joins yourself (i.e from(u in User), left_join: (a in Authority), on: a.id = u.authority_id, where: u.is_active == true. Compare that to User.objects.filter(is_active=True).select_related('authority').

* Also the ORM doesn't support most of the advanced stuff and you need to use an escape hatch called "fragment" that allows you to write raw SQL.

* Phoenix has no django admin. nuff said.

* The phoenix has some funny controller/view/template architecture (which I also think that was influenced from rails) that isn't very intuitive. The views are more or less useless and everything is like router -> controller -> template. Similar to urls -> views -> template in Django. But having the unnecessary views there adds another level of abstraction making everything more complexfor no reason.

* Things like template inheritance are not really possible in phoenix. You use a thing called layouts to re-use stuff. The Django template inheritance is much, much more powerful and simple to understand.

* Django is much more batteries included: Phoenix has more or less no authentication (beyond the generator generated one I mentioned before), no caching framework (you need to use some kind of extension), no pagination support (!), no permissions and various other things that you'll need to implement yourself or find some obscure library that has 3 years to be updated and doesn't suport the latest phoenix, which gets me to the next point:

* Phoenix needs a JS bundler for its javascript code. It used to use webpack and now uses esbuild. Still, they could just provide the proper compiled JS files and let us decide if we wanted to use any node-js stuff (which I avoid like hell).

* Re-using code among controllers is possible using plugs but definitely not as straightforward as extending class based views with mixins.

* The ecosystem is very very small. Most libraries/extensions are 1 person projects and most of these are from persons that tried phoenix for a project but moved on so they are unmaintained. I remember that there was the "default" pagination library in phoenix (scrivener) and it didn't support the latest phoenix for like 2 years? People had to use a fork instead.

* Better support and much easier updates. Because of the huge different in users, when you have any problem with django you're going to easily find answers on line. Also because Django is more mature and much more eyes look at its release candidates, it will be much easier to update to new versions. I've got apps that started from Django 1.6 and now are at 3.2.

* The documentation of phoenix is not bad but it can't be compared to the django docs.

Yes I know that until now I only told bad things about Phoenix but it's my experience and especially when trying to compare it with something definitely better. However I have used phoenix in a couple of specific projects and these were sucesfull. My opinion in that phoenix is not a general purpose framework but a niche one. When you have some specific requirements then yes phoenix would be a fine solution. These requirements are real-time updates using websockets. It's exactly the niche that Django (and python is general) is not good.

Phoenix, because of elixir (and erlang) is great on supporting small processes that can be used to implement quick real-time communication between clients and server so as to implement apps like chat servers, online games, broadcast communication server etc i.e when your http clients open a websocket and send/receive real-time updates to the server.

To enhance that even more, phoenix has a technology called Liveview that makes all this stuff even easier because it allows you to do client-side updates from the server side so as to keep JS to a bare minimum; instead of using react in your client side you keep all your app server side. This is a revelation and a much better way to work than using the client side JS framworks. This probably is the reason that Phoenix is loved so much more.

Please notice that I didn't compare Elixir/Erlang vs Python. Elixir can be used to create some stuff that can't be done in Python (i.e using processes to schedule or queue stuff etc) but these are not Phoenix/Django related stuff.

Sorry for the long comment, I guess I should have written the blog post ...

Your comparison matches a lot mine with Symfony, but is way more detailed.

- I see you dislike generators as much as me ;)

- Template inheritance, it's maddening isn't it? Sadly it does not resonate with the RoR crowd and by extension the Phoenix one. I've been told to use "heex function components" instead but I'm still a bit lost as how this is an appropriate substitute.

- I disagree with your take on "fragment", it's almost my favourite feature of Ecto, as it means you can use almost any functionality of your database/version of choice without specific support from the (not-)ORM.

Please open up a thread on ElixirForum about template inheritance and CC me. If you include Python examples, I can help translate them to function components. :)

Thanks! I did it there: https://elixirforum.com/t/using-function-components-for-temp...

Hey Jose, here's how it's working: https://docs.djangoproject.com/en/4.1/ref/templates/language...

Generators are more or less useless to me. They are useful to create some tutorial code to see how some stuff should be idiomatically written, but for anything else I just ignore em and just write the code myself.

About the fragment. I agree it is useful but it's usefulness relies on the fact that most non basic sql is not implemented in ecto so you need to be able to use it somehow... Consider that the Django ORM implements almost anything that your gonna need (thing like Case, SQL functions, subqueries, whatever) so you only write ORM code!

There are many points in your comment that is a matter of preference... And with many of them I desagree...

I used Django in the past and the "auto-migraton support" feature you are talking about is great but not perfect. It is even mentioned in the official documentation. I have been myself in situations where it created unwanted behavior. So I can understand the Elixir core team not wanting to bet on a feature that is neither perfect nor essential.

> But having the unnecessary views there adds another level of abstraction making everything more complex for no reason.

Hell no! Imagine how much more succinct and clear templates can be just because you moved some verbose logic into helpers defined in your views? I find that Phoenix encourages people, especially beginners, to adopt nice ways to organize their code.

The generators you like them or not but you are not forced to use them. Personally I find that they boost productivity and are a very good learning tool.

Finally I would say that Django did not become what it is in a day. Elixir/Phoenix is perhaps slowly but surely moving towards a future that I am impatiently awaiting.

I agree about some things being a matter of prefernece and also depending on the kind of stuff you are making.

About the migrations; creating automigrations like django is a ton of work. It handles all trivial and most non-trivial cases perfectly. If you have some really complex stuff you can edit the migration file (it.s normal python).

I don't like organiziging stuff into per-controller views, I usually need to re-use things and create helper views, or other modules having that functionality etc. So their usefulness is diminishing.

About generators, I agree about the learning stuff (I actually mentioned that in my comment). About productivity... hm it depends on how useful they would be.

As for your final comment? I definitely agree; Django is a behemoth framework with more than 15 years of development time and a really huge community of contributors. Phoenix is much smaller both in age and in community so it will definitely be less mature. But I agree that it moves towards the correct goal, especially if you focus on its excellent real-time features where it really shines!

Thank you for the insightful comment. I work with Elixir/Phoenix on a few of our projects, and while I do love both, all of these points ring true.

Only thing I don't agree with is Ecto. I have found it more straightforward to work it and reason about, much because of the functional syntax of Elixir.

But yes, I do hate generators. Adding auth to an existing project was a bad experience, since you need to do a diff to understand changes being added. Not only that, wanting to keep the code clean, removing redundant or completely unnecessary features requires you to understand how the whole thing works. On one hand, great, it's never a bad thing to know every single detail about your authentication. On the other, it's time-consuming, and maybe I would prefer the separate "blackbox" that I can opt-into with clear API which I can always dive into that doesn't mess directly with dev-written code.

> Phoenix has no django admin. nuff said.

Just curious, did you try Torch or Kaffy?

https://github.com/mojotech/torch https://github.com/aesmail/kaffy

For the ORM and auto-generated DB migrations, I actually prefer the Phoenix way. Ecto makes it much harder to trigger N+1 queries than the Django ORM, and in practice I find the explicit migrations make people actually think about what they're doing and what to index, so the schema is cleaner. But I could see why someone would prefer the Django way, and I'd be curious to see the same kind of system in Elixir.

I am aware about the libs you mention. Torch is using generators which is a major nono for me, so... Kaffy I always wanted to try but the fact that it's an add on (so I'll get problems when updating) along with the fact that it seems to need a lot of configuration to enable it (as opposed to admin.site.register(Foo,FooAdmin) in Django) made it difficult for me to decide to try it!

I agree about the n+1. Its a long debate about how useful it is. I understand it is problematic some times but I'd prefer it any time compared to having to declare all joins on my query. Yes, it had bitten me a couple of times when I was new to Django but nowadays select_related and prefetch_related are like a second nature...

Creator of Kaffy here. Kaffy was inspired by django's built-in admin.

I disagree with one point you mentioned regarding configuration. Kaffy requires less configuration to work out of the box with all your schemas. In django, you do need to to write admin.site.register(Foo) for all your models to be included in the admin interface, where in Kaffy all your schemas/models are included by default. Kaffy also offers things that django admin doesn't like a dashboard, static pages, and scheduled tasks.

I suggest you give Kaffy a try and, with your django/phoenix expertise, I'd love to know your feedback.

Hello, thanks for your comment! I didn't know that Kaffy was inspired from the Django admin, I'll definitely try to use integrate Kaffy in one of my phoenix projects now :)

Not an answer to your question, but a lot of Elixir activity takes place on elixirforum.com and there's a Phoenix sub-forum there at well.

https://elixirforum.com/c/phoenix-forum/20

Phoenix really is a joy to use, been using it in production for almost half a decade now. Elixir can have a somewhat steep learning curve, especially for junior devs, but the other side of it is a wonderful place to code.

Half Life Alyx ruined VR gaming for me. Every other game feels like a tech demo compared to it, and so my Valve Index sits behind me collecting dust.

So to has Phoenix ruined any other way of building website. The though of going back to react and all that mess just makes my stomach turn.

We're building a new startup with Liveview, all-in and it's been fun. There are some sharp corners but you get so much for free it's completely worth it to me. I don't think I would build a webapp with anything other than liveview for the next decade. It's just too good and too productive.

Those using it for big projects, is it possible to have some feedback about what is still missing or libraries are there but still need more development. Like does it have the library for Elaticsearch? Everything for auth? Etc… which important library lack documentation? For instance I saw that the one of Stripe is not that good.

That’s what stop me from using it. Being in a startup we don’t have the ressources to have developers having to code other things on top of raising a startup from the ground…

I haven't used Phoenix or Elixir since the latter was new, though I'm sure that they're great tools.

The fanaticism around them partly comes from disillusionment from frontend development. The pendulum has swung to "server-side was right the whole time!" Disillusionment with Ruby may also be a factor as well. Elixir also makes way more promises around scalability and fault tolerance than any language I'm aware of (yes I know it's using the Erlang VM but no one wants to write Erlang).

I have been greatly enjoying writing a side project in phoenix/liveview. It's fun, works well, community is welcoming, etc.

Previously I was writing side projects with Go APIs and react, and compared to that, this is miles ahead. I love not having to worry about creating a REST endpoint for every single interaction.

Also, I really like Ecto. It hits the sweet spot for an ORM of not too much magic and a lot of convenience.

Give it try if you haven't already :)

I think part of it might be because it has a very ruby friendly syntax. So you end up with a bunch of ruby refugees trying it and they are shocked at how quick it is and how easy concurrency is compared to ruby so they fall in love. In reality elixir is not really fast it’s just ruby is shockingly slow. But elixir does have a nice concurrency story. There is no denying that.

As a Laravel dev, can somebody tell me what Phoenix does that Laravel doesn’t? Or maybe, what it does better and/or worse?

If you want to understand, build something with it. Then you will see.