Au contraire, it absolutely is not just you. That is in fact the very reason I willingly gave up my “full stack dev” title some 6 or so years ago. It is soul-crushing to reinvent the same things all the time, over and ever again, always with the ever-to-elusive “only 1% different from the previous file or project” mysterious beast that we can’t seem to ever be able to catch, cage and tame forever.

I’ll not comment on concrete solutions because I don’t have them – I am out of the loop for years. I grumble when I have to do anything more than create / edit 20+ lines of .html.eex files. I just hate it. I can do it just fine but I hate it. It got so bad that as recently as ~7 weeks ago when I had a simple task of adding a few controller actions with views and templates I completely froze and it took me 5 days. Not one of my proudest moments for sure.

The mere fact that we can’t manipulate the glue code of our project – meaning 99% of the Phoenix code in our projects – using commands on the terminal is to me insulting. I know we have generators but they only work one way; sure you’ll generate your stuff but do you have a command like mix phx.controller.parameter.add or mix phx.controller.parameter.change_type (which will create/update a boilerplate validation) or such? Of course not.

This is not bashing Phoenix at all. Phoenix seems to be, in my anecdotal and limited experience, one of the best web frameworks out there. This is more a rant against the entire industry…

IMO most of the web glue code – again, Phoenix controllers, views, templates, helpers, but also Ecto schema modules and even migrations – should be editable with special-tailored terminal commands. Our code editors should not be involved. That’s what I’d call productive.

But… yeah. At least in the meantime many young people can get a taste of what it is to belong to the upper middle class by making money through repeating the same incancantions 500 times until they burn out.

(Also, let’s be friends! You seem to have almost the same gripes as myself and you seem to approach the problem similarly as well.)

I’m a very happy user of Surface. My app is a classic server-side rendered Phoenix app (I only use “dead views” - no LiveView stuff). Here’s the markup for a message template index page:

<App conn={@conn} active_link="Templates">
  <PageTitle text="Message templates">
    <PageTitleLink
      type="primary"
      to={Routes.template_path(@conn, :new)}
      icon="plus"
      label="New"
    />
  </PageTitle>

  <div class="flex flex-wrap p-8 gap-8">
    {#for template <- @templates}
      <div class="flex-shrink-0">
        <TemplateCard conn={@conn} template={template} />
      </div>
    {/for}
  </div>
</App>

Here’s a breakdown of the components:

• App: the application shell with the sidebar nav; highlights the active link,
• PageTitle: top bar with the title of the page, optional links and tabbed nav,
• PageTitleLink: CTA button or a back button,
• TemplateCard: a clickable card with a preview button.

Bringing component system from SPA frameworks is a game changer for me.

I love Tailwind, but my main gripe with it is that it makes the HTML very hard to read (e.g. plain unstyled form vs fully styled form). Components allow me to encapsulate all the markup that only changes the look.

In addition to the libraries like Surface, Temple, and LiveComponents, you can create your own components using the plain old render/3 function.

From inside your main template, you can render another template:

web/controllers/fruit_controller.ex:

defmodule Web.FruitController do
  use Web, :controller

  def index(conn, _params) do
    render(conn, fruit: GroceryStore.all_fruit())
  end
end

web/templates/fruit/index.html.slim (slime):

h1 Fruit

= render Web.TableView, "table.html", id: "all-fruit", columns: [{"Name", :name}, [{"Rating", :rating}], data: @fruit

web/views/table_view.ex:

defmodule Web.TableView do
  use Web, :view
end

web/templates/table/table.html.slim:

table id=@id
  thead
    tr
      = for {title, _key} <- @columns do
        th= title

  tbody
    = for datum <- @data do
      tr do
        = for {_title, key} <- @columns do
          td= datum[key]

assets/css/app.sass:

@import "components"

table#all-fruit
  @include data-table($padding: 1rem)

assets/css/components.sass:

@mixin data-table($padding: 0.5rem)
  td, th
    font-size: 14px
    padding: $padding

  th
    background-color: blue

So now you’ve got a reusable, parameterized table component to render HTML, and a reusable, parameterized Sass function to render CSS. That should give you a nice combination of reuse and customizability.