"Ary Manzana" <a...@esperanto.org.ar> wrote in message news:jjmhja$3a$2...@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. > and leverages server processing time. It's the next step. It's not a > backwards step. :-P > It's the *newer* step. It may be "the future", but that's irrelevent: The question here is whether it's *good*, not whether it's popular or ubiquitous. Most real-world uses of it *are*, objectively, backwards steps. > I figure then Google people are just all a bunch of idiots who just like > JS a lot... Probably not all of them, but for the most part I frequently get that impression. Plus, keep in mind too, they have a *clear vested interest* in treating the web as a platform. Their whole business model relies on the web being treating as a platform. That, in turn, creates a (self-serving) need for them to push JS *regardless* of JS's merit. Without ubiquitus JS, the web has an even harder time competing with real platforms, and that pulls the rug out from under Google. They *are* a major corporation, never forget that.