Arbitrary abbreviations in phobos considered ridiculous

Ary Manzana ary at esperanto.org.ar
Tue Mar 13 05:25:15 PDT 2012


On 03/13/2012 01:52 AM, Nick Sabalausky wrote:
> "Ary Manzana"<ary at esperanto.org.ar>  wrote in message
> news:jjmhja$3a$2 at digitalmars.com...
>> On 03/12/2012 10:58 PM, H. S. Teoh wrote:
>>>
>>> The problem today is that JS is the "next cool thing", so everyone is
>>> jumping on the bandwagon, and everything from a single-page personal
>>> website to a list of links to the latest toaster oven requires JS to
>>> work, even when it's not necessary at all. That's the silliness of it
>>> all.
>>>
>>>
>>> T
>>
>> It's not the next cool thing. It makes thing more understandable for the
>> user. And it makes the web transfer less content,
>
> That gets constantly echoed throughout the web, but it's a red herring: Even
> if you handle it intelligently like Adam does (ie, lightweight), the amount
> of data transfer saved is trivial. We're talking *part* of *one* measly HTML
> file here. And even that can be gzipped: HTML compresses *very* well. Yes,
> techincally it can be less transfer, but only negligably so. And bandwith is
> the *only* possible realistic improvement here, not speed, because the speed
> of even a few extra K during a transfer that was already going to happen
> anyway is easily outweighed by the overhead of things like actually making a
> round-trip to the server at all, plus likely querying a server-side DB, plus
> interpreting JS, etc.
>
> If, OTOH you handle it like most people do, and not like Adam does, then for
> brief visits you can actually be tranferring *more* data just because of all
> that excess JS boilerplate people like to use. (And then there's the
> start-up cost of actually parsing all that boilerplate and then executing
> their initialization portions. And in many cases there's even external JS
> getting loaded in, etc.)
>
> The problem with optimization is that it's not a clear-cut thing: If you're
> not looking at it holistically, optimizing one thing can either be an
> effective no-op or even cause a larger de-optimization somewhere else. So
> just because you've achived the popular goal of "less data transer" upon
> your user clicking a certain link, doesn't necessarily mean you've won a net
> gain, or even broken even.

True.

I always have to remember this interesting talk about saying "This is 
faster than this" without a scientific proof:

http://vimeo.com/9270320


More information about the Digitalmars-d mailing list