JavaScript vs Bash (Bourne-Again SHell)

JavaScript looks for every possible way to treat the code you write as runnable and is very reluctant to point out likely errors. For example, you have call a function with too many arguments, the extra arguments are simply discarded.

If you forget a var or new, you can clobber the global scope. For tiny scripts (JavaScript's original use case) globals are great, but for larger applications globals are generally regarded as a Bad Thing. This is because changes to one small part of a program can randomly break things anywhere else. These kinds of bugs are notoriously hard to find.

Since JavaScript is a weakly typed language, you don't have to learn about data types if you start using JavaScript as your first language. Data types being one of the most important concepts in programming. This will also cause trouble in the long run when you will have to (inevitably) learn and work with a strongly or statically typed language because you will be forced to learn the type system from scratch.

'5' - 1 == 4, but '5' + 1 == 51. There are other examples that make even less sense.

JavaScript has a long litany of warts and gotchas. JavaScript will bite you if you're just a wee bit careless. You have to exercise a great deal of caution and awareness. You either have to know the entire 545-page ES6 spec to avoid them all, or use a linter to help restrict you from using the bad parts (and you still have to be familiar with the language), but beginners don't know these things. (Linters are also prone to time-wasting false positives.) This is a significant cognitive burden on even the experienced programmer (as if coding wasn’t hard enough already), but try learning to program in the first place on top of all of this and you'll understand that JavaScript is a terrible choice for the beginner.

It wouldn't consolidate a good mind structure for moving to other languages. Too open.

Beginner programmers often make the mistake of coding something, seeing it works in the browser they tested it in, and then scratching their heads when it doesn't work in another browser. Ideally you'd want a language that works consistently across all platforms in order to be able to focus more on the programming and less on the underlying environment. It just takes time away from learning and forces you to spend time figuring out why this worked in browser X but not browser Y.

Trying to keep up=javascript fatigue. You won't have time to learn anything else if this is your first language, and you will probably think all programmers are crazy. Plus web assembly may open the door for better alternatives.

this is bound to whatever object called the function. Unless you invoke it as a method. Unless you invoke it as a constructor. Unless it's an arrow function.

Much often needed functionality is not in the standard library. (Contrast with Python.) However, there are well established libraries such as Lodash, to fill the gap (however, due to the diverse/fractured ecosystem it may not be clear what library to use).

JavaScript can work synchronously but its current use is mainly around asynchronous instructions, and it's surely not a good way to start learning programming.

Therefore, attempts to call methods on them will fail. This is especially frustrating since these are often returned instead of throwing exceptions. So a failure may appear far away from the actual cause, which makes bugs very hard to find.

Many cases when you should get an Array, you just get an Array-like object instead and none of the Array methods work on it.

The language and the web platform move fast these days. this makes it difficult for students as there is a lot of fragmentation and outdated information.

This is very surprising for beginners. Especially since 00 through 07 seem to work just fine. And this isn't just for hardcoded numbers. The parseInt() function has the same problem, but only on some systems.

You really want to be using a good editor (light IDE) and a linter, type checker (e.g.:Flow), etc. until you grok the language. And choosing / setting-up that development environment is it's own learning curve. If taught in a classroom, using a subset of JS with solid tools, there is an argument that JS could be an ideal first language... however, that is a lot of ceremony to protect the new programmer from JS gotchas. But without the tools, JS can be a very painful painful first language (trying to figure out why your code isn't doing what you intended).

JS is one of the most dreaded languages as it was designed for the purpose of becoming just an scripting language for a browser. It was never intended to take over as the leading technology in web development, thus the language has been streched past its own capabilities. A beginer should learn something else first, something that is better conceived and refined.

JavaScript is rather inconsistent when dealing with different types. For example, when working with the + operator and two numbers, they will be added, two strings will be concatenated:

3+5; // 8;
"Hello "+"world"; // "Hello world"

When using + with a string and a non-string operand, the non-string operand is converted to a string and the result is concatenated:

"the answer is "+42; // "the answer is 42"
"this is "+true; // "this is true"

In any other case (except for Date) the operands are converted to numbers and the results are added:

1+true; // = 1+1 = 2; 
null+false; // = 0+0 = 0;

Angular, React, Ember, Meteor, Backbone, Knockout, Express, Mithril, Aurelia. The web frameworks pass in and out of fashion too quickly to keep up with. The endless civil wars are becoming tiresome.

But beginners won't know better. And even after you learn, you might have to deal with others' code that uses the bad stuff. JavaScript was originally developed in 10 days. It just wasn't designed that carefully.

In Bash, exceptions are the rule, not even all being described by the main page.

