Why build assets in development?

Phoenix Forum Questions / Help
,
1

Hello,

This is not a Brunch vs Webpack vs Rollup topic, I was wondering why we build assets at all during development.
Some browsers already implement ES6 module loading, so why not relying on the same app.js that would:

  • be loaded as is in development, triggering additional downloads with imports
  • be built/packed/concatenated/minified for production depending on the same imports
    (the same could apply to CSS)

One benefit would be to get rid off build time of assets.

Thanks!

2

And some don’t. The Web has always been about the lowest common denominator…

  • some people might use ES7 or a language that transpiles to js.
1 Like
3

I am not suggesting releasing production code only for a small account of browsers, but using them during development (and skipping build time).

  • some people might use ES7 or a language that transpiles to js.

True,
It makes me think that with Brunch (or other tool) it’s possible to have different pipelines in development and production anyway, for instance:

  • copy files in development vs. pack files for production
  • or following your remark: transpile+copy in development vs. transpile+pack for production
  • …
4

You could certainly try it, but in the end I’d rather mimic my production setup in development as much as possible instead of hitting any issues introduced by the compilation steps of webpack/babel/… just in production. For as long as 3rd party scripts are still imported using ~3 different systems I’m happy hitting issues earlier rather than later.

5

It really is too little, too late - this may have made a difference back 2011 when Browserify first appeared but in 2017/18 I see this as a non-event. In the meantime the asset build pipeline has taken on a lot more responsibilities than just “bundling modules”.

Most of the asset building activities are aimed towards removing workload off the browser. If the browser does it’s own module loading then a lot of framework processing has to move back into the browser - like with Vue being forced to use the Compiler client-side or React using babel-standalone in the browser for JSX (which isn’t recommended for production, only prototyping) - which isn’t going to improve the user experience.

The hope that browser modules will obviate the asset build pipeline so that things can go back to the “simpler, good ol’ days” is at best naive. Sure there will always be cases were HTML + CSS + some Unpoly is good enough - but the truth is that “modern web development” is driving towards “mobile first” design in an attempt to make mobile native apps largely unnecessary - so that asset build pipeline is here to stay.

So it really becomes a matter of turning the asset build pipeline into an opportunity rather than seeing it as a challenge - for example using a programming language other than JS (e.g. to add static type checking) for complex client-side UI logic.

1 Like