Parcel is really “zero config” and really takes care of everything for you out of the box. I’ve tried it and without much effort I got my frontend set up. I think it will be a good companion for Phoenix.
5 Likes
Brunch is not mainstream enough and Webpack is too complicated.
1 Like
I swear, like every 2 months or so, we got a new build tool/dependency manager on javascript.
16 Likes
No, because no one will agree either way, and its easy enough to switch to use whatever build tool you want. And it seems like there’s a HOT new JS build tool every 6 months. It would be a waste of the core team’s time and energy.
5 Likes
Yes but with a better tool, it saves more time in the long term because it has enough information out there and is less error-prone so core team will see less issues about Phoenix’s frontend.
1 Like
Parcel doesn’t seem ready for prime. For instance, it doesn’t have a working Vue.js packager yet.
3 Likes
Coming from a background using React, Ember, Angular and a heap of other frontend tools/frameworks I’d say no. We could have this discussion in another 8 months. Ember has been using Broccolli for years and have tuned it in a way that works better than the alternatives for their project. Tom Dale has spoken about this alot (Ember Founder).
Unless there is a real benefit to the framework that is measurable now, then I don’t think its worth it. Especially with Parcel being so young.
3 Likes
I suppose it depends on what time of day it is, if I am hungry and whether I expect the parcel to contain food.
Sorry, couldn’t help myself. 
16 Likes
I wish we weren’t part of an industry that worked like this. With the amount of hours spent on FadOps in JS you’d think they get nothing done, but it’s just that 75% of a thousand billion developers still is a lot.
More on-topic: Could you make an example repository and make it easily cloned so that people can use the thing that’s better?
1 Like
The choice of bundler is often constrained by the choice of front-end technology - which has nothing to do with Phoenix.
If you are using React or Vue.js then your cli tools will likely spit out Webpack configurations - so as a consequence of choosing a particular front-end technology (a choice not influenced by Phoenix) it becomes necessary to learn how to cope with the supporting tooling.
Ultimately integrating the asset build system is the developer’s responsibility because it’s a project/product choice.
Phoenix isn’t forcing anybody to use Brunch - it just happens to be good enough for your vanilla EEx-based application.
The choice of bundler isn’t imposed by Phoenix - it’s imposed by the front-end ecosystem that is used (independently) with it.
You are free to use Parcel with Phoenix and even evangelize it’s use with Phoenix but ultimately it’s a non-issue for the Phoenix distribution. Just like Brunch, Parcel will have it’s blind spots (as any other asset builder will have).
6 Likes
I always use webpack 
To tell the truth frontend technologies are changing so fast and always improving themselves in good (new stuff quick) and bad way (instead of improving existence one, another library is created to replace the older one) that at this point I don’t believe phoenix should stop support brunch by default. The main reason is because is gonna be different in a couple of weeks, the other reason: phoenix makes so easy to switch from using other stuff (like webpack) that doesn’t make sense to change at this point.
I just use npm ‘as’ the build system. It comes with node, I can call to any other build system if I want (even concurrently), and it can do everything anyway, so why not.
The best response so far! 
While the js-hater part of me likes to have brunch by default and do not handle the minorities of choosing lots of different tools to solve every minor problem when building assets. There is another part (also js-hater) that is really annoyed every time it has to configure brunch to support the brand new X hype framework.
I guess this part agree with you in using npm only, I just don’t know which part is Jekyll and which is Hyde.
1 Like
I’ve discussed this before, so I’ll just post a link to my comment in another thread: How to plug in webpack 2.0 into phoenix 1.3.0-rc
Essentially, I can’t use brunch as my packager, because they’ve opted to derive plugin load order from the order in package.json, which is always alphabetized on modification. This breaks a very common workflow for me, which means my first task on any Phoenix app is stripping out Brunch and moving to Webpack. Is it a huge amount of work? No. However, it’s certainly annoying.
On topic: I’d be wary of using another “zero config” package manager for this same reason. I don’t think it’s feasible, or responsible, to try to handle this in a way that will work for everyone. Webpack is a better default because it’s more configurable, and package bundling just isn’t a spot where convention wins over configuration (however much I wish that were true).
1 Like
It’s a “get on with the times” issue.
“Oh, you’re using that antiquated, two weeks old, JS build tool? Well good day to you Sir! Good day! I can do my amazing static page in Horseshoe_reactangular.js!”
The argument for Brunch is that it works great for people who want to get started and have everything working.
That’s great, but here’s actual experience from a beginner, not only in Elixir and Phoenix, but programming in general.
Brunch is great for exactly 5 minutes, the 5 minutes you start a project and see that it’s working, after that, I didn’t know what to make of it.
“Tasting your first Brunch
What is the dish made of?
Pouring some syrup
Serving the Brunch”
Brunch’s Docs page made me feel like I’m about to join a strange religous suicide club and the tab was closed faster than an unwanted pop-up ad.
I am yet to finish my first project and I’ve already removed Brunch, not using ecto and have a bitter relationship with Plug.
But this is my personal experience for a project that apparently doesn’t fit in the pipe.
Also as a beginner, it was not immediately apparent that I can use Phoenix without Brunch, after starting a project without it and being left with what I presumed to be a bare bones json api backend.
2 Likes
This is slightly off-topic, but what are you doing if you can’t make it fit with Plug?
1 Like
Hey all – I really like parcel, so I went ahead and made a starter pack / instructions for getting parcel set up with Phoenix.
It is significantly easier to replace brunch with parcel-bundler than it is to configure webpack, IMHO.
7 Likes
Sorry to continue this discussion, but I’m a little concerned with brunch. Most of the work I do is APIs and simple UIs so the default brunch setup (or --no-brunch) works for me. As a proof of concept I moved an old React 0.13.x project from a node Hapi server and webpack to phoenix 1.3 and with a small number of changes i got it working just fine. Brunch code reloading and installing new npm modules worked better than the old webpack setup.
What I am concerned about is there are 7 pull requests and 116 open issues against the brunch github repository and the authors seem completely unresponsive. I’ve gotten caught a few times by depending on a project that is abandoned, or goes off in a direction that makes it unusable, so now I am paranoid. (I’d have the same concern about Parcel.)
Frankly in this case it is entirely avoidable by taking responsibility for your own asset management setup. If you are React focused, Webpack seems the logical choice. For another client-side framework another build tool might be more appropriate.
Phoenix was never joined at the hip to Brunch and it’s inclusion wasn’t meant as an endorsement - it was merely a convenience.
2 Likes
