There are no plans to extract it at the moment but I also want to point out that “without pulling LiveView related code that I don’t use” is most likely a micro-optimization. I just checked LiveView source code and at the moment it defines 57 modules. Plus a quick estimate shows that roughly half of these modules (~28) have Engine/HEEx functionality. That is tiny compared to the number of modules you will have in your application. For example, Livebook has 959 modules, and that’s not counting the ones coming from Elixir or Erlang/OTP. Therefore, it is hard to see how “not pulling LiveView-related code” is going to give any meaningful benefit.

One could argue that, if you don’t care about LiveView, having to debug only the HEEx bits is going to be easier, and I would agree with that. But that comes at the cost of putting a layer (and a dependency) between LiveView and HEEx, which will make the lives of everyone using, maintaining, and debugging LiveView - which is perhaps the majority - much harder. So the costs are really hard to justify here.

And it is not like we are averse with breaking things apart. We extracted Phoenix.HTML, Phoenix.PubSub, and Phoenix.View/Template (the latter pretty much based on user demand) in the past. And it actually has led to the downside of fragmenting the documentation - which is a complaint that needs to be addressed… So breaking LV+HEEx might happen in the future but 99% not worth it now.

I’m using heex as a template engine to create PDFs. Was using py/jinja2 before and I have to say (as objectively as i can express myself) heex is easily 1000 times better. But its really good hidden in LV. If you want to use it - and can’t use embed_templates - you have to

  require EEx

  source = "sample.html.heex"

  EEx.function_from_file(
    :def,
    :sample,
    source,
    [:assigns],
    # Phoenix.LiveView.HTMLEngine pre 0.18
    engine: Phoenix.LiveView.Engine,
    caller: __ENV__,
    source: source
  )

  def render(assigns) do
    sample(assigns) |> Phoenix.HTML.Safe.to_iodata() |> to_string()
  end

which is not obvious and not documented at all.

You’d really make the world a better place if you’d free heex and treat it as a general purpose template engine.
Maybe when LV hits 1.0?

I agree that having phoenix_live_view as a necessary dependency in a Phoenix application is a pragmatic choice. I’ve had to worked with over-factored applications before in other languages and I agree it is laborious to coordinate changes across packages that can take the joy out of programming.

For my specific case, I want to use Heex without using Phoenix at all, which I should have mentioned in my reply. I have the beginnings of a single-script-file static site generator that I coded up today that uses heex for templating. Because phoenix_live_view also depends on phoenix, my “static site generator” ends up also bringing in Phoenix and its dependencies as well.

iex(1)> Mix.install([:phoenix_live_view], force: true)
Resolving Hex dependencies...
Resolution completed in 0.332s
New:
  castore 1.0.1
  mime 2.0.3
  phoenix 1.7.2
  phoenix_html 3.3.1
  phoenix_live_view 0.18.18
  phoenix_pubsub 2.1.1
  phoenix_template 1.0.1
  plug 1.14.2
  plug_crypto 1.2.5
  telemetry 1.2.1
  websock 0.5.1
  websock_adapter 0.5.1

It would be nice if it is broken out one day, but also understand if it isn’t, or if it takes a while. Certainly won’t stop me from using it till then . It really is a great templating language.