Consider minifying the angular package
tushar-rishav opened this issue · 6 comments
We could minify the js, html etc related to angular files before packaging.
Pros:
- Significant reduce in size and hence the pip package.
Cons
- Users might have to deminify if they wish to modify the angular code at their side. Otherwise, it won't be readable at all.
As an user, I am inclined towards Pros as the reduction in size would be more than 50%. it would be like saving 20-30 KBs. I agree it's very small size but again why not save it if we could.
As a hacker, people might wanna customise the application and use it as per their needs. Not sure about its possibility.
Thanks for reporting this issue!
@coala-analyzer/coala-contributors, your aid is required, fellow coalaian. Help us triage and solving this issue!
As a "hacker", you can always deminify if you want to edit. I think you should minify it definitely, more so if the performance increase is whopping 50%
I don't see 30kb to be much.
If you really want to save on bandwidth, then you would want to remove bower, and just serve the angular.min.js and bootstrap.min.css - as those will reduce the downloads required by much more than 30kb
BTW: when you calculated 20-30kb, did you compare the final pypi packages ? Or the minified js file vs the non minified one ? Because the tar.gz compression python setup.py sdist does will reduce that number further I think.
Also, if you want to further decompress it, consider making a python wheel ^_^ And also, reducing the number of files (i.e. move all controllers to one file, etc.)
@AbdealiJK
A. Yeah. 30kbs isn't a lot. But I thought why not save those 30kbs if we could do it. My thought was to minimise the overall size of the angular package. Now I think bower is necessity here? Packaging with angular files would further increase the size - by few kbs. Moreover, we will be getting the updated dependencies via bower. I don't see any other PROs of using bower. Should we remove bower and go with packaging static dependencies along with binary package? Hm it's debatable.
B. For now I have just considered js files. So the reduction of 20-30 kbs is because of js+html files only.
But yeah I think sdist will do that dirty work significantly. So I think maybe we could just leave for now. Not sure if it's wise.
I'd say keep it low priority - after your gsoc deliverables are done
but if you access the page a 1000 times, 50kb -> 50mb
but I agree with @AbdealiJK , low priority, first get things to work, then optimize :)