On 17 Mar 2012, at 10:54, rene7705 wrote: > On Fri, Mar 16, 2012 at 11:13 PM, Stuart Dallas <stu...@3ft9.com> wrote: > Why do you think other libraries such as jquery recommend minifying their > code before deployment, and then serving it via gzip? Every bit and byte > counts, especially as you scale up. > > The javascripts are currenlty being served unminified via gzip, because > minifying them all the time creates too much overhead for me. If you want > them minified you can easily do that yourself.
Write a script that does the minifying, and everything else necessary to create a distribution file. Do you really think someone manually runs jquery through the minifier whenever they create a new release? As it happens, they use make: https://github.com/jquery/jquery/blob/master/Makefile It seems you're pretty new to all this, and I appreciate that, but you show little to no willingness to learn from the people on this mailing list, despite asking for feedback. > Anyway, I'm not trying to get into an argument (it's rare that I do), but I > do recommend that you take in what I've said on this issue. The size of the > data you're sending down the pipe matters if you want your library to be used > for anything serious, and no amount of artwork or pretty pictures will > distract anyone for long. > > The download size will hardly be an issue for site operators, whom i > seriously suspect will be on faster links. > And the usage size doesn't have to be large, as mentioned earlier. This comment shows how little you understand about the world from your haven of high-speed internet. Part of the beauty of the internet is that it allows people to disseminate information on a shoestring. I guarantee that 90+% of the people behind the billions of websites in the world access the internet through what you would probably consider a stone age connection. It may surprise you to know that two thirds of the people on the planet do not have any access to the internet at all: http://www.internetworldstats.com/stats.htm > Just remember one thing: If you see something obviously wrong, why not send > me the fix? I will, if you pay me. Open source developers don't do what they do "just because it's there," at least not for the most part. They do it because their goals align with those of the project, or because the project presents a particular challenge. What are your goals for this project? Why did you develop it instead of using an existing library/framework? Here's why I won't be sending you any fixes… * There doesn't appear to be anything your library does that makes it stand out from the thousands of similar libraries that already exist, many of which are far more mature and have large numbers of contributors. * It's a very, very long way off being suitable for usage as a black box. * I see absolutely no value in using your library, either personally or professionally, never mind contributing to it. * Your attitude to the most basic and important advice you've been given practically guarantees that getting involved would be incredibly frustrating and fruitless. Oh, and in case it wasn't clear, you'd need to pay me *a lot*! I don't mean any offence, and I really do applaud your efforts, but in my opinion you need a sharp dose of reality. I encourage you to continue to work on your library because this sort of thing is usually a great learning experience, but don't expect people to help you out when your response to the most basic advice is "that's too much overhead for me." Add the fact that you didn't even respond to the very serious security issues I raised and you can't possibly be surprised if nobody wants anything to do with it. Oh, and it doesn't matter if that particular code is not actually used because it's likely indicative of the overall quality of the rest of the library. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
