Re-implement compression of .js and html

[justinclift]

As a general concept, it would be really good for us to get compression/minimisation of the .js and html/css working again.

That should significantly reduce the client side load time, especially when hosted on a PaaS, like our OpenShift instance.

Probably the best way to "control" this, would be through a variable in the config file to enable/disable compressing the client side js/html/css at start time.

• If the variable is set to true at server start time, it runs the compression sequence (external script?), serving the result as the client side code.
• If the variable is not set to true at server start time, the uncompressed js/html/css is used instead

[Aaron1011]

The current compression script (bin/build.sh) seems to compress everything properly. However, it removed everything except a few files from the client-build directory, which a comment describes a "unnecessary". Do you know why that is?

[justinclift]

Nope. :smile:

I don't have much experience with javascript minimisation tools, and the current compression script used to "break" stuff. I don't remember what exactly though. :frowning: Faint memory kind of says it wasn't compressing everything ok, and there was newer/better compression stuff available we could have looked at.

But, no-one had the time/skill, so, we just removed the step about using it from the instructions.

Now things are starting to look a bunch better, and we're PaaS hosted, it's probably time to get this fixed. :smile:

[justinclift]

You could be right though, and it's just removing too much stuff. Not sure. :smile:

[Aaron1011]

Actually, now that I look at is closely, I think that r.js is actually doing all of the minimization itself. UglifyJS is a popular minimization library, should we switch to that?

[justinclift]

Heh, my standard answer applies here:

Try it out, if the result seems good to you, make it a PR.

:smile:

[justinclift]

Interestingly, UglifyJS seems possible to install using npm. So, we can just add it to the dependencies list. :smile:

[justinclift]

This has been completed by @Aaron1011 in PR #78.

Good stuff Aaron! :smiley:

[justinclift]

Re-opening, because our first attempt turned out to not work so well.

We might need to take a different approach instead, that doesn't rely on spawning external things asynchronously. (not sure)

[lzbk]

I haven't followed the previous attempt, so bear with me if I'm completely off-topic :-S Couldn't we just create a src/ directory and a release/ directory ? Minifying once and for all, the src before committing each new version. We still would have to devise a minifying script that works, that we could include in a makefile or apache ant script, but that would solve the problem of multiple calls to the minifier. PhotoSwipe provides good examples of such scripts. They use apache ant, to call the closure compiler to minimize a concatenated version of all their source files, after checking its syntax with jslint. cf. https://github.com/codecomputerlove/PhotoSwipe/blob/master/build.xml I'm not saying we should use the same technology, especially since browserquest uses "require.js" a lot, which might make concatenation of source files quite complex (even though it could improve performance as well). In a nutshell, if the minimize.js script used by @Aaron1011 works well when called manually to create a "release" version of the code before comitting, maybe that's an approach we could use. What do you think ?

[justinclift]

@lzbk - Well, the previous attempt used a shell script created by Aaron, (uglify.sh) that works outside of OpenShift.

The problem seemed to be how OpenShift ran it. The Node process that launched it would be terminated every time without explanation, but leaving the uglify.sh scrip running. OpenShift would detect the "crashed" Node.js, and start it up again... leaving to many versions of uglify.sh running at the same time, all trying to minimise the same intput files / overwrite the same output files. Kind of a mess. :laughing:

Having the minimisation script instead run at (say) git commit time, with the minimised version also being committed... that could work well too.

I wonder if that's the kind of thing that git "hooks" do? I haven't used them before, but suspect it might be what they're about.

[Aaron1011]

I think that a git hook would be a great way to do this. To work, they need to be placed in the .git/hooks directory in a repo, which isn't tracked by Git. We could take a similar approach to the Kivy project, which put a command in their Makefile to install the hook.