The eBook upgrade for previous owners of a pragprog.com 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? 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?
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 phx.new --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 phx.new --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
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.
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 ā 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 phx.new --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
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
1-minute? you mean < 10 seconds
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: https://gist.github.com/chrismccord/bb1f8b136f5a9e4abc0bfc07b832257e
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 https://github.com/elixir-plug/plug/pull/778