Consider django-pipeline over webpack about pinax

[paltman]

@rizumu thanks for the extensive write up and all the thought you put into it. I do have some individual thoughts about certain points you make above and do plan to respond as soon as I have time to collect my thoughts but this summarizes a lot of my original thinking around webpack over something tied to Django: http://owaislone.org/blog/modern-frontends-with-django/ and I think it's contents are worth some consideration while we are discussing this topic.

[paltman]

Regarding the performance issue, I have narrowed it down to the bootstrap.less and more generically the less-loader.

I have posted a stack overflow question as well as an issue on less-loader's project.

This might be a non-issue soon enough as I believe the sass-loader is much faster.

But there is certainly something happening in the less-loader as lessc is much much faster.

[paltman]

@rizumu so while we wait for me to either figure out what's happening in less-loader or I get a response on my SO question or the less-loader issue I filed, how do you feel about forking pinax-starter-projects and updating the Zero project to replace the build system with django-pipeline so that we can evaluate things in concrete terms?

I will say that I am in favor of the approach in this blog post but slow builds are a pain in deed. I am not sure where the problem lies or if it is fixable or if when we move to SASS it goes away (while LESS is generally accepted to be faster than SASS on compile, I really think it's a loader issue and not a compiler issue as the compilation manually is fast).

All that said, I'd love to check out your proposal in concrete terms and will approach it with an open mind.

[paltman]

I'd also love @brosner to weigh in on this.

[domenkozar]

my 2c on the proposal. Before I can answer any of those issues I'd like to state: separating JavaScript and Django/Python development workflows is what you really want. For following reasons:

• frontend and backend can move (be deployed) separately
• you can easily bring in a frontend person to the project since they'll know the tooling
• separation of concerns, you don't want to deal with problems on frontend when doing backend development, etc

1. This is an issue how you package software. Webpack expect to find all the sources with require() (or another dependency management framework) and you'll need to publish javascript pacakges to npm for each pinax plugin and then install those that are needed. At the end, webpack will spit out a big file taking in a account all of the require() calls.

2. As you've proposed it yourself, minimization takes most of the time. Usually asset building with react takes ~200ms. Set an enviroment variable in production config that will trigger a minimization.

3. If it's served with nginx, it will handle HTTP cache invalidation for you. Otherwise you have to use https://www.npmjs.com/package/html-webpack-plugin

4. Yes, django assets and webpack assets are handled separately, that's a feature

5. Yeah I agree, learning two separate tooling processes is not ideal

6. Generated files shouldn't be commited, but rather generated at deployment time

7. Cool, no biggie either way.

8. I'd say where files are hosted is outside of asset generation logic, but I see the added value

9. Yeah webpack has a bit more boilerplate, but that could also be reduced

[paltman]

I should add recompiled on watch are very fast when changing js is very fast. Recompile when changing less that depends on bootstrap less is generally slow (2-5 seconds). Love the idea of decoupling though. How does that work in practice though with a django project?

[domenkozar]

You'd have to version node packages the same way as python and have a glue code to keep them in sync :)

[paltman]

Well I mean more things like what do you do in addition to just runserver? Also, how do you handle static urls without hard coding things?

[domenkozar]

It's an all-in situation, whole asset management needs to be managed by webpack. Then for development you can serve static files via webpack-dev-server --content-base static/ and access them in Django via uri prefix.

[paltman]

I like this. Going to test this out right away.

Sent from my iPhone

On Oct 13, 2015, at 7:59 AM, Domen Kožar [email protected] wrote:

It's an all-in situation, whole asset management needs to be managed by webpack. Then for development you can serve static files via webpack-dev-server --content-base static/ and access them in Django via uri prefix.

—
Reply to this email directly or view it on GitHub.

[paltman]

As far as for less-loader being slow on parsing the bootstrap less, this person commented that they just switched back to gulp for that part of the build process. I hadn't thought about combining webpack and gulp. I mean i prefer a single build tool to worry about but if it means faster rebuild times it could be worth it.

[paltman]

I just wanted to come back to this issue. @rizumu I really appreciate all the time and consideration you put into this issue and want encourage more of it!

At this time, however, I think it's best if we stick with webpack. A big reason for this is we are embracing React for front-end components going forward (e.g. pinax-images-panel). The React team and community are centered around webpack and this makes things a lot easier for us to standardize on.

Furthermore, I really like having the clean separation of frontend code from the backend code.

This doesn't mean we don't have problems to solve:

• Django apps that ship static files
• speed of loaders like less-loader when including the bootstrap source as part of the compile

I do think these are solvable, but I'd like to solve them in the context of continuing to use webpack.