Elbowing JavaScript out
31–40 of 100 posts
Re: Elbowing JavaScript out
#32Re: Elbowing JavaScript out
#33Re: Elbowing JavaScript out
#34Re: Elbowing JavaScript out
#35"The amygdala is an almond-shaped structure in the brain".
Coincidence?
Re: Elbowing JavaScript out
#36Oh, weird, that stuff uses JS. Huh.
Re: Elbowing JavaScript out
#37is "Amy G Dala" a fake name? I put it in google and got "The amygdala is an almond-shaped structure in the brain". Coincidence?
Re: Elbowing JavaScript out
#38I'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...
[2]Donald Knuth: 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.
Re: Elbowing JavaScript out
#39The 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. This is why with React-style views[1] I feel like I'm finally learning how to write web applications. The DOM is always in a pristine state. [1] Specifically I'm using Mithril, but the architecture is the same in React, and similar now in Ember.
Further paralleling your own journey, I now reach for Mithril first too, and I can't recommend it enough.
Re: Elbowing JavaScript out
#40The worst part of JavaScript is that the relevant committee is simply failing to acknowledge that there are lots of bright computer language designers out there who'd love to have a chance to bring their creations to the web.
Doesn't WebAssembly allow them to bring their creations to the web?