Phoenix 1.6.0-rc.0 released!

You are being extremely dismissive, even after the post outlines the benefits, others in this thread (myself included) have expanded on the benefits, and José has offered help. If node-free js and css bundling and minification with guaranteed repeated builds years in the future is not a “benefit that you can see”, then there is no productive way for you to remain involved in this conversation :v:

23 Likes

Well from my point of view I discovered an omission in the documentation and after getting it all to work esbuild breaks my application. Being node-less is not something I care about all that much. But I will happily leave the conversation to the ones who do. Bye.

I am still trying to understand your perspective. If webpack is all that you care in a framework, what is preventing you from adopting it in this new release?

For posterity for others – the way folks choose to engage in a conversation really matters. Given two paths for improved gaps in docs (which is the entire point of a release candidate to find bugs/docs issues), which path is better? Finding issues with optional tooling when evaluating if it suits your needs then completely dismissing the work of others, or stating your alternative solution works better for you, but offering up the gaps you found in documentation for improvement? Both get us to better 1.6.0 final documentation, but one leaves maintainers discouraged and puts others work down unnecessarily, while providing negative value to the conversation.

51 Likes

Congradulations on the release! :confetti_ball: The new features look very interesting.

Having a single rendering engine/syntax is a big step forward over having both LiveEEx as well as (plain) EEx with their slight variation in syntax and semantics. I’m very stoked about this development!

Are you imagining that the HTML-awareness of HEEx might also help to improve LiveView’s diffing algorithm further (better fingerprinting, improved change tracking, maybe reduce the need for a manual ‘id’ option to track children), or will it remain a ‘plain text’ layer?

We can add the ids and such at compile time, so there is benefit there, but not really in terms of the diffing. Diffing-wise, one area today where we could be smarter is diffing tag attributes. For example if you add a tailwind class to a bunch of other static classes, we have to re-send the entire attribute value. I could also see things in the future like css class purging and what not helping the overall bites-over-the-wire story since we could be aware of al the classes used in all heex templates. Many libraries already do this like purgecss with regexes, but neat to think about doing it within HEEx integrations.

15 Likes

Really excited about this release, looking forward to playing around with HEEx and an included swoosh setup. Thank you Chris, José, and the rest of the Phoenix team for this amazing piece of free software!

Coming from a NodeJS background, it seems both insane and ideal to me to not have webpack included. I’d love to leave webpack behind forever to be honest. Upgrading to the latest TailwindCSS and webpack 5 took me half a workday of frustration, as webpack config is not intuitive and has to be completely rewritten/restructured with every version upgrade, usually with the aid of 5-10 stackoverflow posts and github issues.

esbuild looks very promising, even though it is less than a year old at press time (which could be an advantage if our community engages with its development). I’m guessing esbuild may not yet have full webpack capabilities, but here’s hoping it pushes the JS ecosystem in a more sane direction.

10 Likes

Congrats to all contributors, still improving my elixir skills and hope to become contributor soon :slight_smile:

2 Likes

I’m using the step-by-step upgrade guide to bring an existing application from 1.5 to 1.6; after updating the deps and switching from html.leex to html.heex, I’m getting errors like this for all my forms:

unmatched closing tag. Expected </div> for <div> at line 51, got: </form>

where an example form might look like:

<div class="flex mt-6 mb-8">
  <%= f = form_for @changeset, "#",
            phx_submit: "move_items",
            phx_target: @myself %>
    <div>
      <%= select f, :category_id, @category_select, prompt: "Move to list" %>
      <%= submit "Move" %>
    </div>
  </form>
</div>

Is this expected? I noticed a new syntax in the docs like <.form> </.form> but is that now required for heex?

It is, see Phoenix.HTML.Form — Phoenix.HTML v3.0.2

1 Like

Hey gang, any chance to have a reference on how to add font-awesome to a Phoenix project using this release. I tried many ways but not luck yet. A couple weeks ago I was able to add it to a previous Phoenix version by following this tutorial, but now that we are substituting webpack the way is different. Thanks in advance.

You would want to try the excellent GitHub - miguel-s/ex_fontawesome: Font Awesome for Phoenix, Phoenix LiveView and Surface. It is meant for LiveView and Surface.

1 Like

Thank you for your replying @cvkmohan. Indeed, the package looks really good. I tried to set it up as a dependency in my project and I got a mismatch between dependencies, as you can see below. Any thoughts?

