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:
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.
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. 
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 … 
You can also use the --no-webpack param with mix phx.new
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.
Ok, You would also need to reconfigure watchers if You use the flag
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.
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 (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.
Sorry if the tone came as accusative. I was not talking about you specifically, just as a general remark. 
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!
Sorry if the tone came as accusative. I was not talking about you specifically, just as a general remark.
No worries, I should’ve read it as general comment and not personal, the quote tricked me
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
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).
Nitpicking: Actually, we can. ES6 modules are supported by browsers for 93.38% of all users now:
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.
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!
Yeah eex can be used for so many other things, like xml, graphql, programming languages, etc.
Exactly, I use it for XML for example. 
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 
EEx support cannot be dropped from Phoenix, because EEx is part of core Elixir.
Ah, so it is!
I’ve used it outside of Phoenix myself a few years back, but having done every web project in Phoenix for the past few years, I’d completely forgotten.
Phoenix 1.6 release is in
0 voters
© Copyright Elixir Forum | Terms | Privacy & Cookies
