I really wish this tutorial existed 5 years ago. It would've convinced me to actually try Phoenix instead of pulling up the official getting started guide only to scream internally at all the moving parts and start looking for alternatives.
But on the other hand, had this tutorial existed 5 years ago, I wouldn't have found Sugar (sugar-framework.github.io), and in turn wouldn't have started contributing to it, and in turn wouldn't have gone on the various deep dives into OTP and Plug necessary to comprehend it, let alone become one of the maintainers of it (albeit a rather neglectful one; this year's New Years Resolution is to address some longstanding bugs and get it back into a state where it could actually be to Phoenix as, say, Padrino is to Rails or Flask is to Django), so I guess it ain't all bad :)
I hear ya. I think Hexdocs is great and I really appreciate the standardization of the Elixir community on one documentation format/site (though ironically it doesn't look like Sugar uses hexdocs), and in particular it's great at listing the various functions/modules etc within a package. However, I find it to be very lacking in terms of guide/tutorial content, and the Phoenix guide [1] is a great example of how it falls short. Compared to stuff like Django, which has amazing documentation, not just for the API, but also for guides that tell you how to do stuff like add routes, add authentication, do advanced queries [2], etc, the Phoenix guides are missing a lot.
It took me until I actually read an entire book about Phoenix (Programming Phoenix 1.4 [3], which I do recommend) before I actually got onboard with it. And while there's nothing wrong with reading a book, it is a significantly higher barrier to entry compared to something like Django or Rails, frameworks which a beginner can be taught the basics of in a single day just by browsing through the official documentation.
Now, with all that being said, I really do enjoy working in Phoenix now that I actually "broke through" that initial barrier of understanding. It and Elixir are very well thought out and pleasant to work with, even if they do take a little bit of extra effort to get started.
> However, I find it to be very lacking in terms of guide/tutorial content.
I found this to be the case too, but the community is very helpful on the forums and IRC. Everyone is really friendly and doesn't troll you for being new.
My way of learning so far has been to take in the docs to get the basics, stumble and fumble around on my own, look at code from open source projects, experiment with those things in my app and then as a last resort ask for help from one of the community outlets if I get legit stuck on something or have a question on best practices that I couldn't find online. It's been working out so far, but it's definitely a much more difficult road than binge watching 100 railscasts videos because every feature you want in your app has been designed in a production ready way and perfectly explained on video (that's how I learned Rails in about 3 months while building a quite involved app as my first "real" Rails app a number of years ago).
But like you said, I also came to the realization that Elixir and Phoenix might be one of the most well thought out combinations of software I've ever used for building web apps. Although at times, I do wish I could invent a time machine and fast forward 2 years to see where everything is at.
> though ironically it doesn't look like Sugar uses hexdocs
Indeed it does not. I should probably fix that :)
(Much like how I also need to fix that for OTPCL...)
> it is a significantly higher barrier to entry compared to something like Django or Rails
I don't know about Django (I tend to shy away from Python, and the little Python code I do voluntarily write is specifically for desktop apps via PyQt5), but I'd say Rails has just as steep of a learning curve, if not steeper (or at least it did when I was deep into Rails app development).
> Now, with all that being said, I really do enjoy working in Phoenix now that I actually "broke through" that initial barrier of understanding.
Same here. I "broke through" via a much different path, though, going through Sugar then Plug then bottom-up into Phoenix. Turns out both Sugar and Phoenix stick very close to Plug (unsurprising, since they're both essentially collections of plugs arranged into MVC frameworks), so there's actually a surprising amount of compatibility between the two, both in terms of knowledge/semantics and even outright code interoperability [1] (at least for simple cases). Made it easy to remap my Sugar-centric mental model to Phoenix and comprehend "oh, okay, so that's how that works" or "so that's why I need to do this or that".
One of these days I should probably make a concerted effort to document the similarities/differences between Sugar and Phoenix and describe/demonstrate how one can at least mentally migrate between the two, both for selfish reasons (i.e. convince Phoenix users to try Sugar) and for more community-holistic reasons (i.e. position Sugar as a "gateway drug" to Phoenix).
Ive been waiting for a tutorial like this. I am most likely doing something wrong, but sadly the code samples do not function as listed. Even cloning the repo and executing the commands listed only results in errors after the first step.
But the article is about phoenix from nothing. The reader is encouraged to work through each literate commit. Mix is not used until half way through the article.
Phoenix framework for the Elixir language. It's a web framework that leverages the natural concurrency and performance structure of the Erlang VM to handle both standard web development and web sockets.
That's the high altitude view.
In my professional opinion, Elixir and Phoenix also address the vast majority of short and long term issues that cause problems in projects without a negative impact on developer productivity. I'm a big believer it both. It's also got the perk of being so lightweight that there's almost no performance impact to using Phoenix instead of raw Elixir.
In all fairness it's been around for quite some time.
Moreover, the abundance of frameworks is not inherently a bad thing in my opinion. You don't need to learn it if it doesn't solve a problem for you after all.
I'm not agreeing with the GP's attitude about more frameworks. In fact, I really enjoy working with Phoenix and am glad the author(s) put in the hard work to build it.
But
> You don't need to learn it if it doesn't solve a problem for you after all
is not true. I don't like React and I have to use it at work because that is what was chosen.
React is nigh-universally agreed to solve a set of problems related to frontend web development. You may not recognize the pain of those problems and it may not solve them the way you like it, but the way you've attacked the sentence is really strange.
What if you could eliminate a lot of the pain points that React solves but without having to write much (if any) Javascript but still have an application that feels like it's rendered client side while getting server side rendered templates for free, and things like "but I can share my logic between the backend and frontend" goes away because the backend can do both?
This is just one type of problem that Phoenix's LiveView solves and LiveView is only a small aspect of what Phoenix has available. I'm very thankful work is being done in this area instead of just accepting that everyone wants to use React.
Whether or not you like React, the point is that it's solving a problem. Maybe not for you, but (I'd like to believe) at the very least for some of your colleagues.
True that whether I like it or not doesn't matter in a business and team sense. I should have phrased my comment better.
I don't believe it is solving a problem. It's creating unnecessary complexity. The app is just a typical CRUD app. Traditional server side rendering would be fine in my opinion. Or perhaps coupled with LiveView or TurboLinks, and Stimulus.js.
Btw, this is not so much a knock on React specifically, but on the overuse of the SPA paradigm [1]
So in conclusion, using React in this case (in my opinion) doesn't solve a problem and yet I need to use it.
It's comical how the FA jumps right in assuming you know what it is, what it's for, and why you should care about the first two -- comical in a good way, for those of us who are happier not knowing.
I have a vague impression that Elixir has something to do with Erlang, and that is all I need to know, but that Phoenix has something to do with Elixir also wasn't mentioned right away.
I really wish this tutorial existed 5 years ago. It would've convinced me to actually try Phoenix instead of pulling up the official getting started guide only to scream internally at all the moving parts and start looking for alternatives.
But on the other hand, had this tutorial existed 5 years ago, I wouldn't have found Sugar (sugar-framework.github.io), and in turn wouldn't have started contributing to it, and in turn wouldn't have gone on the various deep dives into OTP and Plug necessary to comprehend it, let alone become one of the maintainers of it (albeit a rather neglectful one; this year's New Years Resolution is to address some longstanding bugs and get it back into a state where it could actually be to Phoenix as, say, Padrino is to Rails or Flask is to Django), so I guess it ain't all bad :)
I hear ya. I think Hexdocs is great and I really appreciate the standardization of the Elixir community on one documentation format/site (though ironically it doesn't look like Sugar uses hexdocs), and in particular it's great at listing the various functions/modules etc within a package. However, I find it to be very lacking in terms of guide/tutorial content, and the Phoenix guide [1] is a great example of how it falls short. Compared to stuff like Django, which has amazing documentation, not just for the API, but also for guides that tell you how to do stuff like add routes, add authentication, do advanced queries [2], etc, the Phoenix guides are missing a lot.
It took me until I actually read an entire book about Phoenix (Programming Phoenix 1.4 [3], which I do recommend) before I actually got onboard with it. And while there's nothing wrong with reading a book, it is a significantly higher barrier to entry compared to something like Django or Rails, frameworks which a beginner can be taught the basics of in a single day just by browsing through the official documentation.
Now, with all that being said, I really do enjoy working in Phoenix now that I actually "broke through" that initial barrier of understanding. It and Elixir are very well thought out and pleasant to work with, even if they do take a little bit of extra effort to get started.
1: https://hexdocs.pm/phoenix/up_and_running.html
2: https://docs.djangoproject.com/en/2.2/contents/
3: https://pragprog.com/book/phoenix14/programming-phoenix-1-4
> However, I find it to be very lacking in terms of guide/tutorial content.
I found this to be the case too, but the community is very helpful on the forums and IRC. Everyone is really friendly and doesn't troll you for being new.
My way of learning so far has been to take in the docs to get the basics, stumble and fumble around on my own, look at code from open source projects, experiment with those things in my app and then as a last resort ask for help from one of the community outlets if I get legit stuck on something or have a question on best practices that I couldn't find online. It's been working out so far, but it's definitely a much more difficult road than binge watching 100 railscasts videos because every feature you want in your app has been designed in a production ready way and perfectly explained on video (that's how I learned Rails in about 3 months while building a quite involved app as my first "real" Rails app a number of years ago).
But like you said, I also came to the realization that Elixir and Phoenix might be one of the most well thought out combinations of software I've ever used for building web apps. Although at times, I do wish I could invent a time machine and fast forward 2 years to see where everything is at.
> though ironically it doesn't look like Sugar uses hexdocs
Indeed it does not. I should probably fix that :)
(Much like how I also need to fix that for OTPCL...)
> it is a significantly higher barrier to entry compared to something like Django or Rails
I don't know about Django (I tend to shy away from Python, and the little Python code I do voluntarily write is specifically for desktop apps via PyQt5), but I'd say Rails has just as steep of a learning curve, if not steeper (or at least it did when I was deep into Rails app development).
> Now, with all that being said, I really do enjoy working in Phoenix now that I actually "broke through" that initial barrier of understanding.
Same here. I "broke through" via a much different path, though, going through Sugar then Plug then bottom-up into Phoenix. Turns out both Sugar and Phoenix stick very close to Plug (unsurprising, since they're both essentially collections of plugs arranged into MVC frameworks), so there's actually a surprising amount of compatibility between the two, both in terms of knowledge/semantics and even outright code interoperability [1] (at least for simple cases). Made it easy to remap my Sugar-centric mental model to Phoenix and comprehend "oh, okay, so that's how that works" or "so that's why I need to do this or that".
One of these days I should probably make a concerted effort to document the similarities/differences between Sugar and Phoenix and describe/demonstrate how one can at least mentally migrate between the two, both for selfish reasons (i.e. convince Phoenix users to try Sugar) and for more community-holistic reasons (i.e. position Sugar as a "gateway drug" to Phoenix).
----
[1]: https://sugar-framework.github.io/docs/tips-and-tricks/ § "Phoenix Compatibility"
Ive been waiting for a tutorial like this. I am most likely doing something wrong, but sadly the code samples do not function as listed. Even cloning the repo and executing the commands listed only results in errors after the first step.
Author has provided the link to git repo in the article. All you have to do is,
git clone https://github.com/pcorey/minimum_viable_phoenix
mix deps.get
mix compile
mix phx.server
and you're good to go
But the article is about phoenix from nothing. The reader is encouraged to work through each literate commit. Mix is not used until half way through the article.
I really like this style of "literate commits".
What is Phoenix?
Phoenix framework for the Elixir language. It's a web framework that leverages the natural concurrency and performance structure of the Erlang VM to handle both standard web development and web sockets.
That's the high altitude view.
In my professional opinion, Elixir and Phoenix also address the vast majority of short and long term issues that cause problems in projects without a negative impact on developer productivity. I'm a big believer it both. It's also got the perk of being so lightweight that there's almost no performance impact to using Phoenix instead of raw Elixir.
It's the most popular web framework for Elixir.
It's MVC-ish with the caveat that the Model is broken down into two files, context and schema.
From what I've gathered, it also offer three unique things compare to other framework (on top of the power of Erlang's VM).
1) Channel - easy integration with websocket
2) Presence - some advance thing that keep track of people online
3) LiveView - In beta-(ish?) It's a compromise between front end framework.
Do note I haven't had the chance to use 2 or 3. I did a little of 1 as a tutorial.
Given there is an active Apache project called Phoenix (https://phoenix.apache.org) I think confusion here is warranted.
This is a really great idea and well executed. Thank you.
Meanwhile it still doesn't have Authn/Authz built-in.
It's a deliberate decision to not impose any set authn/authz structure on the user as many projects have differing requirements in that area.
Maybe someone could make a project creator on top of Phoenix that adds some basic authn/authz to the default structure.
Another framework. May merciful Providence deliver us.
In all fairness it's been around for quite some time.
Moreover, the abundance of frameworks is not inherently a bad thing in my opinion. You don't need to learn it if it doesn't solve a problem for you after all.
I'm not agreeing with the GP's attitude about more frameworks. In fact, I really enjoy working with Phoenix and am glad the author(s) put in the hard work to build it.
But
> You don't need to learn it if it doesn't solve a problem for you after all
is not true. I don't like React and I have to use it at work because that is what was chosen.
React is nigh-universally agreed to solve a set of problems related to frontend web development. You may not recognize the pain of those problems and it may not solve them the way you like it, but the way you've attacked the sentence is really strange.
What if you could eliminate a lot of the pain points that React solves but without having to write much (if any) Javascript but still have an application that feels like it's rendered client side while getting server side rendered templates for free, and things like "but I can share my logic between the backend and frontend" goes away because the backend can do both?
This is just one type of problem that Phoenix's LiveView solves and LiveView is only a small aspect of what Phoenix has available. I'm very thankful work is being done in this area instead of just accepting that everyone wants to use React.
I mean, cool, great. I like React and I like TypeScript more than I like Elixir so that does nothing for me, but great.
But I'm not sure why you replied to me.
Ostensibly, because it helps to solve the problems you've been hired to solve...
Whether or not you like React, the point is that it's solving a problem. Maybe not for you, but (I'd like to believe) at the very least for some of your colleagues.
True that whether I like it or not doesn't matter in a business and team sense. I should have phrased my comment better.
I don't believe it is solving a problem. It's creating unnecessary complexity. The app is just a typical CRUD app. Traditional server side rendering would be fine in my opinion. Or perhaps coupled with LiveView or TurboLinks, and Stimulus.js.
Btw, this is not so much a knock on React specifically, but on the overuse of the SPA paradigm [1]
So in conclusion, using React in this case (in my opinion) doesn't solve a problem and yet I need to use it.
[1] https://news.ycombinator.com/item?id=19134260, https://news.ycombinator.com/item?id=19184496, https://news.ycombinator.com/item?id=19905004
Hmm? You haven't heard of Phoenix/Elixir? It's mentioned on HN fairly often.
No, I haven't.
It's comical how the FA jumps right in assuming you know what it is, what it's for, and why you should care about the first two -- comical in a good way, for those of us who are happier not knowing.
I have a vague impression that Elixir has something to do with Erlang, and that is all I need to know, but that Phoenix has something to do with Elixir also wasn't mentioned right away.
It’s the only framework with significant usage in Elixir. I don’t think one framework per language is excessive.