Phoenix upcoming 1.6 release

The fewer dependencies the better, and the less automagical setups the better. As in, providing the foundation, not a specific way of building applications, I think Phoenix is doing this well today, but I’d hate to see it become a LiveView default-framework (no matter how great LV is).
esbuild will make the frontend messier for many, you still need postcss or similar setup and esbuild comes with its own limitations (and installing it and keeping it up to date without Node is not going to be fun), personally I don’t see any reason for Phoenix to have any kind of front end toolchain, just ship the CSS files for the default template and be done with it :slight_smile:
And I say this as someone who does a lot of frontend.

3 Likes

The phoenix team wrapped it in a hex package. Installing and keeping it up to date will be no different as any other hex dependency. Unless esbuild changes where/how they host static binaries it won’t even require an update to the hex package.

5 Likes

That will just move the maintenance to the Pheonix team, esbuild isn’t even on 1.0 so any change can be breaking, just automatically updating based on when you’d run hex could result in some not-so-fun issues.
Edit: I noticed the explicit version handling in the example by José, guess that would work, but now you have version management in multiple places.
I have nothing against esbuild, I use it in Phoenix projects today, but I wouldn’t compare it with webpack in terms of features or use cases.

1 Like

esbuild + Tailwind JIT + Alpine.js has been my weapon of choice lately, so I’m super happy to see this and the synergy between Phoenix and Tailwind teams. Really looking forward to the 1.6 release, especially the .heex templates.

Some relevant links:

22 Likes

Fully agree with this. Most important part is - how little Phoenix intervenes with asset management - with some very little configuration you bring your own asset package manager. If you still want to stick to Webpack - no issues. If you want Parcel, Vite, Snowpack - there are just a couple of changes you make in the core application and you are done. This separation is really beautiful. Anyone from Rails world - Sprockets, Webpacker - how they are very intertwined with application development - would understand the pain.
All in all - well done Phoenix team.

12 Likes

The most important feature of esbuild is to not move from under us. Subscribe to Phoenix issues tracker and the Phoenix tag in the forum, you will see folks struggle with phx.new from time to time. Maybe the node version is too old, maybe npm is too recent, maybe node-sass just stopped working. All I want is for phx.new to work 5 years from now and this direction gives us that. We want you to be able to run mix phx.new, then mix phx.server, and have that page functional, regardless if you have opted-in to LiveView or not.

After that, you can opt-in to any complexity you want. You can bring Redis, you can bring Webpack, you can bring RabbitMQ. But the initial bootstrap should always work and stand the test of time.

I would love to ship with no assets toolchain but that’s not practical. Even a barebone Phoenix app requires importing “phoenix_html.js” and we can’t just bundle it into the app because running “mix deps.update phoenix_html” should update both the Elixir code and JavaScript code. So a minimal bundler is required even without LiveView (and even more required with LiveView).

I seriously recommend everyone thinking that the current status quo is ok to spend some time on the support front lines. It will be immediately apparent it is not fine and that it generates an incredible amount of churn. :slight_smile:

52 Likes

Agree with this @josevalim - The first thing I do after a mix phx_new is - delete the assets folder - and - copy my alternate assets folder which is configured with vite. But, even there what I liked the most about phoenix application structure is - except the change in config/dev.exs - I do not have to make any other change. Quite refreshing coming from … :slight_smile:

3 Likes

You can also use the --no-webpack param with mix phx.new

1 Like

Unfortunately, that does not work. With --no-webpack, you can not install LiveView. If we go that route - configuring LiveView has to be done manually. Hence my shortcut. :slight_smile:

3 Likes

Ok, You would also need to reconfigure watchers if You use the flag :slight_smile:

1 Like

Correct. We will depend on Phoenix LiveView by default (we kinda already do due to the dashboard) and we will move to the more expressive .heex templates with function components. But, when it comes to your own code, you can still choose between phx.gen.html (no liveview) and phx.gen.live.

12 Likes

I wouldn’t count myself to the ones thinking the status quo is fine, I even said I think Phoenix should come without asset management :slight_smile: (I get the problem of staleness though).

Hopefully this will lead to less churn, I just think it will be a different kind of churn, but I’m happy to be wrong.

3 Likes

Sorry if the tone came as accusative. I was not talking about you specifically, just as a general remark. :slight_smile: :heart:

Right, we may still have churn. But we are trading three churns (node, npm, and webpack) by one that we can explicitly hardcode and control on new app installs. On paper, this should be more manageable!

6 Likes

Sorry if the tone came as accusative. I was not talking about you specifically, just as a general remark. :slight_smile: :heart:

No worries, I should’ve read it as general comment and not personal, the quote tricked me :slight_smile:

Right, we may still have churn. But we are trading three churns (node, npm, and webpack) by one that we can explicitly hardcode and control on new app installs. On paper, this should be more manageable!

Lets hope for that! As someone who deals with this day to day I don’t wish it upon anyone, especially not when you’re all doing this free of charge :heart:
I think this will also make it easier to cement where Phoenix asset management starts and stops, since Node and NPM is out there’s no feasibility to adding frameworks like Tailwind to the defaults (and I say this as someone who loves Tailwind).

2 Likes

Nitpicking: Actually, we can. ES6 modules are supported by browsers for 93.38% of all users now:

https://caniuse.com/es6-module

A typical phoenix (LV or not) application only have a handful of js files. I don’t bother to bundle or minimize them any more. Granted if the user want to do something more complex they would need to pick a toolchain, however, by then the user should be sophisticate enough to pick on their own.

3 Likes

We very much explored this route, and this was my initial take on the matter when we decided enough was enough wrt to placing the burden of node on phx.new users. The “simply use <script type=module|modulemap and let HTTP2 take care of it, which no build step at all” was very much explored. Unfortunately, I don’t think this is the best default today as any moderately complex LiveView app doing its best to avoid javascript will still necessarily have more than a handful of js files over time. Charting, stripe/payments, alpine, hook files, etc. For example, livebook has 30 js files today. HTTP2 is great, but making dozen of H2 requests for assets isn’t a long term ideal solution. This is of course a great option for folks who truly have only a handful of js files that don’t creep over time, so by all means go for it! :slight_smile:

19 Likes

Yeah eex can be used for so many other things, like xml, graphql, programming languages, etc.

4 Likes

Exactly, I use it for XML for example. :smiley:

2 Likes

I’ve also got at least one index.xml.eex file in just about every project I use. Hopefully .eex template support isn’t dropped from Phoenix, even if .eex disappears from the generators.

That said, I’m super excited about this release!

In particular, the move away from NPM and Webpack to esbuild is something I was already playing around with and considering on my own. I was worried about a lack of searchability given the intersection of Phoenix users and esbuild users being too small. Bringing it into phx 1.6 completely solves that issue :smiley:

2 Likes

EEx support cannot be dropped from Phoenix, because EEx is part of core Elixir.

5 Likes