Give the recent release I would like to say I think I’m ready to to start a project that forks Phoenix that focuses only on the following when running phx.new.
configs
endpoint
Phoenix.LiveView.Router
Phoenix.Controller
Phoenix.Component
Phoenix.Html
Phoenix.Channel
Gettext
Maybe some of the phx.gen but if I’m honest I only care about the phx.gen.auth but without scopes or the coupling to core components and tailwind
What I want to avoid in this fork.
LiveView/LiveComponents
EsBuild/Tailwind/Daisy
LiveReload
LiveDashbord
Telemetry
Rest of the phx.gen
Core Components.
Placeholder html and tailwind css classes.
.link and phx- bindings
I find myself even if using --no-assets doing so much to remove these concerns and the direction live view has on phoenix in the last few releases just does not feel like we have good boundaries between theses areas of concern when starting a new project.
I mostly want to start this because I want to be more JS / CSS ./ Asset pipeline agnostic and start with bare bones html and start to be additive vs subtractive when starting a new phx app.
Thus the best thing that comes to mind is Sintra / Flask.
its like when we all migrated from rails and some of us thought “lets re invent active support” and others pushed back and said “We don’t want to keep adding more to this framework”
I feel we have past the point of reinventing active support.
Please don’t take offense to this, I love the hard work you all have done and put into phoenix and liveview.
I personally like liveview, but I also love clean and hard boundaries.
I only want liveview when I want liveview and I think that is the main issue I take now with phoenix the most with each new release.
I feel like the FOMO with each release pushes me to want to change things that have little change for features I’m personally not interested in. My hope is that since the core logic of phoenix is solid at this point there will be less new release because from the looks of it most of the work that’s been happening is really outside of the ares I want to focus on the most.
Phoenix is a full-fledged web framework, and Sinatra and Flask are micro-frameworks. It’s perfectly fine if you’re personally looking for a micro-framework, but that’s not what Phoenix is designed to be – it’s a different beast altogether.
You don’t need to fork phoenix just to have different generators. phx_new is a separete package. You can create your own generators alongside all the existing stuff. I’ve heard many people who would love to have an igniter based phoenix installer, which would allow for greater flexibility, but it’s also a lot of work to redo where the code already exists.
As @LostKobrakai said you don’t need to fork Phoenix, like I didn’t to create the Elixir Scribe tool with new generators.
If you take a look to lib/mix/tasks on my tool you can understand how you can create your new generators, that will use the templates located at priv/templates.
As LostKobrakai advised I would use Igniter to achieve whatever is necessary with the generators, which I didn’t use at the time because Igniter wasn’t yet released.
You have done that (trim to bare bone) once, right? I see nothing wrong of reusing that starting point over and over again. I myself is not a big fan of any project generators and have not run any in years.
I don’t really see it tbh. Pretty much everything on your list to remove is stuff that you can easily turn off even in phx_new. A lot of the functionality is located in separate packages (like the dashboard). If you want a cleaner “new project” wouldn’t it be better to write your own generator instead of forking the entire framework?
Also the problem with this is that your list is so arbitrary. Like, I have zero interest in Tailwind (and now Daisy) and I also nuke core_components immediately. But why would I want to remove LiveReloader?!
The point being: everyone is going to have slightly different preferences for what to enable, so in the end you will end up with a list of flags just like phx_new
I didn’t do a good job of phrasing my intent. I guess the use of fork was not a good way to describe my intent.
Regardless I started down the path of creating a new version of Phoenix.New that is specific to my concerns and I got a working first pass so I’m happier now.
I will need to keep working on it. but I think its a good first pass.
With Mix.install and Plug.Cowboy you can do a single-file HTML server:
#!/usr/bin/env elixir
Mix.install([
{:plug_cowboy, "~> 2.5"}
])
defmodule Router do
use Plug.Router
plug(Plug.Logger)
plug(:match)
plug(:dispatch)
get "/" do
send_resp(conn, 200, "Hello, World!")
end
match _ do
send_resp(conn, 404, "not found")
end
end
plug_cowboy = {Plug.Cowboy, plug: Router, scheme: :http, port: 4000}
require Logger
Logger.info("starting #{inspect(plug_cowboy)}")
{:ok, _} = Supervisor.start_link([plug_cowboy], strategy: :one_for_one)
# unless running from IEx, sleep idenfinitely so we can serve requests
unless IEx.started?() do
Process.sleep(:infinity)
end