Failed to use "phoenix_html" (versions 3.0.0 and 3.0.1) because
  apps/habitus_web/mix.exs requires ~> 3.0
  ex_fontawesome (version 0.3.0) requires ~> 2.14
  phoenix_ecto (version 4.4.0) requires ~> 2.14.2 or ~> 3.0
  phoenix_live_view (version 0.16.0) requires ~> 3.0.0
  phoenix_live_view (version 0.16.1) requires ~> 3.0


Failed to use "phoenix_html" (versions 3.0.0 to 3.0.2) because
  apps/habitus_web/mix.exs requires ~> 3.0
  ex_fontawesome (version 0.3.0) requires ~> 2.14
  phoenix_ecto (version 4.4.0) requires ~> 2.14.2 or ~> 3.0
  phoenix_live_view (version 0.16.1) requires ~> 3.0


Failed to use "phoenix_html" (version 3.0.2) because
  apps/habitus_web/mix.exs requires ~> 3.0
  ex_fontawesome (version 0.3.0) requires ~> 2.14
  phoenix_ecto (version 4.4.0) requires ~> 2.14.2 or ~> 3.0
  phoenix_live_view (version 0.16.0) requires ~> 3.0.0

** (Mix) Hex dependency resolution failed, change the version requirements of your dependencies or unlock them (by using mix deps.update or mix deps.unlock). If you are unable to resolve the conflicts you can try overriding with {:dependency, "~> 1.0", override: true}
1 Like

I think @miguels needs to update the dependency packages and give a new release. Let us hope he notices this.

1 Like

I see that the topic of {Node, NPM, webpack} → esbuild switch is raising some questions and doubts. I myself have had to wrap my head around all the pros and cons in order to figure out my own go-to default scenario for new & existing Phoenix apps. Which led me to the following writeup: Wrapping your head around assets in Phoenix 1.6.

To summarize, I’m all in for esbuild but not so much for lack of npm. At the same time I 100% understand the Phoenix team’s reasoning. Now for the productive part, the article includes not just the discussion on pros & cons of the transition backed by real-world examples, but perhaps most importantly - a complete guide for turning 1.6 default app’s assets to esbuild backed by npm (or yarn) which is IMO the most reasonable default - for those that see it fit. :slight_smile:

I hope @chrismccord & friends that you’ll find this writeup as a useful & productive addition for this major transition, and one that by no means does neglect the efforts of everyone behind this awesome new Phoenix release.

12 Likes

I acknowledge the benefits of your approach, but I’m on the maintainers side on this. Phoenix could ditch Milligram and Topbar - they are only there to make the “blank” app look decent. I think you’re bound to nuke phoenix.css sooner or later. Even the name implies this. Topbar is kind of different, because a LiveView app without progress feedback is not great, but I’d say it’s in the same boat as Milligram.

So I’d say that we’re essentially left with esbuild. It’s a Go binary. So you either wrap it with Elixir which you already have, or bring the whole Node.js world just for one binary and potential other uses. I prefer the Elixir wrapper.

2 Likes

Really impressed with the evolution of the framework.
That’s an amazing job! I’m still newer on the elixir-lang but already can see the fantastic language that it is.

:+1: Sure I get it. I’m not a Phoenix maintainer but from the issue stats (npm was 591 out of 2034 :scream:) it looks like a clear line had to be drawn to indicate that Phoenix support cannot and doesn’t cover npm - which it has every right to, offering 1st class support for plugging any bundler. I suppose these sorts of lines are thinner with frameworks than with regular libs.

I’m a very pragmatic developer (don’t ask about my testing approach :stuck_out_tongue:) but I personally wouldn’t put even a single lib (e.g. topbar) into my project by copy-pasting because I’ve been there years ago and it’s just never worth it. And realistically, you’ll always want at least few more NPM packages in about every non-API project.

Fortunately, we can skip being “sides” via constructive discussion, respect and mutually beneficial solutions. Elixir community always was particularly rich in these values and I hope that my article carries them on, explaining my POV straight and providing solutions, at the same time being respective to the perspective of every party included.

10 Likes

Congratulations! Thanks for the hard work. Gonna test it right now.

Probably it is a win-win all around. Phoenix maintainers did what they had to do. And, the “pragmatic developers” get to do what they want. Probably that is what frameworks are supposed to do - provide sane defaults and allow customization for the more advanced ones.

2 Likes