Live data from Hacker News

Minimum Viable Phoenix

petecorey.com

11–20 of 29 posts

Re: Minimum Viable Phoenix

#11
post #3
post #2

Another framework. May merciful Providence deliver us.

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.

Re: Minimum Viable Phoenix

#12
post #9

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.

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.

Re: Minimum Viable Phoenix

#15
post #10

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.

Re: Minimum Viable Phoenix

#16
post #12
post #9

Earlier quoted context omitted.

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

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.

Re: Minimum Viable Phoenix

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

Re: Minimum Viable Phoenix

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

Post reply on HN