The upcoming Phoenix 1.6 release looks very interesting. Became a habit to watch the commits - and - what they are bringing in.
phx.gen.auth integration - for built in authentication
swoosh integration to provide a mailer baked in.
the new templating language heex which is HTML aware.
The new component function - which allows the componentization of views.
Ecto.Enum integration into the generators.
Really looking forward to it. @josevalim - any expected time of arrival for Phoenix 1.6?
Two suggestions:
It would be good to move asset packaging from webpack to esbuild or Vite where the build gains lot of speed - and - we deliver javascript as modules.
heex becomes the default templating engine over eex. ( A tongue in cheek question - any plans for making LiveView the default method for building full stack web applications? People who need API would have no conflict with that! )
I am a Rails migrant - and - feeling at home. Thanks a lot for all the work. ( Oops… These two sentences are not just to @josevalim , but to the entire community! )
3+4 are really a great step forward. I think heex will replace leex, not eex.
How far will the swoosh integration go? Will it be directly linked to gen.auth and bring some templates so we can directly send registration and lost-password mails?
3+4 is very good. As much I understood, heex is not just for LiveView but it is a regular templating engine. Yes, it is replacing leex for now - but - I thought, it can be the default templating engine.
Yes. swoosh integration commits show that we can directly send mails. I just hope - Swoosh brings fills a role like ActionMailer in rails - where infra is provided - and - all you need to do is some templating.
this is already happening. esbuild so we get js/css bundling/minification. No node, no npm, no webpack
7 is essentially happening as well as heex will indeed be the default. --html and --live will be merged
Wow! Thanks for the reply @chrismccord
BTW, it must be already planned - but - just another suggestion - consider using GitHub - surface-ui/surface_formatter and adding it to formatter - so that - our heex templates are also nicely formatted before saving!!
esbuild is a go program that does not depends on node. However, I don’t think it handles SCSS or PostCSS, only plain CSS. so you would still need something else in many cases.
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.
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
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?
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.
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.
What is the tentative release date for 1.6?
