<div dir="ltr">I found myself back in the same boat in 2013, and ended up trying to learn/use JavaScript more. <div><br></div><div>Before then, I just dabbled with it using a healthy amount of disdain and disinterest.<div><br></div><div>I'm certainly no expert in JavaScript, but a lot of comments from others in this thread definitely struck a chord with me.</div><div><br></div><div>What I can add, is that coming from a primarily C/C++ background, I found JavaScript incredibly boring to play with until I had a real project to work on with it. I also found that I had to dive right into a framework for this project to keep it interesting for me (in my case, Node.js, which is brilliant and the one I've spent the most time with since). I did another project with Angular after (easy learning curve and used for our triOS XCAS frontend), and have more recently played with React (higher learning curve than Angular IMO). I know nothing about Vue other than there's a documentary about it (which makes it sort of creepy....).</div></div><div><br></div><div>My two cents.</div><div>And yes, I'm still a Rust snob.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 14, 2021 at 5:21 AM Chris Frey <<a href="mailto:cdfrey@foursquare.net" target="_blank">cdfrey@foursquare.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Some thoughts from a non-expert.<br>
<br>
On Sat, Mar 13, 2021 at 01:12:16PM -0500, Paul Nijjar via kwlug-disc wrote:<br>
> - How does JavaScript want me to think?<br>
<br>
If you're talking about the browser, think Document Object Model (DOM),<br>
and the events that trigger from it. Javascript runs single-threaded.<br>
<br>
The initial DOM is created from the HTML file.<br>
<br>
The javascript within that HTML file, or included from it, can update<br>
the DOM programmatically. The DOM itself can have events that link<br>
back into the code, such as onclick="" attributes in the HTML<br>
which call javascript functions on user input.<br>
<br>
Example of non-event style javascript:<br>
<br>
<!DOCTYPE html><br>
<html> <head> <meta charset="utf-8"> </head><br>
<body> </body><br>
<script><br>
<br>
function print(msg) {<br>
document.write("<p><b>Print:</b> " + msg + "</p>");<br>
}<br>
<br>
print("Hello world");<br>
<br>
</script><br>
</html><br>
<br>
Here, the DOM starts with a blank body. The embedded javascript defines<br>
a print() function. Then calls it once, which updates the body<br>
with more HTML elements, such as <p>, <b>, etc. You'll see the<br>
end result if you use your browser's Inspect feature.<br>
<br>
You can use javascript to search the DOM, add, edit, and remove<br>
elements of the webpage on the fly, or as a result of events.<br>
The webpage becomes a dynamic, interactive UI this way.<br>
<br>
Rob Gilson said: "Don't learn jQuery if you can avoid it." I think<br>
you won't be able to avoid it in the long run, but in my opinion,<br>
the reason to avoid jQuery is that it will usually invert the<br>
framework way of thinking.<br>
<br>
Frameworks abstract the heavy lifting of DOM updates. They do an<br>
amazing job of it, with techniques that are not immediately obvious.<br>
Without them, you either use vanilla javascript to manipulate the<br>
DOM using C-like code, or you use jQuery which introduces its<br>
own mechanisms to speed up such manipulations. But either way,<br>
you're still in the mode of a programmer poking and peeking at the<br>
DOM and trying to keep the whole thing organized manually.<br>
Frameworks break you out of that mode.<br>
<br>
For example:<br>
<br>
1) Vanilla HTML:<br>
<p id="status"></p><br>
<button id="save-btn">Save</button><br>
<br>
<br>
2) Vanilla javascript:<br>
JS:<br>
// attach a handler for the button, so when clicked, it updates<br>
// the status field<br>
document.getElementById('save-btn').onclick = function onSave() {<br>
document.getElementById('status').innerHTML = "Saving...";<br>
...<br>
}<br>
<br>
3) jQuery:<br>
JS:<br>
// same thing, using jQuery<br>
$("#save-btn").click(function() {<br>
$("#status").html("Saving...");<br>
...<br>
})<br>
<br>
As you can see, jQuery is basically syntactic sugar overtop of<br>
what you would normally write in vanilla javascript. But it doesn't<br>
give you a structure to work with.<br>
<br>
A framework would encourage you to put different screens<br>
in different files, and make entire sections of your screen potentially<br>
reusable. It would also give you special variables that once<br>
they are bound to UI elements, they update themselves, so there's no<br>
manual get/set labour. It would also give you a way to manage<br>
dependencies between javascript modules, similar to how Python<br>
supports import, so you can reuse entire modules, and start treating<br>
them like classes or singletons.<br>
<br>
It's good to play with vanilla javascript a bit to get the hang of it,<br>
in my opinion, but don't wait too long before trying out a framework.<br>
<br>
<br>
> Some overview articles would be good to start, followed by some<br>
> hands-on tutorials that illustrate language features step by step. I<br>
> do not think I want to commit to some six month course right now, but<br>
> if you know of good ones then pass them along. <br>
<br>
All I have to share right now is my own personal notes on javascript<br>
prototypes and inheritance. It is very complex, but it *is* step by step.<br>
Not really beginner friendly tho, so maybe save it for later. It does<br>
show how to arrange an HTML file for programmatic JS experiments.<br>
<br>
To use it, load file:///tmp/jsproto.html in your browser,<br>
then read the source at each step to understand what it does.<br>
<br>
- Chris<br>
<br>
_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org" target="_blank">kwlug-disc@kwlug.org</a><br>
<a href="https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" rel="noreferrer" target="_blank">https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote></div>