Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minimum Viable Phoenix

petecorey.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Minimum Viable Phoenix

#21

Post by txcwpalpha »

yellowapple wrote: post #20

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…

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

Re: Minimum Viable Phoenix

#22

Post by nickjj »

txcwpalpha wrote: post #21
yellowapple wrote: post #20

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…

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 f…

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

Re: Minimum Viable Phoenix

#23

Post by theonething »

nicolas_siplis wrote: post #7
theonething wrote: post #5

Earlier quoted context omitted.

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.

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

Re: Minimum Viable Phoenix

#24

Post by yellowapple »

txcwpalpha wrote: post #21
yellowapple wrote: post #20

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…

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 f…

> 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"

Re: Minimum Viable Phoenix

#25

Post by anthony_doan »

gojomo wrote: post #10

What is Phoenix?

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.

Re: Minimum Viable Phoenix

#27

Post by bluegene »

dve wrote: post #18

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

Re: Minimum Viable Phoenix

#28

Post by Ndymium »

sansnomme wrote: post #26

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.

Re: Minimum Viable Phoenix

#29

Post by dve »

bluegene wrote: post #27
dve wrote: post #18

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.
Post reply on HN