hi,
The second idea will be described in the form of scenario. Assuming that a web app, depending on dojo library, has been finished and will be released. They found a performance issue about long load time, so they optimize their js through ECMAScript Cruncher, but the size of their js is still too big. So the programmers develop a compressing tool to
- Break the js into 1160bytes /piece
- Compress them
, which works like winrar.
In this way, all of js has been compressed and can be transferred more fast, but in the browser they can not run. So they have two choices:
- Develop a firefox plug-in to decompress the compressed js
- Transfer a tool-like js used to decompress the compressed js.
At last, the issue about long load time has been resolved successfully. So my idea is to provide the functionality to compress/decompress js.
why 1.1kb/piece?
and you know dojo dose have a powerful js builder? (which shoud be more featureful than ECMAScript Cruncher)
in addition, js can be gzip-ed (along as any other text based files) and all modern browsers support that, why you need to introduce another level of compression? or you are trying to achieve something else, like better compression ratio?
I think I am not sure what you are trying to solve and how
--
http://www.liucougar.net
生于忧患，死于安乐
"People's characters are strengthened through struggle against difficulties; they are weakened by comfort."
- Old Chinese adage
re: why 1.1kb/piece
hmm
This sounds like it will run much slower than the current code. The network layer already splits things into packets for us, so I don't see any advantage to us doing it ourselves. But more importantly, this idea would require lots of GET calls to the server, and latency becomes a big problem, bigger than it is now. The builder for dojo actually combines lots of little files into one big file to make things go faster, since the client only needs to issue one GET request to the server.
We do need to do something for iPhone which has a 25K limit on JS files but that seems unrelated.