Hacker News Reader

Comment by Ezku | Hacker News Reader

From the comments here, I was expecting to find myself hopelessly out of date, and to end up with a migraine trying to parse through a mindnumbing list of changes. Turned out I was mistaken.

  > Me: oh, cool, they fixed so many tiny things I had bumped up against
  > Some others: oh no, why are things changing

I'm not getting it. Maybe I'm reading this wrong, but to me these seem pretty obvious small issues to smooth over.

View on HN

The way JS/TS change _feels_ a lot more haphazard.

For example why introduce a new method to support negative indexing. Supporting `array[-1]` instead of `array.at(-1)` would mean one less thing to remember.

Many of the changes make the language feel like a hodge podge made from parts of other languages. This lack of cohesion is IMO what makes upgrading the language always feel like moved cheese.

Because your example is a breaking change, and breaking changes are hard to make in a runtime that needs to reasonably support two decades worth of web content.

For example, if you have a `binarySearch` function that returns -1 if an element isn't found, a developer might do something. `const result = arr[index]; if (result !== undefined) { ... }`. This would then start returning the last element instead of undefined at that index.

We already have things like "use strict", because of backwards compatibility. Following the same idea, we could have something like "use ES2023" or something along those lines. Issue with JavaScript is that browsers have in-flux implementations of new features (as browser parent companies see it fit for their usage), and there's no cohesive point in time release process. I think "living" standards, are part of the reason why the web stack is so jumbled.

But what do I care, whatever mess and complexity arises from these "good enough" implementations is left for the generation after us to deal with :)

In some sense, the messiness of the living standard is also what enables large-scale web archival.

A lot of old code in other languages may be hard or impossible to compile and run without significant work.

Exactly right. `arr[-1]` means `arr["-1"]` and already does something.

It is also a breaking change to use new syntax and functions since old browser does not support new features. In this perspective `arr[-1]` seems a fair breaking change.

No, because changing browsers to interpret `arr[-1]` as `arr[arr.length - 1]` breaks existing sites that expect `arr[-1]` to be interpreted as `arr['-1']`: That is, the value stored on object `arr` at key name '-1'.

Changing browsers to interpret `arr.get(-1)` as `arr[arr.length - 1]` doesn't affect any old code using `arr[-1]`.

It's not about supporting old browsers. It's about supporting old code.

I think you're confusing your application with the language itself.

Adding new syntax and functions to the language is not a breaking change. Old code will continue to work.

If you start using these new features in your application, and it no longer works on old browsers, then sure that's a breaking change. But that's a choice for you to make. The language is still backwards compatible.

`indexes[haystack.indexOf(needle)] = true`

There's a valid example of code that would be broken (`indexOf` returns `-1` as "not found"). Is it a good way of solving whatever the author was trying to do? Probably not, especially now that sets exist. Is it code you might conceivably find on hunreds of sites across the past decades of the world wide web? You bet.

Yes, we could introduce another "use strict". But we only just got rid of the one via ESM (which enforces strict mode). That was a one-off hacky solution to a hard problem coming off the end of a failed major version release of the language (look up ECMAScript 4 if you get a chance). We don't want to see a repeat of that.

Why is there still no simple way of handling changes like this?

Surely there should be a simple way to have a header in each file with the language version, and then the file will be interpreted as that version?

All of this was hashed out during the "Harmony"[1] days. Versioned-JS was of course one possible future. Maybe even still is. But the prevailing decision coming out around that time and leading to ES5 and ES2015: We'll add "use strict" as a single-point-in-time breaking opt-in upgrade to fix a lot of the common problems, but let's otherwise stick to "One JavaScript"[2].

You may find [2] and [3] especially enlightening to understanding this thinking, and any other discussions from ES Discuss on the topic if you fell like digging into history.

[1] https://johnresig.com/blog/ecmascript-harmony/

[2] https://2ality.com/2014/12/one-javascript.html

[3] https://esdiscuss.org/topic/es6-doesn-t-need-opt-in

Well, "use stricter" and "use strictest" are still available...

!important

Maybe this is simple in implementation, but it's definitely not simple in developer experience.

You grab some code in one of your old projects for implementing a binary search. Can you copy-paste it into a new project that targets a newer language version?

The question isn't as simple as "does it have syntax errors", because we're talking about changing semantics here. Given a set of semantic changes and a piece of code, figuring out (either as a human or a computer) whether the observable characteristics of that code have changed is somewhere between vexing and impossible. It's entirely possible, for example, that your code encounters changed semantics, but not in a way that changes the actual behavior of the code.

