search

matthiasbock / BooleSim

Systems biology tool: Boolean network simulator
http://matthiasbock.github.io/BooleSim
11 stars 6 forks source link

Speed up site loading #7

Open chaitan3 opened 11 years ago

chaitan3 commented 11 years ago

During GSoC, I had minimized the number of files that need to be fetched by the browser to speed up the site loading. I think all the js files need to be squashed into 1 or 2 files. Secondly to speed up the js code on the site, all the libraries must be in minified form. This ensures that the browser does not waste time in interpreting line endings and spaces and long variable/function names.

Maybe we could do what biographer ui does, do the development in a number of files and then combine them all to a single file.

matthiasbock commented 11 years ago

Well, sure, quick site loading is nice to have, but I think for this project it is of secondary importance:

First, I don't really feel, it's too slow right now. It works quite fluently on my computer, I use a dual-core 1,7 GHz i386.

Secondly, I generally dislike the approach of JavaScript "compression". You wouldn't put compiled C programs into a repo either. And, whatever kind of compression we could do manually, the browser could also optimize by itself. Also, this is not the concept of JavaScript, which is generally not "compiled" on the programmer side. We could have used Java then.

Third, I consider it very important, that developers, potential forkers/future developers and also the everyday users are capable of quickly reading into code behind specific functions. This requires code parts, which functionally belong together, to be separated into distinct module files, which are ideally named after their corresponding content/functino. Also, it requires meaningful naming of variables and functions and also a nice and consistent code formatting.

Fourth, this is important for this project especially, because our intended audience is the scientific community. There will be experts and programmers among them, so we can expect the users to want to make personal adjustments to the code, so being able to quick and easy read into it can decide about the general acceptance of our software.

chaitan3 commented 11 years ago

Agreed that the speeding up of the site is not a priority, we could fix it later. Right now, for the paper, this issue is not important, but in case our software grows larger and incorporates a lot of features like in biographer-ui, we would be compelled to switch to a system of combining and minifying for JS performance and speed of loading. Currently the site loads in 4 seconds in India. Doubling the size of our code would make it close to 6-8 seconds, which is unacceptable.

Also it is correct that potential developers should be easily be able to read the code. But, normally if a user wishes to look at the source code, he/she will normally make a clone of the repo. This will contain the development version of our software, having separate js files whereas the combined version will be deployed to the web server and not hosted in the repository. I don't foresee users directly trying to read the source code of the website using a browser(It would be too complex), their first instinct would be to download the source code or browse the github repository. But that's just my opinion, for now I will concentrate on fixing the other bugs and let's have a discussion on this later.

matthiasbock commented 11 years ago

Okay. If you really think, it is necessary, we can introduce it at some point :-)

You thought of a Makefile, that compresses the present code and packs everything into one "BoNeSim.html", right ?

chaitan3 commented 11 years ago

Yeah, the Makefile will do fine, a single cat command along with node-uglify does the job.