I’m not sure about anyone else, but I’ve been more than content with the promise of Phoenix; a fast, highly scalable and productive (i.e. enjoyable!) web framework. So I haven’t really been thinking about a Phoenix wish-list since it’s already giving me what I wanted.
LiveView changed that! 
So that got me thinking - what else is there that we might love to be in Phoenix - no matter how big of a leap or a dream it might be 
For me, so far Phoenix ticks two of the boxes (speed/scalability, and soon, making front end easier thanks to LiveView) and the only other thing that would make me even more ecstatic is… doing something similar for Mobile! Imagine if we could create native mobile apps (even if just via their web view - like some of the current Mobile frameworks) as easily as what LiveView is going to enable us to do for web apps? How cool would that be? 
Wonder if we all chip in and buy Chris a pack of these each it might actually happen? 
I think you nailed the two near-future aspects:
What I would like to see in Phoenix next would be something a bit more academic: state machines. For example, I already coded orders, carts, line items, fulfillment etc. e-commerce details in PHP, Ruby and Elixir about 12-13 times in the last 5 years already. And the truth is, a rather straight-forward (if a bit hard to express and code initially) state machine would have eliminated most bugs right from the get go. No small amount of real-world abstractions can be coded with state machines. Of course, the trouble comes when you have to ask the question: “alright this is so well working and abstracted now but what about special cases X, Y and Z?” – and there’s always something like that happening. Not sure I have a good solution for that yet.
why would you want it in Phoenix? Erlang has it so we can use it right now http://erlang.org/doc/man/gen_statem.html but all in all imo it’s somewhat low level for a web framework.
Exactly because of what you said – it’s low level and if we have more first-class-citizen support that would help us reduce bugs.
But it’s mostly just a desire without me giving it much thought yet. Elixir is pretty good at making DSLs so I imagine that would be the easy part. How would that integrate with the rest of Phoenix and not confuse people however, would definitely be much more challenging.
As a side note there is an Elixir wrapper for gen_statem.
Well wouldn’t it make sense to just use the Erlang’s one “under the hood” in the services that need it and expose the public API for Phoenix related parts (channels, controllers etc.)? 
As of today, yes, of course it does. This still entails the mandatory steps of you devising a flow using REST / GraphQL / something-else which will utilize the state machine under the hood. My point here is to have a SM + Phoenix implementation that can generate routes and “controller” (state movement?) functions, allowing you to plug custom code at places, all the while keeping all the SM + network delivery mechanisms (again: REST / GraphQL / what-have-you) cruft to a minimum.
The curse of digging a bit deeper into the scientific part is beginning to notice how the world invents and reinvents wheels all the time, and stumbles at the same problems almost every time. So this is just a generic high-level laundry wish-list borne from that feeling.
OK, I understand, though I’d rather implement it myself using low level functionality then have it in Phoenix - it would be way too magick-y otherwise.
There is definitely some truth to that
I sympathize with that point of view. I myself also don’t want the feeling of “things just somehow work” that I got when I was working with Rails. Functional languages’ explicitness is a a huge breath of fresh air for the brain.
Having an optional SM would be the optimal solution – an “advanced” tool for whoever has the experience to use it. However, having a bunch of optional features can only make the framework complex and confusing with time so it’s probably for the best for this to be a community project and not a part of Phoenix…
Well, that’s a +1
I see phoenix as feature complete - I’d rather new ideas be tackled in other projects. Even if the aim is to tightly couple some idea with phoenix it would be nice to see stuff namespace’d outside of phoenix so other projects could come along and make X new project pluggable to break off the coupling to phoenix and then Y project could bring X project under its own umbrella of easily integrated tooling
© Copyright Elixir Forum | Terms | Privacy & Cookies
