Phoenix 1.4.0 released!



The eBook upgrade for previous owners of a license was undervalued.


There have been other discussions around this if you search the old mailing list or issues. The tldr; is supporting something like --template means we as the Phoenix team must be careful about maintaining compatibility as we update our generators. This isn’t a burden we want to take on as maintainers, especially when contributors have first-class mix tooling to generate their own projects as they see fit.


Yeah, that’s something to have in mind, maybe an extension as third party project would fit better. Thank you for the reply.


The problem is not about the effort but about mentality and mindset.

Rails also started like that: “small convenience for developers, out of the box”… they continually add them, one by one, slowly. Sounds familiar? Jquery, Turbolinks, and then Webpack, are they being serious? Yeah, I know Rails is Omakase, but I don’t want to fill my machines with things I don’t need.

Laravel also started as a nice little web framework (real nice if you ask me), until they put this frontend preset stuffs. What the hell happened? :confused: I just want to use that Laravel thing, don’t make download the whole frontend preset stuffs. I don’t want to use Vue, why do Laravel make me download it? :worried:

I’m okay about backend stuffs that are out of the box. I’m 100% with conventional out of the box web framework. But, frontend stuffs? not so much.

It would be really really great if we could just start creating a new project, with no frontend stuffs at all. Let me just look my own.

Having a web framework which gives you node_modules as a default setting is a nightmare. Hopefully this is not the trend we are looking into.


mix --no-html --no-brunch. I realize it is not the default, but it is possible.


I alias that command from a long time ago, and I always use it.

Still, If packaging with frontend stuffs is inavoidable, at least don’t make it the default.

mix --with-brunch is better, IMHO.

But this is 1.4, we are now going to see phoenix bundled with webpack.


Congratulations to the team and many many thanks for making my life easier and my job more fun. I would be tearing my hair out without elixir.

The presence update looks FANTASTIC. I remember wrasslin’ with presence diffs :scream:

We just started a project with Phoenix 1.3.4 and would like to update to this RC. Do we have upgrade documentation somewhere I can follow? My project is small enough that an upgrade should be painless, but large enough that a rewrite from scratch is a non-starter.


I can’t speak for Chris but usually defaults are defined to make things easy for on boarding. Once you are comfortable, you may never use HTML generators again…but they are there.

One of the highlights of Phoenix is the exceptional performance of its view layer. Hiding that by default doesn’t make sense.

If you are using Phoenix to make something more highly specialized, you get the ability to tweak it to your needs…but expert needs are never intended to be the default for a framework like this. If it were we would just tell people to start with Plug and here’s how to add migrations, here’s how to add routing, here’s how to add views…

Having a single file to delete or setting to use to do things the way you prefer is a really convenient way to be one of the 20% use case.

There was also a discussion here about Webpack, brunch, etc. it basically boiled down to webpack becoming the defacto standard in JS land and it makes more sense to defer to that community. Phoenix just makes it easy for the on boarding use case.

As an expert who knows what he wants, it’s easy enough to change/remove.


I’m talking more about 3rd party things that are optional and replaceable.

Views, migrations, routing, they aren’t. I support Phoenix over raxx.

As long as it is not as complicated as I experienced before with Rails, I’m okay with that. Hopefully Phoenix is not going the Rails’ path. :slightly_frowning_face:


If it was, I don’t think most of us would be here. The biggest influence from Rails on Phoenix (that I’ve seen) is tooling for developer efficiency. Rails pursues that to the detriment of long-term maintainability (in my experience)…Phoenix doesn’t.


I believe it’s linked in the first post:


Jose and the others want to see Elixir succeed. They want to show us that there is a better way to do things. I would bet that most of us here are refugees from other technologies – like the original creators are.

To help with that onboarding and to gain popularity, easy defaults are the way to go as @brightball said.

It’s absolutely admirable how @chrismccord and the Phoenix team got their hands dirty and got outside their comfort zone to give us the ever-changing de facto standards from JS and CSS lands so we can develop easier and with less annoying details to care about. That’s something they absolutely didn’t have to do; they could have just told us “here is how you can make your own asset pipeline, here is how you can put JS and CSS in your project, k thx bye” – but they went out of their way so we didn’t have to. I am grateful.

It’s okay to disagree with the choices they make – we all have different work needs. It just seems to me that you will have to become an expert – if you are not already :wink: – and just rip out the parts you dislike. For just a few weeks of learning I feel that Phoenix is extremely flexible and lightweight; you can mold it to almost whatever you want.


As others have said, mix --no-webpack. Our choice to use Milligram as a tiny, unobtrusive css file is an odd hill for you to plant your phoenix-is-turning-into-a-nightmare flag on :smiley:

Seriously, we previously included Bootstrap as a sane default, which required us to pollute our generated markup with bootstrap specific classes. I didn’t think this move to pollution-free markup would be controversial.

At any rate, it’s clear you care about Phoenix, and I appreciate that, but rest assured, focusing on a nice up and running experience for on boarding newcomers is not going to ruin us – it’s the key to our continued success :slight_smile:


1-minute? you mean < 10 seconds :innocent:


Maybe @dimitarvp is used to wisely giving conservative estimates to business folks :slight_smile:


You got me. I have PPTSD… Post-Promise Traumatic Stress Disorder.


I updated the phoenix package, but now phoenix_live_reload has mix deps.get errors.

Failed to use "phoenix" (version 1.4.0-rc.0) because
  phoenix_live_reload (version 1.1.5) requires ~> 1.0 or ~> 1.2 or ~> 1.3 *
  mix.exs specifies ~> 1.4.0-rc

* This requirement does not match pre-releases. To match pre-releases include a pre-release in the requirement, such as: "~> 2.0-beta".

** (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}

How can I address this @chrismccord?

I’m following this gist:


Are you missing override: true from the phoenix dependency? This is required for release candidates.


@chrismccord I have tried phoenix release candidate version by updating all dependencies in separate branch of bigger GraphQL project. Everything seems to work nice, but I have such warning:

[warn] Setting Ranch options together with socket options is deprecated. Please use the new map syntax that allows specifying socket option
s separately from other options.

[warn] Setting Ranch options together with socket options is deprecated. Please use the new map syntax that allows specifying socket option
s separately from other options.

Of course I have made all changes including Deprecated Transport macro part described in your post. Do you know something about it?


This issue is in Plug. I have a PR open to fix it