I did not know esbuild is written in go
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.
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. What is the tentative release date for 1.6?
Hmm… another interesting co-incidence. LiveView 0.16 and Phoenix 1.6 both might get released at the same time.
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
And I say this as someone who does a lot of frontend.
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.
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.
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 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
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.