>Then observe how much javascript it actually used. It’s used a ton because we have been given the tool, and in having this tool, we use it. I'm not convinced

>Then observe how much javascript it actually used. It’s used a ton because we have been given the tool, and in having this tool, we use it. I'm not convinced of this reasoning. I think computing history has shown repeatedly that many ideals of declarative purity will give way to something that becomes Turing Complete. (E.g. config files with IF-THEN/GOTO[1], SQL that includes "stored procedures" with loops, TeX typesetting language adds Turing-Complete programmability[2], etc) Thought experiment... imagine a different starting point of browsers where there was only HTML/CSS but no Javascript engine. Wouldn't the pent up desire for some "programmability" in web pages eventually lead one of the browser vendors to add new HTML "logic" tags that have if/else/goto/loop? Or a vendor adds CSS "extensions" with eventual Turing Complete power? Once one browser adds it, the others copy it and we have the same situation of "program code" on the client browser. Maintaining 25 years of no programming logic power on browsers since the 1990s Mosaic browser does not seem realistic. In other words, if it wasn't Brendan Eich's Javascript to dynamically mess with the webpages, it would have eventually been something else to provide similar powers. >The page loads, then, afterward, you tell some scripts in the footer to observe the presentation in this pristine state, then to go around and mess about with it. Is there any other place in the stack where we architect code to work like this? I don't know what is meant by "other place in the stack" but in the wider computing world, MS Windows Forms (WinForms) works like this. You have ".frm" files with the "declarative" widget placements and then C#/VB code that can hide/unhide, resize, add GUI elements, etc. Other GUI toolkits (C++ Qt) work the same way. >But the frontend? So I’d agree that it’s here to stay. But I don’t think we have to embrace it for all web stuff as much as we have. With mobile phones and many desktops experiencing 100ms to 500ms network latency, what's the alternative? If a web surfer updates a shopping cart from quantity of 2 to 3, is it really the best practice to have the server rebuild the entire page and resend the result of "subtotal=price x quantity" to the client just so we maintain ideological purity of no Javascript on the web browser? Most users would find the constant page refreshes to be sluggish and not user-friendly. [1]http://stackoverflow.com/questions/648246/at-what-point-does-a-config-file-become-a-programming-language http://stackoverflow.com/questions/648246/at-what-point-does... [2]Donald Knuth: http://maps.aanhet.net/maps/pdf/16_15.pdf http://maps.aanhet.net/maps/pdf/16_15.pdf excerpt: In the 70s, I had a negative reaction to systems that tried to be all things to all people. Every system I looked at had its own universal Turing machine built into it somehow, and everybody’s was a little different from everybody else’s. So I thought, “Well, I’m not going to design a programming language; I wanted to have just a typesetting language.” Little by little, I needed more features and so the programming constructs grew. Guy Steele began lobbying for more capabilities early on, and I put many such things into the second version of TEX, TEX82, because of his urging. That made it possible to calculate prime numbers as well as do complicated things with page layout and figure placements.