Back to basics (of Javascript?)

I've seen a lot written recently about returning to the "basics" of javascript (some of these do make good points), and some rebuttals to this notion, and some that take my PoV.  The "return to basics" camp appear to me to be relative newcomers to the software industry (by relative I have 25 years doing professional development, and another 10 or so before that of hacking things on my own).  I think these people didn't have to come up through the age of learning assembly, learning c/c++, and then, thank god, having the higher level languages become available.   I've seen some say that javascript is the assembly language of the web, and if that's true, why the hell would we want to write in it if there is a higher level language (typescript, web assembly can be written in almost any language at this point) available.  You don't want to go back and write programs in assembly (alright, maybe some do, but they are a special breed) when you have c#, python, java, etc available, right?  That's like saying "Ok, I have a hammer, let me go build a skyscraper with it."  You're going to need a few more tools in order to do that, and if you don't buy them, you're going to have to make something someone else has already made.  Yes I know a lot of people will complain "but tool XYZ doesn't do exactly the thing I need", well, use the tool for what you can, and put pieces together to make something, that's what engineers and architects do.  They don't stand around complaining "Oh, this circular saw has a 12" blade, I have to have one with a 12.5" blade.  You make it work.

I particularly love this quote

"Software should be developed using least amount of complexity, dependencies, effort and using fundamental tools that have been and will be here for the next 20 years."

Who in the hell thinks their software is still going to be running in its current form in 20 years?  If by some miracle it is, then it's the problem of the people running it to make sure the same tools and assumed environment are available to run it.  You don't see people expecting software from windows XP to continue to run on Windows 10 (well, maybe some people do, but hey it takes all kinds in this world).  The underlying hardware and software have just changed to much for that to be feasible.  Yes, you can run a VM that will probably get you 90+% of the way there, but some programs were written to directly access hardware and that hardware just isn't around any more, or make assumptions about memory allocation, there are all kinds ways the old programs just won't work.

Another one I like:

You take a risk whenever you bring in 3rd party code. This risk is reduced with tried and tested libraries/frameworks, but never truly eliminated. If you can get away with writing code yourself or with your team, you can reduce that risk and maintain a codebase that you know in and out.

What is the risk that we're taking?  That the code will disappear?  Unlikely for many reasons.  The risk that the code won't do exactly what we want?  Use it for what you can, or fork it and make it do what you want.  I would propose the bigger risk is creating something on your own where you don't have the time to think through all the ramifications, whereas you could be helping a group (hopefully) of people who are already working on the problem, adding your knowledge to theirs.  That's what OSS is all about really.

I'm not saying don't learn the basics and the underlying technology and the context in which these were built, learning this will absolutely make you a better programmer/developer in general, but learning something doesn't mean you are going to or should use it in your day to day activities.  I took 4 years of Latin in high school with no pretense of actually speaking it, but it is extremely useful as a lot of languages derived from it, and I can very often get a basic understanding of a word based on its derivation from Latin.  So please, learn all you can about computer science and the history that brought it to its current form, but please don't re-invent the wheel whenever you have to travel somewhere.

I know people don't like change in general, but if you're any kind of developer/programmer, you better thrive on it, and love it, because the rate of change is just going to keep on increasing.  No, you're not going to be able to know everything, pick some areas that you like, and learn them, and keep learning them.  You will get paid for knowing them, if that's your goal.  If you don't like change, go learn Assembly or FORTRAN or COBOL.  I'm sure some bank will want to know you.

Sorry for the rambling, I meant to focus on Javascript, but branched off into general programmer stuff pretty quickly.

Agile workflow and how it's (not?) used

I've been thinking about the Agile workflow recently, mainly due to pains employers I've worked for have had with implementation and delivery.  I've seen a number of places that miss the very first tenet of Agile:

Individuals and interactions over processes and tools

So many places I've worked for place far more stress on the processes and tools, i.e. how do we measure what Agile is doing for us, from Kanban boards to scrum sprints, the focus seems to be on measuring velocity, not on improving velocity.
More places seem to understand point 3

Customer collaboration over contract negotiation

I have worked for very few places that try to turn the thumb screws on over the letter of a contract, and most clients seem to understand that things evolve as they are developed and don't have a problem with updated payments.
Weirdly however lots of places still don't get point 4, even though they do get point 3:

Responding to change over following a plan 

Once a plan is in place, they will try to stick to it until the end beyond all reason.  I'm very curious as to the cause of this, or if it's just me seeing this.

Why you should put package-lock.json in source control

Simple, eliminate the "works on my machine" response from developers:

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

This will keep all the installed dependencies the same when you do npm i. If you don't, any packages you have in package.json will get their dependency tree based on what the package you're using specifies, i.e. it could be latest compatible (@^x.x.x) or anything.  And without a package-lock.json you're at the mercy of what your dependencies specify.

Angular, Angular, more Angular, and Redux

I've been working with AngularJS and Angular 6 for 2 years and almost 1 year now respectively, and I do enjoy them both.  I'm also loving Redux, but wish I had known about it when I first started with the AngularJS project, it would have saved me a lot of headache with client side state.  I'm converting the project over, but it's slow going with the amount of work.  I'm also very glad for the Pluralsight courses on them (shameless self plug), the Angular NgRx: Getting Started course by Deborah Kurata and Duncan Hunter is very good for, well, getting started.  I already knew a bit about redux and working with it, but the effects chapter was very useful, and the Architectural Considerations chapter on container presentational pattern I liked a lot.  I'm watching a course on unit testing, but I'm still having difficulty with figuring out what to test on a UI layer.  I'm used to writing tests for things that have logic in them, and I try to keep the logic out of the UI layer.  I can where testing services and probably the container components would be useful, but I don't know about testing a presentational component, it would seem to make for brittle tests, hopefully the videos will be informative in that area.

Alexa...

So I got an echo dot for Christmas, and I must say I'm liking it.  It looks like home automation is finally getting to the point where it may be worth it.  I'm liking the concepts of the Z-Wave and IFTTT, but products that support those protocols are still a good bit pricier than the straight wifi ones.  I got a "smart" plug to go with the dot, and it's definitely useful.  I'm going to get a couple more and a wall switch and wire up the office and see how that goes, then consider doing more with it. 

--- Update ---
Ok, I'm revising my opinion of the "smart" plug.  My internet connection is not always connected, and this particular plug (Amazon branded, not sure who actually makes it) turns itself off after a period of being disconnected from the internet.  This causes issues when your monitors are plugged into it (for ease of turning off at night).  I'm hoping they don't all suffer from this kind of issue.  I've stalled on the automation at the moment, I've got 3 echo dots (which are obscenely cheap), but only my office, front porch lights and one lamp hooked up with philips bulbs (they came with the dots).  The bulbs would be useful for things like lamps I think (better than smart plugs), but I'd rather go with smart wall switches, and I'm waiting for the Wink hub 2 to come back in stock.  Alexa is still great (I love whisper mode!), and works well with the limited items I currently have, so I'm looking forward to hooking up more lights, I just wish roku worked with it.