Webpack

General Prog (Archived)
1

Just got this in my inbox from Zurb:

You may have heard about Webpack, the new JavaScript Module Bundler that’s taken the webdev world by storm that all the cool kids are talking about. They just launched version 2, are being used by massive web companies like Twitter, Facebook, and Paypal, their monthly downloads are about to cross 4 million, and the Ruby On Rails core team has announced that Rails 5.1 will ship with webpack support built in. In other words, it’s the new hotness and has a ton of momentum behind it.

I just checked, and it should be easy enough to swap out in Phoenix according this post by Chris:

What do you think about it? Would you use it over brunch? Why?

5 Likes
2

They have foundlings, they have people working on it … Project under https://js.foundation

4 Likes
3

With an SPA built with webpack you don’t immediately send your admin panel down the wire to all clients. Foundation 6 gives you an la-carte front-end.

They are a good fit and should make for a crazy fast downloading frontend.

3 Likes
4

The folks at Airbnb seems not keen on switching to Webpack 2. Here’s an explanation of why on a Reddit thread. It’s mainly due to the potential interoperability issue between CommonJS modules and ES modules should Node.js finally implement module system later. I don’t know if Brunch has that problem though.

3 Likes
5

It should not as it babel’s down to ES5.

However in my and others experiences, webpack has some major issues, but then again so does brunch. Currently I’m using just npm ‘scripts’, I have bucklescript compiling to a directory, rollup.js bundling and optimizing those output files and my other javascript all together into a set of a few files, and for production environments it also passes it all through an uglifier and google closure (probably redundant to have both, but eh), with significantly less code and significantly greater maintainability than even Brunch’s config (especially webpacks, yeesh…)

3 Likes
6

module standard is big problem for js community …

2 Likes
7

I’d be interested in seeing your bucklescript |> rollup pipeline

1 Like
8

Actually I introduced it to the Bucklescript author and rollup.js is now not only added to the official tests of Bucklescript (that you can check there if you are curious) but he is also adding more optimizations that make it even easier for rollup.js to process here:

I’m planning more blog entries on how to use bucklescript including using it with rollup, so expect those as I get time. :slight_smile:

2 Likes
9

When i started with Elixir/Phoenix i did not have idea what was Brunch or Webpack, but actually after 1 year i like Brunch, but i think Webpack community is very bigger than Brunch, and documentation for some features is hard to find.

I did not agreed of remove Brunch/Webpack from generator, but switch to Webpack i think is an good idea.

1 Like
10

Over the weekend I finally got Webpack working with Phoenix with everything. Fonts/Images/CSS/SASS/NPM modules. Here is the config file: Webpack 2.0 Config File for Phoenix

Note: Currently there is a bug in file-loader@0.11, please use file-loader@0.10.1 instead or this config will not work.

3 Likes
11

I’m about to move to Webpack in my next project. I’d rather not have to learn it indepth yet… just get it working.

Is there anything other then what editing the files you outline in your Webpack config link to get it working?

2 Likes
12

The basic steps are: generate your project (with Brunch, because it creates the correct directory structure), delete brunch-config.js and remove brunch files from package.json. Install Webpack with npm, create a webpack.config.js file, add an npm script to run Webpack on build, and edit the watchers in config/dev.exs. Lastly, add the specific Webpack loaders to compile your assets (ES 2015, css, etc.).

I followed this post by Matthew Lehner to get up and running with Webpack and Phoenix. I also liked this free DailyDrip video. It covers Webpack, Phoenix, and Elm.

2 Likes
13

I have a starter repo up that I use for Vue+Phoenix projects:

Probably the most useful features for me are code-splitting and PostCSS plugins.

Running certain modules, such as minifiers, can be time-consuming, so I set it up to run only in production mode.

If you have the time, Steven Grider’s webpack course on Udemy is pretty good at taking you through the steps in setting up Webpack and understanding things in detail (though not Vue or Phoenix-specific)
https://www.udemy.com/webpack-2-the-complete-developers-guide/learn/v4/overview

3 Likes
14

Thanks for the starter:

I imagine I can just search/replace the project name to change the name?

What’s the reason I see js directory renamed to src so often?

1 Like
15

It’s a convention found in the vue-cli templates:
pwa
webpack
webpack-simple

3 Likes
16

It’s just the Webpack file and the rest of the instructions (npm packages to install, change to config/dev.exs) are in the comments. Let me know if you have trouble with it and I’ll try and help.

Here is the updated version for use with Webpack 2.0+ and Phoenix 1.3

1 Like
17

Yep, you can search/replace to change the project name.

But, I usually find it easier to scaffold a new project like this:

  1. Create a new project
    mix phx.new newproject
    cd newproject
    mix ecto.create

  2. Replace your new /assets folder with /assets from the repo, then run:
    npm install

  3. Edit config/dev.exs by changing your watchers config from this:

watchers: [node: [“node_modules/brunch/bin/brunch”, “watch”, “–stdin”,
cd: Path.expand("…/assets", DIR)]]

to this:

watchers: [
node: [“node_modules/.bin/webpack”, “–colors”, “–watch-stdin”, “–progress”,
cd: Path.expand("…/assets", DIR)]
]

Finally, replace your new /templates folder with /templates from the repo.

1 Like
18

Looking around online, I see a lot of articles encouraging code-splitting. But I don’t see counterarguments being considered.

I.e. What is the right size to start code-splitting, given the tradeoff between a slower initial load and then fast navigation versus much faster initial load but slower navigation?

I know for myself, I’d prefer the former unless it’s really long.

19

Also, if I code-split, navigate, and then hit the back button, the bundle for the page I navigated to is not lost and then reloaded when I navigate back, correct?

20

Code splitting helps You separate what is changing (Your apps) from what is not (Libraries). Eg. separate into bundle and vendor. But caching is not the ultimate way for optimization.

One cool feature of Webpack is lazy loading… For example if You use a router, each bundle will be loaded on demand. The trick is to transform call to import into a function call. This will result in bundle calling bundle0, bundle1 etc. Something like…

() => import "./whatever";