[NhanH]

Another thing I am concerned about is the removal of default integration with FE build pipeline and npm libraries. I understand the complexity of the pipeline, and Rails is doing the same. But the difference is that Rails has a replacement in place (importmap), while Phoenix recommends vendoring the lib. In additional, Rails has suitable replacement for the use case (hotwire) and a clear focus on the philosophy of productivity. I am not sure why Phoenix did the same things without a clear path forward.

[josevalim]

The integration is still there and it is mentioned in our assets guide: https://hexdocs.pm/phoenix/asset_management.html#third-party...

Regarding import maps, I am still slightly skeptical. First they don’t solve all needs of npm (for example, what if you need to precompile your FE code?). Second, I have feeling that every import map management tool will eventually become a package manager through slowly creep in of requirements. At the same time, there is nothing stopping anyone using it on their Phoenix apps if they so desire.

[NhanH]

Is the plan to keep esbuild (and npm integration) for the long term, or would that be deprecated in a few years?

[josevalim]

I would hope it to be long term but it is impossible to know given how fast the JS landscape can change.

But also keep in mind that Phoenix is not tied to any of these. The esbuild bits are only part of the generated app, which you can stick to or change altogether.

So when we moved to esbuild, we broke zero of the existing apps and no deprecations were emitted. The same would happen if we move away from esbuild.

As an example, I moved most of my apps to esbuild (and I have been very happy with it), but one still uses webpack because it uses the Monaco editor and we rely on certain plugins. So our approach has always been “sane defaults” but not getting in the way if you know better or prefer something else.

[wstuartcl]

Snorted a little at this -- how can anyone forecast JS ecosystem 5 years out. =)