nhoban
Convincing a client to use Phoenix over other popular web frameworks
I’ve recently had a client query our use of Phoenix over other web frameworks. They indicated their investors/mentors had never heard of it and were concerned it wasn’t that popular among devs.
I’m guessing this is mainly a risk mitigation concern and that should they want to find another dev to replace us for any reason, they want to be able to with ease.
I’m just curious how you approach discussions like these with potential clients? Do you have any good resources you turn to that help you convince the client that Phoenix is the better choice over other web frameworks?
We’ve provided something like the following explanation to the client, but would love to hear any thoughts you may have if you’ve had dealing with this/similar scenarios.
Phoenix was created in 2014 (built on top of Elixir, which is the language) and is kind of like a lightweight version of Ruby on Rails. It was recently voted the most loved web framework by developers.
Stack Overflow Developer Survey 2022
Many notable organisations are using Elixir and/or Phoenix, including Apple, Financial Times, Bleacher Report etc.. Some benefits of Phoenix are:
- Easy to learn and quick to scale
- Enables you to go from prototype to production in no time
- Incredibly fast
- Concurrency - can handle lots of simultaneous connections extremely efficiently
It’s better than Java because it allows you to avoid having to use a client side framework like React or Vue. This is thanks to a technology called LiveView, which allows you to write client side behaviour in backend code. The end result is a web application that feels fast like a React app, but doesn’t require the overhead of creating and maintaining separate backend and front end apps.
While not as many developers know it, it is quite easy for other developers to pick up. A ruby or PHP developer should have no problems picking it up in a couple of weeks."
Most Liked
LostKobrakai
If non-technical people are concerned about your choice of technology it means they’re worried about painting themselves in a corner. Approaching that would involve figuring out which corner it is they’re worried about and then addressing those worries. I don’t think they want to be convinced about one technology over the other, but they seek ensurance of making a good choice. In the end they’re likely not in the position of properly evaluating the brought up arguments anyways.
dimitarvp
I am with @LostKobrakai and @adamu here: pick your battles wisely.
I’ve successfully advocated for Elixir 4 times in the last 6.5 years and the companies told me later they were very happy with their choice. Another 7 opted for something else.
Technical merits don’t matter to managers / business owners; they see technical complexities as your responsibility. They are mostly just managing risk. To them picking a stack with smaller hiring pool is a no-brainer case of high risk.
Whether that means they treat their employees like cattle that can and should be replaced at their whim – I’ll leave that evaluation to you. In my experience this was not always the case but to those people “just treat your people well and they won’t leave, duh!” is somehow not common sense. Then again, people leaving so they can focus on kids or side hobbies is a thing as well so I can understand their point of view somewhat.
If you end up trying to advocate for Elixir, emphasize on the fact that there is a number of companies that chose Elixir without having a single Elixir dev in their team, and still succeeded.
This impresses non-technical people.
mindok
I think your response looks good. I’d add a couple more points:
- that it makes modern, real-time features pretty straightforward to add, and give them some examples of what that means to them as a business.
- it just runs… fault tolerance due to the backing of the BEAM significantly improves reliability
- while developers may have to learn Elixir / Phoenix, they won’t need to learn a bunch of other stuff like external background job managers, redis, latest JS front-end framework, etc as all these things are baked in (@sasajuric’s great talk, Soul of Erlang, (Youtube) tabulates these at the end)
- related to the above - it’s operationally very simple to deploy - reduces DevOps costs and skill base required
It is then up to them to weigh up risks and benefits in their context, and I think it’s totally fair if the concerns related to developer availability outweigh the benefits for them - tech isn’t one size fits all. I don’t think you will find a shortage of other clients willing to go with Elixir/Phoenix.
Last Post!
otijhuis
I totally agree that there are many reasons Elixir/Phoenix can be an objectively much better fit for projects. I was just playing devil’s advocate. My comments were based on the explanation that was used in the first post. There is no reasoning why it benefits the business. There are just generic statements which are very easy to counter. There’s nothing objective about it. Even ‘easy to learn’ might not be the case depending on who is doing the learning. Functional programming might be completely new to them. I’ve seen developers struggle with it.
I love new and different technologies. I’m also someone who can switch between technologies very easily. But iimho as a senior developer it’s also my responsibility to be objective, look at the type of project, look at the people around me and see things from the business side. I also have to be aware of both the pros and cons of the technologies used. I’ve seen countless times where something is being used because it’s new and shiny, not because it benefits the business. Many developers also tend to ignore the negatives of the technologies or what is required to support it in production (deployment changes, support training and so on). So yes, I will push back and ask tough questions. Not to prevent change, just to be sure there is solid reasoning behind it and that it will actually benefit the business.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









