Phoenix upcoming 1.6 release

I did not know esbuild is written in go :slight_smile:

3 Likes

This! Already having enough problems with asset recompilation on Webpack.

Hope that happens sooner than later. I’m pumped for the new stateless function components. Especially because I’m heavily using TailwindCSS recently.

I’d hate if that would be the case. I do think that LiveView is a great tool and I recognize there’s some adoption by the community. However, I don’t believe that this should be the default experience for building web applications.

IMHO: LiveView is great for specific scenarios as well as other component-based JS frameworks like Vue and React. But, for people doing HTML-centric applications like me (the OG web experience) this would look like a shot in the foot.

I don’t know if Heex will be flexible at the point that you get LiveView functionality for free within the default templating system. But If I have to spend most of my time removing traces of LiveView in each new project because this is now the “default” experience, I’d expect at least that we have a fallback flag in the generators that removes this inconvenience.

9 Likes

Hmm… when I meant LiveView being default - I probably meant Stateless Components being used everywhere for Views. More like, ViewComponents Gem by Github in the RailsWorld. Whether, those components include Javascript for the behaviour is dependent on us. Like, ViewComponents relying on Stimulus. I guess, one more Rails example and I will be kicked out of this forum :stuck_out_tongue_winking_eye:

2 Likes

:heart_eyes:

9 Likes

Oh No!!! @josevalim I am not on Twitter. And - it is purely coincidental that I raised these questions now. Never thought you will provide solution so fast!!! GitHub - josevalim/phx_esbuild_demo
Though most of the questions are answered now - there is one still pending - and - only you can answer. And - in your usual style, you can skip it. :stuck_out_tongue_winking_eye: What is the tentative release date for 1.6?

3 Likes

Very Soon™

47 Likes

I guess, this application is created without LiveView support. Saw some commits in LiveView and Phoenix where the core Javascript is written in Module format. May be those pushes are necessary for the esbuild to work with LiveView.

1 Like

Hmm… another interesting co-incidence. LiveView 0.16 and Phoenix 1.6 both might get released at the same time.

2 Likes

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:

21 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