In this world it just becomes very, very difficult to reason about extremely common operations; it'd be a constant source of frustration. There's a good reason you rarely see languages versioning their behavior in impactful ways.

> Why is there still no simple way of handling changes like this?

This is nothing JS specific. Breaking changes are breaking changes. If you can, don't introduce them.

> simple way to have a header in each file with the language version

One special aspect that differentiates JS from other languages:

It's both a language AND a universal runtime. A lot of JS that's executed is not JS that's written by humans but generated by a compiler/transpiler.

So adding a layer of header versioning is not a big win in terms of developer experience: It would anyways be the deployment toolchain that's responsible to deal with such a versioning scheme. It would ideally be invisible to the developer.

To be pedantic adding an at function is a breaking change too.

Not really.

You can add a polyfill to check if `Array.at()` exists, and if it doesn't, create a function that does the same thing and add it to the `Array` object, so now all `Array.at()` code works as expected.

Then once every environment you target supports `Array.at()` by default, you can remove the polyfill to reduce the size of your code.

    if (array.at) {
      explode();
    }

Adding the at function would break the above code which depends on array.at being undefined.

They test a lot of websites before introducing new methods. Something somewhere may break but it's very unlikely and this pragmatic approach allows progress.

This is also why the language got Array.prorotype.flat instead of flatten (flatten was breaking an old version of a popular library called Mootools): https://developer.chrome.com/blog/smooshgate/

And extending javascript's built-in objects has been considered bad practice since at least 2007.

Before that point, browser environments were so different that you needed to write code per-browser. Those theoretical concerns didn't really matter since in-practice you were essentially coding the same app in different scripting languages.

> extending javascript's built-in objects has been considered bad practice since at least 2007

Totally. It's just extending the prototype that causes the problem though, not extending from (class myclass extends array). This causes a lot of confusion among new js devs so I underline this on every opportunity.

When I look at clever TypeScript, I always think the code was written by either Haskell or C++ template metaprogramming refugee, and this isn't good for the longevity of the language, see what happened to Scala's adoption because of it.

Typescript will have no adoption problem. It is the defacto only compile to js language supported in NPM. It is also ergonomic to JS devs who want or are forced (at work) to use typing and an option on most scaffolding tools like NextJS or CRA. The fact that TS is actually very good just confounds this more!

It will live as long ad JS is popular. The main threat is web assembly which will make JS compatibility seem quaint.

Something should be pointed out to outsiders looking at typescript, otherwise they might get the wrong idea about the language.

In practice there seems to two different sides of typescript code.

1. Regular projects: tend to have rather easy to understand/write/maintain code.

2. Dependency code: tends to have code-golfed metaprogramming that the IDE uses to auto-magically autocomplete and highlight issues in regular project code.

While I'm an C++ refugee, most of the "clever" TS stuff I write is due to JS framework idioms creating duplicate work(redux-reducer typings...) or forcing 'any' escape doors to the degree TS use doesn't help. Doesn't mean I'm "above" using any escape hatches where appropriate though or keeping things "dumb" (most of my TS code is fairly monomorphic).

After coding it with it daily for the past year I can think of very few times I've had to write "clever" TypeScript. And half of those are now solved with TypeScript's new `satisfies` operator :P

The only consistently annoying thing about it is how dumb it plays with JavaScript's built in array methods but it still is sufficiently smart 80% of the time (and the other 15% a simple `as const` does the trick)

Yeah, this is why I wince every time TS gets another feature.

IMO it was entirely good enough for what it does quite a while ago. No need to add more—that's purely introducing risk (of the language's ecosystem getting worse, mainly) from my perspective.

On the contrary, many of the new TS features over the last year or more have been around making type inference smarter and allowing for less explicit typing

Yep! Or making type checking safer (this list is enormous), or better aligning TS specifics with how JS is actually used (upcoming 5.0 getting import specifiers more or less right as a great example).

Developers love hating on JavaScript, on change, and on "complexification." This is all of the above.

The first comment I read after yours is literally "I hate how much programming languages change"

Agreed. My main complaint is that some of these changes don’t filter down fast enough for my liking, because I’ve bumped into the issues they fix, often enough.

That, and for various reasons, it’s easy to use "import" everywhere in browser-side code, but painful to use "import" in Node. That’s a major selling point for ESBuild in my mind—I can avoid dealing with Node as much.

Yeah, the language changes seem pretty minor and incremental. I think the more interesting changes in the last few years have been with engines. All major browsers now support ESM modules and custom elements.

The big hurdle is a lot of new jargon that sounds more complicated than what it's doing.

Reply on news.ycombinator.com