3 ms·

>> First, it's about the same size as Moot as a whole (91kb) I am feeling a bit of a fool to ask that but... what's the obsession with the code size when it co

by gedrap 13y ago

>> First, it's about the same size as Moot as a whole (91kb) I am feeling a bit of a fool to ask that but... what's the obsession with the code size when it comes to client side JS? Bandwidth? Well, unless you are running at Google's scale, some extra bandwith is much cheaper than the time spent on writing your own solutions to well known and solved problems (and some of the problems you were not aware of yet). Performance, since more code - more stuff to execute - will take longer? It's good to have performance in mind and maybe benchmarks will tell you that it's X times faster but what will it be once translated to seconds?

adamcw 13y ago
Bandwidth concerns cut both ways. I typically worry less about my server being able to serve it, than I do about the client having to receive it. For desktop users it's less of an issue, but site size matters a great deal to mobile users. At least that's where I tend to worry about it, not sure if this is the common reason.
robmcm 13y ago
They want small JS files so their designers can have a 2MB background image...
owenversteeg 13y ago
As I said here (https://news.ycombinator.com/item?id=7032169 https://news.ycombinator.com/item?id=7032169) it's usually because of front-end performance. Users are very concerned with performance, and loading a 150kb library doesn't help. The extra kilobytes translate into seconds at an alarming rate if you're not on Google Fiber, and I've found that in rural NH Bootstrap usually takes 3 seconds to load vs. Min takes 300ms to load. Min (http://minfwk.com http://minfwk.com) is a 995 byte CSS framework I made to deal with the slow loading times of other CSS frameworks.
ultimatedelman 13y ago
it all comes down to load times. because users will leave if a page takes a long time to load, the less code you have to transfer over the wire, the better. it is different from server side code because it must be transferred and executed by the user. also, this applies heavily to mobile. not everyone has high-speed internet connections or wifi on their phones, so the less data transfer you have, the faster your page will load, and the less likely your user will leave before it's done loading.

by gedrap 13y ago

adamcw 13y ago

Bandwidth concerns cut both ways. I typically worry less about my server being able to serve it, than I do about the client having to receive it. For desktop users it's less of an issue, but site size matters a great deal to mobile users. At least that's where I tend to worry about it, not sure if this is the common reason.

robmcm 13y ago

They want small JS files so their designers can have a 2MB background image...

owenversteeg 13y ago

As I said here (https://news.ycombinator.com/item?id=7032169 https://news.ycombinator.com/item?id=7032169) it's usually because of front-end performance. Users are very concerned with performance, and loading a 150kb library doesn't help. The extra kilobytes translate into seconds at an alarming rate if you're not on Google Fiber, and I've found that in rural NH Bootstrap usually takes 3 seconds to load vs. Min takes 300ms to load. Min (http://minfwk.com http://minfwk.com) is a 995 byte CSS framework I made to deal with the slow loading times of other CSS frameworks.

ultimatedelman 13y ago

it all comes down to load times. because users will leave if a page takes a long time to load, the less code you have to transfer over the wire, the better. it is different from server side code because it must be transferred and executed by the user. also, this applies heavily to mobile. not everyone has high-speed internet connections or wifi on their phones, so the less data transfer you have, the faster your page will load, and the less likely your user will leave before it's done loading.