[kwlug-disc] Learning Javascript

Sun Mar 14 09:49:57 EDT 2021

I found myself back in the same boat in 2013, and ended up trying to
learn/use JavaScript more.

Before then, I just dabbled with it using a healthy amount of disdain and
disinterest.

I'm certainly no expert in JavaScript, but a lot of comments from others in
this thread definitely struck a chord with me.

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....).

My two cents.
And yes, I'm still a Rust snob.

On Sun, Mar 14, 2021 at 5:21 AM Chris Frey <cdfrey at foursquare.net> wrote:

> Some thoughts from a non-expert.
>
> On Sat, Mar 13, 2021 at 01:12:16PM -0500, Paul Nijjar via kwlug-disc wrote:
> > - How does JavaScript want me to think?
>
> If you're talking about the browser, think Document Object Model (DOM),
> and the events that trigger from it.  Javascript runs single-threaded.
>
> The initial DOM is created from the HTML file.
>
> The javascript within that HTML file, or included from it, can update
> the DOM programmatically.  The DOM itself can have events that link
> back into the code, such as onclick="" attributes in the HTML
> which call javascript functions on user input.
>
> Example of non-event style javascript:
>
>         <!DOCTYPE html>
>         <html> <head> <meta charset="utf-8"> </head>
>         <body> </body>
>         <script>
>
>         function print(msg) {
>                 document.write("<p><b>Print:</b> " + msg + "</p>");
>         }
>
>         print("Hello world");
>
>         </script>
>         </html>
>
> Here, the DOM starts with a blank body.  The embedded javascript defines
> a print() function.  Then calls it once, which updates the body
> with more HTML elements, such as <p>, <b>, etc.  You'll see the
> end result if you use your browser's Inspect feature.
>
> You can use javascript to search the DOM, add, edit, and remove
> elements of the webpage on the fly, or as a result of events.
> The webpage becomes a dynamic, interactive UI this way.
>
> Rob Gilson said: "Don't learn jQuery if you can avoid it."  I think
> you won't be able to avoid it in the long run, but in my opinion,
> the reason to avoid jQuery is that it will usually invert the
> framework way of thinking.
>
> Frameworks abstract the heavy lifting of DOM updates.  They do an
> amazing job of it, with techniques that are not immediately obvious.
> Without them, you either use vanilla javascript to manipulate the
> DOM using C-like code, or you use jQuery which introduces its
> own mechanisms to speed up such manipulations.  But either way,
> you're still in the mode of a programmer poking and peeking at the
> DOM and trying to keep the whole thing organized manually.
> Frameworks break you out of that mode.
>
> For example:
>
> 1) Vanilla HTML:
>         <p id="status"></p>
>         <button id="save-btn">Save</button>
>
>
> 2) Vanilla javascript:
>         JS:
>         // attach a handler for the button, so when clicked, it updates
>         // the status field
>         document.getElementById('save-btn').onclick = function onSave() {
>                 document.getElementById('status').innerHTML = "Saving...";
>                 ...
>         }
>
> 3) jQuery:
>         JS:
>         // same thing, using jQuery
>         $("#save-btn").click(function() {
>                 $("#status").html("Saving...");
>                 ...
>         })
>
> As you can see, jQuery is basically syntactic sugar overtop of
> what you would normally write in vanilla javascript.  But it doesn't
> give you a structure to work with.
>
> A framework would encourage you to put different screens
> in different files, and make entire sections of your screen potentially
> reusable.  It would also give you special variables that once
> they are bound to UI elements, they update themselves, so there's no
> manual get/set labour.  It would also give you a way to manage
> dependencies between javascript modules, similar to how Python
> supports import, so you can reuse entire modules, and start treating
> them like classes or singletons.
>
> It's good to play with vanilla javascript a bit to get the hang of it,
> in my opinion, but don't wait too long before trying out a framework.
>
>
> > Some overview articles would be good to start, followed by some
> > hands-on tutorials that illustrate language features step by step. I
> > do not think I want to commit to some six month course right now, but
> > if you know of good ones then pass them along.
>
> All I have to share right now is my own personal notes on javascript
> prototypes and inheritance.  It is very complex, but it *is* step by step.
> Not really beginner friendly tho, so maybe save it for later.  It does
> show how to arrange an HTML file for programmatic JS experiments.
>
> To use it, load file:///tmp/jsproto.html in your browser,
> then read the source at each step to understand what it does.
>
> - Chris
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20210314/d1b753c3/attachment.htm>