There are a grand total of 5 different ways of quoting, sometimes even when one does not want to, for instance in command substitutions. These are all based around preserving the literal meaning of every character, with an exception list. There is even an exception list to the exception list in 4 of the 5, regarding how the backslash behaves! The behavior of the backslash is also one of the quoting rules, so naturally, it also has an exception in how it works when it stands before a newline as compared to other characters.

Bash has several layers of interpretations, all to be kept in mind:

The ~ expands to the home of the current user. So if you store it in a variable, can you use it that way? Nope: tilde expansion comes before variable expansion.

Aha, so that's how it works! Then, since applying quotation happens after redirections are set up, it must mean that redirecting within quotes works, right? Nope: there is an exception! If a redirection symbol is not quoted, quotation around the symbol is observed, but is not removed. So, since variable expansion also comes after setting up redirections, and no exceptions are described here in the man page, getting the name of a file from a variable and using it as a target should not work, right? No: redirection does not actually take place when the symbols are being read, the symbols are merely removed and are noted for later, right before when the actual command runs.

Apart from 5 types of quotation, there are basically 2 quoting phases, 2 word splitting phases (with only one being controllable), and a tokenization phase on top of that.

If you have a command, it could be an alias, a special built in, a non-special built in, a symbolic link to a file, a regular file, a function, with different rules regarding how they can be overridden, if redirection happens before or after arguments have been passed (what does "time my_command 2>&1 >log_file" do?), etc.

This list is admittedly long, but it doesn't even scratch the surface of the bloat, complexity and inconsistencies of Bash.

Apple, one of the largest distributors of UNIX systems, only ships an ancient version of bash that predates the iPhone.

No one knows why as Apple hasn't said, but the version Apple includes in MacOS is from right before the license was updated to version 3 of the GNU GPL (General Public License). Other major companies (IBM, Microsoft) have had no problem shipping the latest version of bash, so it's unclear what Apple's lawyers are averse to. The GPL has always said that if you distributed a program, you granted everyone the right to use it freely. The biggest change in version 3 was the addition, "...and that includes software patents."

This was necessary because back in 2006 Microsoft was demanding that any company that uses Linux pay them or get sued for infringing on their patents. They even took some companies, like TomTom, to court. No software which can be restricted retroactively like that is truly free, so GPL 3+ includes a clause saying that if you distribute the program, then you are also granting license to any patents you own that are necessary to run it.

What patents Apple has that bash could possibly infringe on is a mystery, but the bigger question is, Why does Apple even care? So what if they are granting people the right to run bash without being sued by Apple. It's not like they were planning on doing that, right?

Even though it is not bash's fault that it is not Apple Lawyer-approved, this is a CON for it because a lot of people use Apple products. While there are methods like brew to install a current version of bash, Apple does not make it obvious to their customers what they are missing.

One of bash's claims to fame is compatibility with previous versions of itself and historic shells. But, doing that means that new features are often written in tortured, awkward syntax that is not easy to learn. For example, bash uses the POSIX way of doing arithmetic: to add 5+3 you must put the numbers in double parentheses with a dollar sign at the start: x=$((5+3)). It is true that many shells suffer from this same CON, but since bash is such an important shell, it has less wiggleroom to ditch clunky ideas that might break existing scripts.

People who wants power features or to customize their shell experience use zsh or fish.

filename expansion is not consistent. "echo *" will print the names of the files in your current dir, if there are any... and will print "*" if there are none.

If there are no .sh files, this will print mask itself:

for filename in *.sh; do
    echo $filename
done

To have command autocompletion in bash you need to install third-party plug-ins.

What it is mostly used for are file system operations. Guess what it is bad at? Operating on files. It automatically splits and carries out filename expansion on every single string resulting from variable expansion and command substitution unless quoted, by default on whitespace, whilst spaces are very common in filenames.

Before that, it even does pathname expansion, so woe to anywone who does not want to actually operate on files, but has a globbing metacharacter stored anywhere in a variable.

This means what you store in a variable is not going to be what will ACTUALLY be accessed.

If an empty variable is unquoted, it disappears completely due to word splitting, sometimes leading to applications signalling a missing parameter at a wrong position.

If quoted however, said variables cannot be iterated over in a loop, no matter what character one uses for word splitting.

If you use any globbing pattern with a command, be sure to use -- after the option arguments or if none are present, before starting the pattern with a mandatory ./

Otherwise, another Bash script run gone wrong or a hacker can create files named like an option ("-f", for instance) and your program will happily accept it as such, if it results from globbing.

For interactive use, it is convenient. For programming, it is a no-go.