Re: Management of static assets

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Web components are now standard HTML without JS frameworks, so that could be 
supported by Django. In which case, even StencilJS tsx components would work 
out of the box.

Prior to rendering, a middleware could scan the response and add the registered 
scripts/styles for the custom HTML tags it finds.

This would be a lot more convenient than form media, more portable and cover 
the full spectrum of use cases.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ILpwAOlivF-u3TTxhq0HgKy4CLazC_L3-bGQ8DFUE4Wsg5Ai6hgArNoyfR74J5mPdTIjfJP3iyS09F55wE0UxQJqtJqPo_BXQmfBs1Y8Yb4%3D%40protonmail.com.

Re: Management of static assets

[David Smith]

Hi All,

Thank you all for your time taken to read and respond to this topic. 

Based on the conversation I'll try and summarise to try and gain wider 
approval. 

-  There is a valid use case for form media so it should not be deprecated
-  The name is wrong so we should proceed with the rename
-  There are some areas where the current feature can be improved and we 
should progress with these (some items noted on this thread + other open 
tickets on trac)
-  If we wish to 'do more' it requires much more thought and a DEP. A DEP 
should most likely focus on building blocks rather than a full solution. 

The key thing here in the short term is the name change. If there are no 
objections to this I am happy to look at an implementation. Could then come 
back to the mailing list before it's merged, especially as it will be a 
breaking change?

Kind Regards

David



On Saturday, 9 May 2020 21:39:51 UTC+1, Aymeric Augustin wrote:
>
> Thanks David for investigating the topic thoroughly! I wasn't expecting 
> all that when I filed a one-line ticket six years ago :-) So, here's a 
> bunch of opinions.
>
>
> Before I start, I'd like to quote the intro to the Media class 
> :
>
> *Rendering an attractive and easy-to-use Web form requires more than just 
> HTML - it also requires CSS stylesheets, and if you want to use fancy 
> « Web2.0 » widgets, you may also need to include some JavaScript on each 
> page. The exact combination of CSS and JavaScript that is required for any 
> given page will depend upon the widgets that are in use on that page.*
>
>
> That was the reasonable thing to do before single-page apps, asset 
> pipelines, bundlers and code splitting. It's still a fairly reasonable 
> thing to do on a website that relies on good old HTML forms but would 
> benefit from "*fancy « Web2.0 » widgets".*
>
>
> *1. Django shouldn't do anything* (besides what 
> django.contrib.staticfiles already does)* for projects that use webpack *(or 
> any other bundler)
>
> The correct approach with a bundler is to bundle all JavaScript code and, 
> if needed, to optimize with code splitting. Attempting to include only 
> what's needed on each page, like Media does, will usually be 
> counterproductive, because it will general different bundle for different 
> pages and defeat caching by the browser.
>
> Then I know two techniques for integrating the frontend code with Django:
>
> - the single page app 
> 
>  (website 
> and API on separate domains) — this is clearly out of scope of this 
> discussion as Django only provides an API in this scenario
> - what I call the hybrid app 
> 
>  (website 
> and API on the same domain) — here django.contrib.staticfiles helps; it 
> comes after the JavaScript bundler in the deployment pipeline (and I prefer 
> plain django.contrib.staticfiles over django-webpack-loader, but that's 
> another story)
>
> (NB: while the blog posts I just linked to focus on create-react-app, the 
> concepts apply to any modern JavaScript toolchain.)
>
> Regardless, Django already provides more than we need. For example, both 
> webpack and django.contrib.staticfiles add hashes to file names to ensure 
> cache invalidation.
>
> So my answer to questions 3, 4 and 5 is "no, except maybe documentation".
>
> Now, let's leave this brave new world and remember the jQuery era.
>
>
> *2. Media makes sense*
>
> Although pluggable apps are fantastic, the concept doesn't work well for 
> templates, which is where  and 

Re: Management of static assets

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Le samedi, mai 9, 2020 10:39 PM, Aymeric Augustin 
 a écrit :

> Perhaps Django could standardize a way to accumulate a list of CSS and JS 
> assets to include in a page, which could then be rendered in HTML, perhaps 
> after optimizations (provided by third party apps).

The Cubic web framework has something like response.scripts and response.styles 
where you introspect and attach or remove stuff along the way.

Typically, if two different apps ship their own jquery.js then things are not 
going to work, one jquery will override the other and plugins will not be 
registered anymore.

So in Cubic at least your lib can check if there's a jquery js prior to adding 
your own. It's no silver bullet though.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dncgO1IUgyjWRJ9fMMbHWh5L9W5VfmgNgwyP9BNo2w11wdNAtZ8JZEH6bH61i-1o3kC_iPKx0ptXGMexpUQFC1u4oG13VEdA7xg0RX3Lw0U%3D%40protonmail.com.

Re: Management of static assets

[Aymeric Augustin]

Thanks David for investigating the topic thoroughly! I wasn't expecting all 
that when I filed a one-line ticket six years ago :-) So, here's a bunch of 
opinions.


Before I start, I'd like to quote the intro to the Media class 
:

> Rendering an attractive and easy-to-use Web form requires more than just HTML 
> - it also requires CSS stylesheets, and if you want to use fancy « Web2.0 » 
> widgets, you may also need to include some JavaScript on each page. The exact 
> combination of CSS and JavaScript that is required for any given page will 
> depend upon the widgets that are in use on that page.


