Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 327453

Summary:	Compress all JavaScript at runtime
Product:	[RT] RAP	Reporter:	Ralf Sternberg <rsternberg>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	b.muskalla, fr.appel, ruediger.herrmann, stephan.leichtvogt
Version:	1.4
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:	plan-version=1.5 plan-theme=development plan-status=proposed
Bug Depends on:
Bug Blocks:	338647

Description Ralf Sternberg

2010-10-11 10:36:05 EDT

If we could improve our Javascript compression, we could consider compressing all Javascript at runtime. To do so, we should consider integrating an existing compressor such as the YUI compressor http://yuilibrary.com/projects/yuicompressor/ or the Closure Compiler http://code.google.com/closure/compiler/.

Expected benefits:
* the additional step of creating pre-compiled Javascript files using a third-party tool would become obsolete
* custom Javascript code would also benefit from the improved compression
* standard and debug variant could not differ, which can now happen by mistake

Possible problems:
* the compression might slow down the initial start time, we need to evaluate that

Comment 1 Benjamin Muskalla

2010-10-11 10:55:10 EDT

You should be careful with approaches like the closure compiler. The last time I checked it, it did the same thing as GWT - dead code elimination. Without a client-side protocol handler, this can be problematic as either the code that is called from the LCAs isn't there anymore or has another name.

Comment 2 Tim Buschtoens

2010-10-11 10:58:21 EDT

This would also enable us (in theory) to create browser- or application-specific client-code, decresing the size of javascript that needs to be transported and parsed.

Comment 3 Ralf Sternberg

2010-10-11 17:34:52 EDT

(In reply to comment #1)
> You should be careful with approaches like the closure compiler. The last time I
> checked it, it did the same thing as GWT - dead code elimination. Without a
> client-side protocol handler, this can be problematic as either the code that is
> called from the LCAs isn't there anymore or has another name.

If this code elimination is not optional, it would of course disqualify the Closure Compiler. Even with a protocol handler this would exclude any custom widgets.
But the YUI compressor seems to do a very good job (see bug 327451)!

Comment 4 Ralf Sternberg

2011-02-05 04:48:12 EST

With the approval of CQ 4536, the subset needed from the YUI Compressor can now be checked into our CVS.

Comment 5 Ivan Furnadjiev

2011-03-31 06:24:18 EDT

YUI Compressor is in CVS. client.js is not needed anymore as YUI Compressor compresses the javascript files at runtime in "standard" mode. In "debug" mode the javascript files are delivered uncompressed.

Comment 6 Rüdiger Herrmann

2011-03-31 06:57:37 EDT

Does this change affect the startup time of RAP?

Comment 7 Ivan Furnadjiev

2011-03-31 07:24:07 EDT

We do the measurement before the actual integration and the results are the following - measurement is done in DisplayLCA#writeLibraries:
1. with client.js - average time of 10 measurements is 1948 ms
2. with YIU compression - average time of 10 measurements is 2314 ms
We loose ~350ms from the startup time witch is about 15%.

Comment 8 Ivan Furnadjiev

2011-03-31 07:34:09 EDT

I did the measurements again with the current CVS HEAD - measurement is done in DisplayLCA#registerResources. The average time needed for QooxdooResourcesUtil.registerResources(); is 2250ms.

Comment 9 Ivan Furnadjiev

2011-03-31 08:10:04 EDT

I reverted the last changes as my last measurements of the startup time show different result than before.

Comment 10 Austin Riddle

2012-02-29 12:46:07 EST

Is there anything we can do to make this a reality for 1.5?

Comment 11 Ivan Furnadjiev

2012-02-29 13:03:11 EST

We have it in our list for M7.

Comment 12 Ralf Sternberg

2012-11-03 13:51:22 EDT

Compressing all JavaScript at runtime would delay the startup by roughly 2 seconds. While this is certainly acceptable at deployment time, it would further impede the development-deploy-test cycle. Therefore we agreed not to do this at the moment.

I've opened bug 393496 to move the clientbuilder into the RAP repository. This will make it easier for others to re-built the client.