Phoenix has generators for each main part of building an app.
And some packages have their own commands we can use.
I like the unix philosophy of small apps that do different services/jobs/tasks, but I also like FreeBSD because it has nice integration across its structure, easy installation of ports, and configuration overall.
To me this framework and elixir are a dream to learn in - everything feels really well thought out.
It was really cool to see a video of a meet recently where someone showed a preview of the frameworkās new time related helpers(?).
Could it be possible for mix to be able to do this in future - if Phoenix not only embraces the unix way but also freebsdās - of integrating and increasing and where possibly making as simple as possible services etc.
Thinking about the roadmap for Phoenix Framework, would be possible to someday, perhaps, have enough mix ātasksā that can help to generate an app - all as part of an alternative branch or mix install 'mix archive.install https://github.com/phoenixframework/archives/raw/master/phoenix_new.**super**-duper-ez ?
-
Would this be possible without breaking package compatibility between the two?
-
Would this make Phoenix as bloated or annoyingly opinionated as Laravel?
-
Would this be worthwhile to help noobs get started and build adoption of Phoenix Framework?
If the developer could choose to generate 1-3 Basic Apps eg a static site, a signin/session-less app, and one with a user and admin accounts, enough other mix tasks for creating the components of each of those apps (and new types of app), and a way for the community and founders to decide on what could/should/will go into the next release of mix to work the phoenix framework to generate more advanced apps etc, would be interesting.
Then we could share mix tasks as workflows online to build the basic templates for apps we want to start an app with.
Perhaps Iām just feeling Iām getting busier and that idea and others I have already imagined (as many of us likely have) to help make apps faster, better, and hopefully as friendly, fun, and financially profitable as possible, are more fitting to a framework like Laravel that isnāt pushing the envelope in regards to performance speed, reliability, and scalability as Phoenix Framework is, and is making up for that by trying to make PHP more fun, standardised, and fast to work with.
I hope Phoenix Framework will also set some big challenges for its evolution in respect to being fast to work with - not just fast to run.
Iām finding it quite fast to learn and fun, but wonāt be pushing the envelope in my first app - I just want to get it built, including the basics like user login/sessions/admin user management etc.
Iām getting there - learning about sessions as I look at packages/libs like Coherence, tutorials, etc - but itād be really neat to have a āversionā of phoenix framework or āofficialā pacakge for creating the basics like auth etc that sets things up either a simple way like all in the same app eg users and admin, or set up as umbrella appsā¦ using the optimal/opinionated way of using GenStage etc and the OTPā¦ so the apps ājust workā and community/third party packages could be built on those āstandardsā.
Then it would easier to learn, modify, and build out too - because even noobs like me could find the current version of docs for how auth works, how it must work with third party packages that modify or extend it, and customise it for our own needs within the āstandardā.
I guess itās not that unlike how strict Appleās stuff is, and how they break each part of the app into ākitsā eg UIKit. Could we do the same for basic core parts of a phoenix framework āexamples of the standard way of coding with phoenix framework, elixir, and the OTPā apps?
While being developer friendly, simple to use, and powerful as generators that can be run in series - procedurally - to build apps?
But I return to my questions above, and wonder if Iāve answered my own first question already - and if this community would want two branches of packages, because who would write for both types of package - the one for phoenix framework without the built in packages for auth (whether written by the founders or an existing package creator/contributor) etc - or the one with auth etc as a mix archive.install or mix switch/option?
What do you think?
