I think you nailed the two near-future aspects:
- 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.
- 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.