That was the reasonable thing to do before single-page apps, asset pipelines, 
bundlers and code splitting. It's still a fairly reasonable thing to do on a 
website that relies on good old HTML forms but would benefit from "fancy « 
Web2.0 » widgets".


1. Django shouldn't do anything (besides what django.contrib.staticfiles 
already does) for projects that use webpack (or any other bundler)

The correct approach with a bundler is to bundle all JavaScript code and, if 
needed, to optimize with code splitting. Attempting to include only what's 
needed on each page, like Media does, will usually be counterproductive, 
because it will general different bundle for different pages and defeat caching 
by the browser.

Then I know two techniques for integrating the frontend code with Django:

- the single page app 

 (website and API on separate domains) — this is clearly out of scope of this 
discussion as Django only provides an API in this scenario
- what I call the hybrid app 

 (website and API on the same domain) — here django.contrib.staticfiles helps; 
it comes after the JavaScript bundler in the deployment pipeline (and I prefer 
plain django.contrib.staticfiles over django-webpack-loader, but that's another 
story)

(NB: while the blog posts I just linked to focus on create-react-app, the 
concepts apply to any modern JavaScript toolchain.)

Regardless, Django already provides more than we need. For example, both 
webpack and django.contrib.staticfiles add hashes to file names to ensure cache 
invalidation.

So my answer to questions 3, 4 and 5 is "no, except maybe documentation".

Now, let's leave this brave new world and remember the jQuery era.


2. Media makes sense

Although pluggable apps are fantastic, the concept doesn't work well for 
templates, which is where  and 

Re: Management of static assets

[Claude Paroz]

Le mercredi 22 avril 2020 17:22:02 UTC+2, Carlton Gibson a écrit :
>
> ...
> *Not sure* how much of this we need to pull into Django itself? 
> compressor, say, does the whole combine and compress thing well. If we pull 
> that in are we going to do the same for image optimization? Or pull in 
> Whitenoise? Or...? For a user just with contib.staticfiles, what's the very 
> next thing we could do that would make life easier? (i.e. is "I can't run 
> webpack" top of their list?) — What can we do better in core vs a 
> third-party app? — Is that just awareness, which is not a nothing? 
> Note the "not sure" — I think about this a lot, it's a big issue, but I 
> don't have a single answer: I've got what I do, and that works for me, but 
> I see lots of people doing different with success. 
>

I fully understand that it's not necessarily the role of Django to provide 
a full backed solution to management of assets, which is indeed changing 
quickly in some aspects.
However, I think that the problem now is that Django isn't aware of global 
project or app assets (they are just lines in templates), which means that 
third-party packages must provide their own different implementation of 
asset "objects". It does also mean that Django is helpless with regards to 
any management of static assets, typically in a case like subresource 
integrity.

My opinion is still the same, that we should add basic blocks of asset 
objects in Django core, giving ability to Django to offer basic services 
that are useful for most projects, while letting third party apps to build 
upon those "blocks" to give specific functionalities that need a quicker 
development pace than Django itself.

Claude

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10528a3d-4838-4358-804b-3f1f258a57f3%40googlegroups.com.

Re: Management of static assets

[Carlton Gibson]

Hi David. 

Wowser. Good work! 

(A cup of tea indeed — I should have replied to the first question better 
)

(Inter alia) You raised five questions. These were the last three: 

- Should there be better support for front end JS frameworks
- Should we have support for webpack
- We should support NPM

I think the *key point here is not to bind to a particular package*, 
webpack say. It's already Parcel.js no? — and it'll be something else next 
week. 

django-compressor, beyond concatenating and compressing files has this neat 
ability to define `COMPRESS_PRECOMPILERS` 


Here you can map files to any CLI tool (or write a bit of Python if it gets 
too clever — but TBH I never have to do that). 

An example from a project: 

COMPRESS_PRECOMPILERS = (
("text/x-tailwind", TAILWIND_COMMAND), # Compile tailwind via 
PostCSS, with tree-shaking, FTW 
# ("text/x-scss", SASS_COMMAND),  # Would compile Sass. 
Oops didn't delete it yet. 
("text/x-elm", ELM_MAKE_COMMAND),# Run elm make.
)

You can just as easily put in webpack or parcel or babel (or a chain of any 
or all of them...) 

It's that plus the offline compress tool that means I've been happy with 
compressor for a long time — I just never had to move on. 
(There's a point where you hand off to a frontend specialist but ...) 

So, particularly given how fast the tools landscape moves here, and how 
slow Django moves in comparison, some kind of wrapper where you shell out 
to A.N.Tool — it doesn't have to be JavaScript. It might be make, or 
pyinvoke — rather than something tied to webpack, as the example, would be 
a requirement for me. 


*Not sure* how much of this we need to pull into Django itself? compressor, 
say, does the whole combine and compress thing well. If we pull that in are 
we going to do the same for image optimization? Or pull in Whitenoise? 
Or...? For a user just with contib.staticfiles, what's the very next thing 
we could do that would make life easier? (i.e. is "I can't run webpack" top 
of their list?) — What can we do better in core vs a third-party app? — Is 
that just awareness, which is not a nothing? 
Note the "not sure" — I think about this a lot, it's a big issue, but I 
don't have a single answer: I've got what I do, and that works for me, but 
I see lots of people doing different with success. 

Kind Regards,

Carlton



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4cda64f0-2630-4377-a2d7-a2312a006ae9%40googlegroups.com.