While I have noticed that Phoenix is a thing people are generally happy about, I was surprised to see, that it beats the Loved/Dreaded section of the current stackoverflow survey by a staggering 20% over Express and RoR.
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?
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.
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.
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
As for Stripe, some client developers have been code-generating their client with mixed success. ExAws, however, is essential.
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.
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 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.
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.
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.
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.
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.
Probably because they decided to use microservices (read: distributed systems) for no God-loving reason.
Acknowledging that opens up a whole world of already thought through solutions to problems in distributed systems.
What is meant by sagas in this context?
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.
Although to be honest it boggles my that it's possible to accomplish this on iOS.
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 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?
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).
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.
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.
I’ve never used the language, so no feedback to the value of the claim, but that metaphor does resonate.
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 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.
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.
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.
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).
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.
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!
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.
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.