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).
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 :)