What would you like to see in a future version of Phoenix?

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?

https://twitter.com/chris_mccord/status/1039190145927454720

I think you nailed the two near-future aspects:

1. Making a perfect blend between Drab, LiveView and Phoenix semantics. It’s really not surprising that frameworks like Drab exist; frontend is a nightmare environment due to JS flakiness (a huge topic in itself) and eventually people just go like “screw this, let’s do something close enough that’s much more maintainable and productive!”. I am so glad LiveView got introduced.
2. Starting to aim for mobile. IMO that’s a huge challenge on all platforms and languages. Go is trying and so far they have some success but for our branch to succeed we need a full-blown BEAM working on Snapdragon and Exynos chipsets, and iDevices. Not sure how hard that is, probably a lot. Not to mention that both Android and iOS development isn’t exactly perfectly streamlined (although tools are improving regularly). Bonus points for actual Kotlin and Swift bindings to make the two-way interaction between Android/iOS and the BEAM inside the mobile ecosystem easier.

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 gen_statem — OTP 29.0.2 (stdlib 8.0.1) 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.

https://github.com/ericentin/gen_state_machine

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