We go on adding fancy new syntax for little or no gain. The whole arrow function notation, for example, buys nothing new compared to the old notation of writing "function(....){}" other than appearing to keep up with functional fashion of the times.

Similarly, python which was resistant to the idea of 20 ways to do the same thing, also seems to be going in the direction of crazy things like the "walrus" operator which seems to be increasing the cognitive load by being a little more terse while not solving any fundamental issues.

Nothing wrong with functional paradigm, but extra syntax should only be added when it brings something substantial valuable to the table.

Also, features should be removed just as aggressively as they are added, otherwise you end up with C++ where you need less of a programmer to be able to tell what a given expression will do and more of a compiler grammar lawyer who can unmangle the legalese.

Function.toString being more accurate is helpful.

But real progress would be removing dangerous backtracking regular expressions in favor of RE2: https://github.com/google/re2/wiki/Syntax

That's hard to believe unless you're working on the most amateur of teams.

There's a point where you have to expect people to understand the most basic concepts of the language/tools they're hired to use. This shouldn't require more than a simple 5min pull-aside of the junior developer.

Also, you can't change function(){}'s dynamic scope without breaking the web, which is a major downside for your suggested upside of developers not having to learn the distinction. function(){} was always confusing from day one. ()=>{} is a move back toward intuitiveness.

Pretty sure that tells you if a number is odd. I guess maybe there is a reason these libraries exist.

    All major engines have also implemented corresponding trimLeft and trimRight functions - without any standard specification. 

If you have alternative recommendation that's not these tools, I'd be curious to hear it.

Even if you support IE, you can still reap the benefits of modern JS if you're willing to do some differential serving. You can use the module/nomodule pattern to serve ES2017 without making changes to the server.

How about simply compiling IE5 into WebAssembly, wouldn't that solve the problem? ;)

Personally, I only lodash for the debounce functionality.

