Introduce a perfect cache for generated JavaScript code

[mirkosertic]

There should be a generated JavaScript file per compiled jar or classes folder. Also, the file name should be unique to prevent proxy server caching from destroying the application. This is already implemented by GWT as a "perfect cache".

[Prototype1]

I want to create a small sheet tomorrow about how the compiler works and which classes do the different work. That should be helpful to adjust different tasks. The current code is everything but clean and readfrienly

[mirkosertic]

Perfect, looking forward to it!

[Prototype1]

Look at my pull request. Sadly it is not as much as i wanted to write but it is really time consuming to understand what is actually going on. As far as i see it wont be easy to extend any of the current features the code isnt really readfriendly almost messy. I would try to fully overwork Project.java, Assembly.java, DragomeJsCompiler.java and Parser.java

[fpetrola]

Yes I know it's messy, you can get some help taking a look at original code from j2js project. it's almost the same compiler architecture and most changes are related to generated js code in DragomeJavaScriptGenerator

[Prototype1]

Maybe i have time tomorrow to create small class model of what a better arichtecture would look like

[mirkosertic]

well, the SingleClassEntryPoint looks like it was intended to write only the required classes as JavaScript. I fiddled around with it a few hours but still do not get how the tainting mechanism effectively works.

What the exporter should do: scan the entry point class file and go recursively over all dependency of the class and mark it as to be exported.

Finally, write all marked classes as JavaScript including the framework code.

The current implementation seems a little bit buggy, At least it scans all dependent classes, but when i take a look at the code, it seems to be completely empty.

[Prototype1]

Yep. I would like to write something to replace the current design.

[mirkosertic]

That would be great! Here is a short blog entry about perfect caching:

https://blog.oio.de/2014/10/01/javascript-caching-adopting-perfect-caching-for-js-apps/

We should implement something like this i think.

[Prototype1]

I will add you to my Dev branch as contributer. So you can commit changes without creating a pull request.

[fpetrola]

What is the difference of using a query string parameter with last compile timestamp?

.../webapp.js?compiled=34635455456787

[mirkosertic]

Well, perfect caching will save client server roundtrips. The JavaScript is downloaded ONCE to the client and then cached forever(as long the user does not clear the history). Using a get parameter will always trigger a roundtrip to the server, which will either send a new version to the client or a not modified response. The client will do this for every served html page and every page refresh, so get parameters are not as performant as perfect caching in terms of network usage and browser response time.

[Prototype1]

and i guess the timestamp is there to verfiy that the browsers cached .js version is the current version that the server supplies.

Else the browser would display an older version of the .js