Phoenix 1.6.0-rc.0 released!

I’d actually thought of the extra EEx tags after I asked the question but figured I’d just leave my question as it was. I’m actually quite happy with this decision as I like EEx tags but see the {} in attributes as a big win. I was just wondering what made the Phoenix team not take this “all the way”. It shows some good restraint!

yeah TBD on more components. We simply didn’t have enough time to arrive there but definitely on our list :slight_smile:


Ansioso pra usar :heart_eyes:

1 Like

So I just gave this a try.
--live does not generate a LiveView anymore, so I was forced to RTFM :anguished:.
So for all other lazy newbies, here’s what’s to be done to get a minimal liveview running:

mix hello --live --no-ecto

add lib/hello_web/live/hello_live.ex

defmodule HelloWeb.HelloLive do
  use Phoenix.LiveView

  def mount(_, _, socket) do
    {:ok, assign(socket, :attrs, %{})}

  def handle_event("hide", _, socket) do
    {:noreply, assign(socket, :attrs, %{"style" => "display: none"})}

  def handle_event("show", _, socket) do
    {:noreply, assign(socket, :attrs, %{})}

  def render(assigns) do
      <button phx-click="hide">hide</button>
      <button phx-click="show">show</button>
      <div {@attrs}>Welcome to Phoenix!</div>

change this in lib/hello_web/router.ex

  scope "/", HelloWeb do
    pipe_through :browser

-    get "/", PageController, :index
+    live("/", HelloLive)
mix phx.server

Important: do not just count the lines output by this call and think its stuck for half minute… :thinking:
It just takes no time to startup. :star_struck:


For completeness, you can totally use npm with esbuild. If you call “npm install topbar” inside the assets directory after and then import topbar, it will 100% work. :slight_smile:

You only need to migrate esbuild itself to npm if you need plugins, which we detail here: Asset Management — Phoenix v1.6.0-rc.0


This is why I felt the decision to remove node from the base setup has been a great leadership decision. Once, node is in - why just esbuild via npm? why not webpack? why not snowpack? why not vitejs ? The options will be too many with no clear winner.
If going via the npm route - I would think instead of esbuild, better to go with vitejs, as vitejs uses esbuild under the hood and we get even postcss support right away. Just for the record A proof-of-concept integration of Vite.js (modern JS/assets bundler) with Phoenix + Liveview - #2 by 50kudos this post worked well for replacing webpack with postcss. The performance in development looked similar to what we are getting via esbuild.

After that i upgraded Phoenix 1.6 and LiveView 0.16.1 i have this issue:
in a LiveView template heex there is this code:

<%= for i <- @topics do
	render "topic.html", topic: i				        
end %>

if i launch my webapp i receive this error:

** (ArgumentError) lists in Phoenix.HTML and templates may only contain integers representing bytes, binaries or other lists, got invalid entry: %Phoenix.LiveView.Rendered{dynamic: #Function<4.81847032/1 in SWeb.CommentView.“topic.html”/1>, fingerprint: 98279643322116372238403084114730099928, root: false, static: ["\n", “”]}

I tried also with render_many but is the same.

How can i do?

Crap, ~10 years in dev and I still can’t properly RTFM :slight_smile: Thanks for the link!

Btw I’ve noticed that the build.js script from docs doesn’t pass minify: true to a production build and doesn’t enable inline sourcemaps for watch, which may be a painful omission for those that’ll just copy&paste (both of these are covered by default phx_new app).

I’ve created pull request to improve the guide a bit: Improve esbuild plugins guide by karolsluszniak · Pull Request #4457 · phoenixframework/phoenix · GitHub</title.


You should probably delegate to Phoenix.View…

Phoenix.View.render ViewModule, “topic.html”, topic: i

But now You should use function components.

def display_topic(assigns)

The problem is that this doesn’t work with heex:

<%= for i <- @topics do
	render "topic.html", topic: i				        
end %>

But this is ok:

<%= for i <- @topics do %>
	<%= render "topic.html", topic: i %>				   
<% end %>

After upgrading my 1.5 apps (with tailwind) to 1.6, I eventually ran into an error pushing the new commits to Heroku:

sh: 1: npm: not found

This forced me to dig a little deeper into the buildpacks for Elixir and Phoenix, and after learning quite a bit, I realized the fix was simple. But it seemed like a nice opportunity to write up another quick blog, as a complement to the official deployment guide, which received a nice update for 1.6, but assumes no npm is required.

Deploying to Heroku with Phoenix 1.6 and TailwindCSS

Please let me know (privately, as to not clutter this thread) if you have any feedback about this blog or how it could be improved.


Hi, I’m wondering if someone can help me through a small obstacle. I’m reading through the upgrade gist, I’ve reached mix assets.deploy, but when I issue that command, I get an error of:

22:48:17.974 [debug] Downloading esbuild from
** (RuntimeError) couldn't fetch {:error, {:failed_connect, [{:to_address, {'', 443}}, {:inet, [:inet], :nxdomain}]}}
    (esbuild 0.2.2) lib/esbuild.ex:227: Esbuild.fetch_body!/1
    (esbuild 0.2.2) lib/esbuild.ex:159: Esbuild.install/0
    (esbuild 0.2.2) lib/esbuild.ex:142: Esbuild.install_and_run/2
    (esbuild 0.2.2) lib/mix/tasks/esbuild.ex:32:
    (mix 1.11.4) lib/mix/task.ex:394: Mix.Task.run_task/3
    (mix 1.11.4) lib/mix/task.ex:443: Mix.Task.run_alias/5
    (mix 1.11.4) lib/mix/cli.ex:84: Mix.CLI.run_task/2
    (elixir 1.11.4) lib/code.ex:931: Code.require_file/2

I am able to curl the file’s url just fine.

Any suggestions?

Thanks! :slight_smile:

It’s interesting how the web world went from Grunt → Gulp → Webpack → esbuild

It seemed always that the next project became popular because the previous one was too complex and hard to configure, which makes me curious of what comes after esbuild, and what they will do different.

Anyways, gratz to the dev team for the new release!

Hmm… very interesting that Rails has released this - As I said, all non-Javascript frameworks are facing similar problems.
Hope there would be a Go/Dart/Rust based solution for CSS processing also. Web Development is at an important milestone. Let us see what the future holds.


That and a native package manager alternative to NPM/Yarn/PNPM that runs without node. Managing packages via semver with vulnerability control etc is what holds me to node atm…

(for CSS there’s but I guess you’re thinking about postcss-like functionality)

Looks like native is trending so who knows…

1 Like

Yes. I am looking at postcss sort of functionality - because that is how the defacto css framework tailwindcss works! this project looked interesting to me - scss based utility css framework. I wondered if I can get on with dart_sass also. But, the project looks in very early stages. I can use css, but not exactly a designer. So, hesitant to use. :slight_smile:
World across - nationality is trending. In software - native applications are trending. Let us see where this takes us to. :slight_smile: ← this is postcss on a rust powered runtime. Though afaik I read there are still some problems with tailwindcss on it.

Trivial question: how do you pronounce HEEx? “He-ex”, “heeks”, “H-E-E-X”?

“heex” => “heeks”


For the people interested, both and got a new release which support Phoenix_HTML 3.0.

Thanks @miguels