I know this because I have wanted to use fn.toString() as part of some meta-programming many years ago (but couldn't because comments were not stored).

I am sure a lot of effort went in to making a good decision, aiming for a good outcome, but this smells like a bad one.

At this point I'm mostly fine with the feature set of C99 so I can live without the newer standards. Actually there's stuff in newer standards that I find questionable, but that's a different discussion.

C99 on the other hand was sorely needed, if only for standardizing some basic features that up until then were only available as vendor-specific extensions. Things like inline, stdint.h, bools, variadic macros, restrict, compound literals and more[1].

Writing code without these features is often severely limiting. Or rather, you probably won't be limited but you'll have to rely on vendor extensions and write non-portable code. Or maybe you'll use a thousand-line long configure script to make the code portable.

>Also, a new feature I want to use needs only be supported by one C compiler: the one I'm using. With JS, I need all of them to support it.

If you're making proprietary software that makes sense, if you're developing open source code you very much care about portability and compatibility. I care about the compiler I use, the compiler OpenSuse uses, whatever garbage Visual Studio uses, the compiler FreeBSD uses etc...

Besides I have basic code snippets I wrote over a decade ago that I still use today, regardless of the environment. That's valuable too.

[1] https://en.wikipedia.org/wiki/C99

I've always had the impression that C programmers also care about standards compliance, and aren't typically willing to marry their project to a particular compiler.

At least, it's the language community where you see "language lawyers". I'm sure there are "language lawyers" in other language communities, but I've never seen discussions about what causes "undefined behavior" or what's "implementation dependent" or discuss interpretations of particular passages of the standard like I do with the C and C++ communities.

Using modern JS features does not require universal support.

    > Object.freeze([1,2,3]).push(4)
    TypeError: can't define array index property past the end of an array with non-writable length (firefox)
    Uncaught TypeError: Cannot add property 3, object is not extensible (chrome)

I often find myself writing classes where the last step of a constructor is to Object.freeze (or at least Object.seal) itself.

That's pure BS. This is only true for atomics, the value can change (under let, var and const) as we can easily see with Array.push, for example.

  stream.map(f).collect(...)

The only real downside is the lack of return values mean you can't chain mutations, but personally that never bothered me.

Yes, although the new object is not frozen by default. Adding is quite straight forward, expecially with the spread syntax

    let x = { a: 1, b: 2 };
    Object.freeze(x)
    let y = {...x, b: 3}
    // y == { a: 1, b: 3 }

    let x = { a: 1, b: 2 };
    Object.freeze(x)
    let { b, ...y} = x;
    // y == { a: 1 }

Yes, but given that JS is a dynamic language I wouldn't expect anything different (everything must inspected at runtime).

> And freeze isn't recursive against the entire object graph

You're right, although one could quickly implement a recursive version.

In any case I find Object.freeze not much useful since trying to mutate a frozen object will simply ignore the operation; I think that most of the time trying to do that should be considered an error and I would prefer to have and exception raised.

    const foo = Object.freeze({ a: 1, b: 2 })
    const fooCopy = { ...foo }

But like it or not JS isn't a language with a powerful type system, and it doesn't pretend to have one so knocking it for that is like knocking Python for using whitespace, or knocking Rust for needing a compiler.

Luckily, Typescript and Flow have most of what you are asking for, and they work pretty damn well across the entire ecosystem.

Off the top of my head, I know typescript has the ability to mark things as read-only even at the individual property level. [1] And they have tons of the type checking nice-ness that you can expect from other "well typed" languages like Rust.

[1] https://basarat.gitbooks.io/typescript/docs/types/readonly.h...

In my experience most "immutability" in JS is enforced by convention or, at best, static type systems. It's not ideal, but it works.

Rust allows this, and it really clears codes up. I don’t have to make up different identifiers for same data but different representations. (e.g. I would do the above code in JS as... someKindOfDataAsArray = [...someKindOfObectAsNodeList])

    function flatten(x, n=1) {
        return n > 0 ? x.flatmap(y => flatten(y, n-1))
                     : x;
    }

Assignment was specifically made a statement to avoid the confusion / typo risks of `=` v `==`.

Can you elaborate?

How do you match against a `Buffer` pattern/type?

With the exception of Safari, all major browsers support auto-updating, and anybody who intentionally uses an outdated version of Safari is a masochist with a deviant fetish for error messages.

At some point this is a business decision like anything else and the security considerations in particular have helped get people onto evergreen browsers faster than used to seem possible.

I don't know - it's never confusing to me. I just use the IDE that allows me to view the types of the variables whenever I need to see them.

IDE also highlights the definitions and then the usages of the variable, including the syntax scope where it's used.

You're definitely using the wrong tools for the job if you get confused with that little detail.

>> Given that JS doesn't restrict the type of a declaration you can just assign a new value to it, place it in a small scope or use a chain.

Yeah, but I don't want to semantically assign a new value to the variable. I want this to be a new variable, because it is a new variable.

So the point of var is slightly over exaggerated because they could have gone the python way and simply allow declarations to be anything that is an assignment.

That's already an error in strict mode (which would presumably be on for anyone writing bleeding-edge JS).

    let arr = [{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}];
    let b = "!"

    for(let e of arr) e = b;
    console.log(arr)

    for(let e of arr) e.a = 2;
    console.log(arr)

    for(let e of arr) {let copy = {...e}; copy.a = 4;}
    console.log(arr)
    

    for(let e of arr) {let copy = {...e}; copy.b[0] = "!";}
    console.log(arr)
    

The most frustrating thing about all of this is that the best way to make a deep copy to avoid all unwanted modification is JSON.parse(JSON.stringify(arr))

The arr.map providing you had a variable on the left side would output the result of each iteration into said array ( so an array containing all b values - however I guess you meant arr.map(e => e)

Think of the closure as an object. It contains variables like `this`, `arguments`, a pointer to the parent closure, all your variables, etc.

The interpreter needs to create this closure object BEFORE it runs the function. Before the function can run, it has to be parsed. It looks for any parameters, `var` statements, and function statements. These are all added to the list of properties in the object with a value of `undefined`. If you have `var foo` twice, it only creates one property with that name.

Now when it runs, it just ignores any `var` statements and instead, it looks up the value in the object. If it's not there, then it looks in the parent closure and throws an error if it reaches the top closure and doesn't find a property with that name. Since all the variables were assigned `undefined` beforehand, a lookup always returns the correct value.

`let` wrecks this simple strategy. When you're creating the closure, you have to specify if a variable belongs in the `var` group or in the `let` group. If it is in the `let` group, it isn't given a default value of `undefined`. Because of the TDZ (temporal dead zone), it is instead give a pseudo "really undefined" placeholder value.

When your function runs and comes across a variable in the let group, it must do a couple checks.

Case 1: we have a `let` statement. Re-assign all the given variables to their assigned value or to `undefined` if no value is given.

Case 2: we have an assignment statement. Check if we are "really undefined" or if we have an actual value. If "really undefined", then we must throw an error that we used before assignment. Otherwise, assign the variable the given value;

Case 3: We are accessing a variable. Check if we are "really undefined" and throw if we are. Otherwise, return the value.

To my knowledge, there's no technical reason for implementing the rule of only one declaration aside from forcing some idea of purity. The biggest general downside of `let` IMO is that you must do extra checks and branches every time you access a variable else have the JIT generate another code path (both of which are less efficient).

NSFW link:

https://www.cbsnews.com/news/ayn-rand-vs-the-invisible-hand-...

Not quite. You should also use the spread operator when you are spreading an iterable into an array:

    const unique = [...new Set(arr)];

On Windows VCRUNTIME installs are mostly painless, easily backgrounded, and people don't realize they sometimes have as many as 100s of different versions installed side-by-side because every game installed wants a slightly different version.

But on Linux, it's often as much as like three-fourths of the reason that code needs to be rebuilt so often for every possible different Linux distribution because most distributions lock to only a single libc and prefer every app dynamically link that specific libc. Apps get held back by distributions slow to adopt libc updates all the time in Linux, and app devs try to stick to common libc versions based on distribution popularity (user preference), which isn't dissimilar to the lagging browser problem.

(Then there are arguments about statically bundling libc / VCRUNTIME, etc.)

It's not as bad as JS land on average, but that doesn't mean that C is immune to the same problem. As soon as you are dealing with shared libraries / platforms / runtimes, you run into having to deal with what users are willing to install (and practically no platform is immune, depending on trade-offs one is willing to take).

Once a transpile step is required, it doesn't make as much of a difference what is on the other side.

FYI, this doesn't happen in C, all C versions are backwards compatible - you can compile C89 code on any compiler supporting C99, C11 or C18.

And by the way - if you paid attention in the first place my post actually has exactly what you've just written.

We have legacy JavaScript dependencies and most of them worry me. I don't stay up at night worrying about the domain and range of TypeScript ones even if their testing is weak. There's a reason for that.cs TypeScript is loose where it should be loose and yet strongly encourages flexible but very clear typing that provides significant resistance to broken contracts and misunderstood semantics. I won't hire a web or Node developer who has a problem with it today because understanding the value of gradual and structural typing is, I strongly think, evidence of baseline competence.

"I write worse code, slower" is defensiveness masked as "a taste thing." We've improved the state of the art and it's better here.

The typing there might add a few extra characters to your function definitions but you gain them back in terms of less need for documenting the argument types in comments. You hardly ever see typing inside of functions in Typescript so it hardly adds any verbosity.

For anything remotely important, you're almost certainly going to already want a build pipeline to do things like concatenating/minifying code, running tests, and deploying. Adding a transpilation step to extend support to older browsers comes with almost no cost to time or maintainability, assuming you're using well-supported things like Babel and its official plugins.

While less of a consideration for established teams, it dramatically raises the barrier to entry for those who are learning as well as those who currently have much simpler requirements. Those are the future members of that established team. Adding hurdles to the process of learning will, in the long run, result in a smaller, more homogeneous pool of experienced developers to draw upon. It's a self-perpetuating cycle - making folks learn by using complex build scripts will result in experienced developers who then create further complexity because they've self-selected to be those who happen to think in that mode.

That's not intended to suggest that progress is bad. Rather that it's a bit short-sighted of us, as an industry, not to consider the ramifications of enforcing a workflow that happens to be trivial from the limited perspective of long time front end developers.

{ Edit to try to make the last paragraph sound less accusatory. Sorry! That wasn't my intention. }

https://gitlab.com/WA9ACE/frontend-starter

I ended up adding Parcel for easy Typescript support.

> Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither

Whoa! That's a lot of words to basically say "JavaScript does not have static or inferential/derivable types". Kind of like the way type annotations create all that syntax noise. And I was talking about achieving the BENEFITS of "gradual and structural typing". It is done for the the benefits, not for its own sake. Do you even know the benefits? In proper JS, the same is easily achieved by duck-typing, and run-time checking whenever necessary.

> And given that TypeScript is a strict superset of JavaScript, it's absolutely bonkers to claim that JavaScript is "more powerful and expressive"

I touched on the a bit when talking on trade-offs. A superset does not mean super like superman. it means an added layer of abstraction. You are moving further away from the metal, and leaving some decisions to the TypeScript compiler. That means giving away power, and flexibility to the compiler. A good engineer understands, and is not in denial about the trade-offs they are making.

> But as a gentle observation: people don't usually go on about "tribal" developers when the facts are on their side.

What really happens is that people outgrow their tribal instincts once they realize that this are all just tools that come and go, it is the underlying ideas that matter. JS absorbed all the best ideas from jQuery, and jQuery went. It has integrated all the best ideas from CoffeScript (js with a python frame of mind), and coffee-script is no longer the rage it was a few years back. Same is happening with TS, which is why my money is still on JS. The fact is, js will outlive ts.

I'm afraid I don't know what you have in mind as far as syntactic sugar that makes things harder for learners. Every new syntax I can think of makes JS easier to learn and use.

I'm not saying it's some sort of lost knowledge like Damascus steel, I'm just saying that many people these days are so caught up into the current dogma of JS that they never consider a simpler but still modern path.

The user doesn't manually compile anything, but their choice (sometimes lack of choice) of browser determines which version of the spec they can run. So you end up polyfilling forever because some significant chunk of your user base is tied to IE8 or worse.

All the original commenter meant is that the people making the software can't ever guarantee what version of JS the end user's browser can handle.

I'm not saying that to excuse thrash. Thrash is bad. But like..."oh, at some point you'll have to have somebody who actually understands how the thing we use to make money works"--you should have that person anyway! It's an existential threat to your business not to.

Understanding things is our job. Unless you're somewhere where understanding things isn't valued, and 1) it's gonna eventually fail, and 2) you have better places to be.