Open Stack

Matthias Runge <mrunge at redhat.com> writes:

> On 21/01/15 09:59, Martin Geisler wrote:
>
>> 
>> This seems to imply that users will download at least one .js file
>> per dependency.
>> 
>
> Not necessarily. We still use django-compressor, which copies all
> javascript into fewer files. E.g. here in my untweaked juno
> environment, I just get 3 instead of 10-15 following your logic above.
> (at least one js file per xstatic package).

Cool, I did not know about this!

Radomir said that this is run in a post-install hook for Horizon and
that he's unsure how or if the distros re-run the scripts when the
dependencies are installed. That is, if an updated version of the js-foo
package is installed, all apps that depend on js-foo would need to have
their JS bundles refreshed.

Or maybe it's simply run every time Horizon is started?

>> That's probably acceptable for an application like Horizon which
>> users will be using again and again, but for most web applications,
>> you don't want your users to download 10-20 small .js files, instead
>> you want them to download one minified and compressed file with all
>> the JavaScript code needed.
>
> see above :D
>
>> 
>> I'm just mentioning this since it's one way that web apps differ from
>> how normal Linux apps are typically deployed. Basically, web apps
>> prefer static compilation and discourages "dynamic linking".
>
> I'm not sure, I can really follow you here.

I was trying to draw a parallel to how traditional (C) programs use
dynamic when loading -- perfect for distributions since this allows them
to patch a security problem just once and know that all programs that
use the affected library will get the update since they dynamically load
the library at runtime.

Contrast this with static linking -- which is normally discouraged or
forbidden by distributions since you'll have to recompile all dependant
programs when you patch a library.

I was thinking that web apps look like statically linked programs when
they're deployed using compressed and minified sources for maximum
performance.

Let me add that this kind of optimization matters the most if your
visitors who only visit the app once or rarely. With a file per
dependency, they'll get poor performance since their browser won't have
cached the files.

For an app like Horizon it might not be as important: even if it loads a
little slow on your first visit, you're likely to visit it many times as
you admin your deployment and those subsequent visits will be faster.
Still not as fast as they would be if the server could reply with a
single "304 Not Modified", but probably fast enough.

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150121/23d3a8e4/attachment.pgp>