I suspect this is due to some rather fanatical following and coordinated effort to skew the outcome. Still, I am curious, specially since the latest blog update is nearly from one year ago, which gets me at least a little suspicious in web world.
Any takers? What's the current feeling around Phoenix? Is is the end all superior fullstack framework (at least form the devs side) this survey makes it out to be?
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
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.
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.
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.
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.
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.
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 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.
I guess that’s part of the reason why the Phoenix blog is less active?
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.
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)
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 just wish I could get a job in it.
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.
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.
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)
In general Elixir is a bit more quiet that way, but that doesn't go to say its not nice to use.
- 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.
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.
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
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.
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 ...
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.
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…
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).
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 :)
sorry my shift in this keyboard is broken so no capitalise or question mark