JavaScript and TypeScript features of the last 3 years | Hacker News Reader

JavaScript and TypeScript features of the last 3 years

medium.com

464 pointsKillusions265 comments

I love this thread, it has two of my favorite HN topics: 1) People shitting on JavaScript not realizing that their "obviously better" solution was considered and found not a good solution. 2) People shitting on TypeScript not realizing that conditional types and template literal types are awesome. I really like those type-safe routers (https://tanstack.com/router/v1/docs/guide/type-safety) and fully-typed database clients (https://www.edgedb.com/docs/clients/js/index#the-query-build...).

Typescript is one of those things that makes me so productive that I have absolutely nothing to argue or prove. Their loss.

Not a rebuttal, just curious, how do you find your productivity compares to a "real" statically typed language (e.g. Go, Java, etc.)? Does your increase in productivity compared to JavaScript simply come from static typing, or is TypeScript itself the source?

It's a bit of both for me. I'd say 90% of it is from simply having types; 10% is from some of the cool things you can do with TS types that aren't common in most statically typed languages.

> cool things you can do with TS types that aren't common in most statically typed languages

like what?

Some folks have built whole SQL databases and DSL compilers in the TS type system. These tend to be toy projects with disclaimers not to use them. But the type system being Turing complete[0] (for better or worse), pretty much whatever you can imagine. This project[1] is one I actually return to frequently for practical ideas.

0: https://github.com/microsoft/TypeScript/issues/14833

1: https://github.com/sindresorhus/type-fest

For me (coming from C++) being able to easily union and intersect types, and being able to specify certain values (not sure the right name for this). For example:

    type ServerResponse = {success:true, response:JSON} | {success:false, error:string};

In C++ I would probably have to type success:boolean, and make response and error optionals, but the TS type is more expressive.

if success==true, then response must exist. if success==false, then error must exist.

    const sr: ServerResponse = {success:true, error:"moo"); // won't compile, doesn't match

TS understands this type really well, and type narrowing makes it easy to work with.

    // NOT LEGAL; error might not exist
    console.log(sr.error);

    // IS LEGAL; we test for success first, which narrows the type. 
    if(sr.success){
        console.log(sr.response);
    } else {
        console.log(sr.error);
    }

I'm a big fan of TS, but discriminated unions are available in a lot of languages and when not, there's usually some library adding it like boost::variant if the language has runtime types or templating/macros.

C++ has std::variant these days, no need for Boost… however, neither version has particularly good ergonomics.

> boost

No, thanks.

If I understand std::variant, it THROWS if you try to access the wrong type?

I should have been specific, but all of the errors I mention above are compile-time errors, not run-time.

Too late to EDIT: but "literal types" was the word I am looking for.

I used "success:true" and "success:false" as part of the two types I was combining; it seems like "success:boolean" would server the same function, but it does not. The type I created has more information that that.

https://www.typescriptlang.org/docs/handbook/literal-types.h...

- easy referencing the type of another struct's field. As in `function parseInput(input: SomeType['someField']) { }`

- it's ability to infer types in general

- parsing. given a route string like `/users/:userId` TypeScript can force you to always pass `{ userId: 1234 }` when actually building the route without having to declare the interface anywhere

- conditional types

Both. Static typing makes JavaScript well more than tolerable. Dare I say enjoyable! But I also love TS' duck typing and I love how it's totally optional.

The optionality is a special trait that most "real" static languages don't get to enjoy (for better or worse). By being optional, I can simply ignore types when I'm hacking/prototyping something and type safety/soundness is the last thing I care about. Rust, for example, can feel really tedious when it makes me "show my work" and I'm just trying to scribble something up quickly. If that makes sense? I just make `any` a linting error so I can use it during my experimentation/prototyping but I cannot ship it.

I agree. I feel like sketching in JS and solidifying in TS is super productive. Being able to go from a plain old JS object to a type is really satisfying. I feel like full stack TS might be a great choice for new web projects. And if you find a bottleneck, you could rewrite in Rust.

> And if you find a bottleneck, you could rewrite in Rust.

Sounds pretty extreme..? What kind of bottlenecks would you be talking about that would prompt me to re-write my entire application in another language?

I'm pretty sure they mean rewrite the bottleneck.

no just rewrite the bottleneck/hot-path

Typescript has quite a few pitfalls like the uselessness of Readonly<T>, which can just vanish with an assignment to a variable typed T where TS will neither warn nor error out nor require an explicit cast.

Not OP but a well-typed codebase means you have to remember less, your broken code gets caught before you even run/compile it, and you can just lean on the type system to write the code for you.

And TypeScript has a much more expressive type system compared to Go, Java, and frankly most languages. Java in particular still has pretty bad type reification (where ArrayList<Integer> and ArrayList<Float> are essentially the same and cannot be used to overload methods, for example).

I use a lot of the utility TypeScript functions (i.e. Partial<>, Record<>) and it catches all sorts of mistakes that might be made by myself in the future or someone not familiar with the codebase. For example, if there has to be a A->B mapping somewhere, I would type B so it would raise a type error if something was added in A but not B. Most type systems are not flexible enough to do anything remotely like that and instead you have to write a bunch of tests where you end up 20 lines of very basic test code for 1 actual line of code.

One major downside of TypeScript is that types are not available at runtime and that computations on types can't be done by writing regular TypeScript (both possible with code generators of course).

Types are absolutely available at runtime, you just have to start from the runtime. Type guards are the solution everyone wants +- a tiny bit of ceremony, and adding type system information to the runtime would just hurt performance for no good reason.

This:

  type Foo = {
    bar: string
    // …
  }

Can just as easily be addressed as:

  const parseFoo = parse.object({
    bar: parse.string,
    // …
  })

  type Foo = Foo<typeof parseFoo>

(Where parse methods here are type guards for their respective parsed return types, and can similarly be used to serialize runtime values as needed.)

For that little bit of extra ceremony, you get to isolate runtime stuff to the boundaries you need to care about, and let the type checker deal with everything else (typically most everything internal).

Have you ever used a language where types can influence runtime behavior? It's an extremely powerful tool to do things like choosing a specialized sort algorithm based on the type of contents of array you are sorting. This has zero overhead iff types are known at compile time and can yet hit different code paths at runtime. To just dismiss this as not needed is extremely short sighted in my opinion.

Having types at runtime is a big deal and I lament that typescript can’t do it (for understandable reasons.)

I have. And I think the limitation is good for a language that doesn’t have that. I don’t want TypeScript to lie to me about its capabilities, I want it to help me make good decisions with the runtime code I actually have.

You can always use zod or io-TS.

> Types are absolutely available at runtime

TypeScript types are not available at runtime. As the name implies, runtime type information requires runtime support. Since TypeScript compiles to JavaScript, the only type information available is that provided by JavaScript.

You can use discriminated unions with TS (https://antman-does-software.com/typescripts-discriminated-u...), and you can even parse them from unknown data using tools like zod (https://zod.dev/?id=discriminated-unions), io-ts, or the likes.

I can't think of anything I can do in .NET (which has runtime types) that I can't do in TS with the help of a library or two.

> I can't do in TS with the help of a library or two.

Libraries like io-ts and zod embed the type information into JavaScript, so the information is available at runtime but only for wrapped types. If TypeScript provided runtime type information, such libraries wouldn't be necessary.

Types are absolutely available at runtime. You just have to start with the runtime.

  const parseStr = (value: unknown): assert value is string => {
    if (typeof value === 'string') return value

    throw new Error(…)
  }

  const str = parseStr(anythingYouCanThrowAtIt)

I can 100% guarantee you str is going to have the same static and runtime type once you’ve checked it, or parsed it from whatever type you’d accept as a string. TypeScript won’t do the parsing for you, because JavaScript doesn’t have clear semantics for runtime casting that anyone wants or would accept. But type guards are exactly the solution to that and incredibly composable. Once you accept that reality and embrace it, getting the static type out of your runtime parser is a single added line of static type code. And all of this is almost exactly equivalent to what languages with runtime casts do, but you have complete visibility into it because you determine how casts behave. There are whole libraries which do this for you so don’t worry about rolling your own unless you have very particular needs. But TypeScript definitely has the facility to align static and runtime types however you see fit. You just need to tell the type system what types the runtime conveys, same as every other aspect of the type system.

You seem knowledgeable about TypeScript, so you certainly very well understand what people mean by "types are not available at runtime". Once your typescript is compiled to javascript, there's nothing left of your user-defined types and interfaces. Type guards are a security that is very much a workaround for the lack of types at runtime.

I’m encouraging thinking about the problem from a different angle. If you parse rather than validate[0][1], you have roughly all of the type information you could want in the runtime, and by using type guards the type system will reflect the runtime types.

It’s not a workaround. Every language with runtime types will have some logic devoted to this kind of casting/narrowing. TypeScript rightly doesn’t build it into the compiler because most of the time you don’t want types to have runtime behavior. For internal logic which can be validated statically, runtime types would be an unnecessary overhead. So it’s up to developers to determine where it should be applied. Type guards are explicitly an affordance for that, designed specifically to convey types with runtime casting/narrowing.

If you use good, composable primitives like zod or io-ts or any of several other implementations, your code will typically be almost identical to deriving runtime from types rather than the inverse.

0: https://itnext.io/parse-dont-validate-incoming-data-in-types...

1: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

I have a bit of experience with TypeScript and I think that its types are pretty good at catching mistakes. You need to run linter (like eslint) and some strict compiler options to take a full advantage of it, but that's not a big deal. And TypeScript type system is miles ahead of Java. I'm not sure if those types provide any productivity increase compared to Java, that's questionable, but at least it's not JavaScript and that's good enough for me. Now JavaScript is truly atrocious hit to productivity. I just can't stand it.

My only issue with TypeScript is its strange design with regard to interface and types. Those are pretty fundamental concepts and they're absolutely similar. I don't understand this design and I think that only one thing should have left, but may be I'm wrong about it. Also I think that TypeScript documentation would benefit from more examples with hard concepts, I didn't fully understand its advanced generics concepts. But that's not a big thing and probably more on me.

> My only issue with TypeScript is its strange design with regard to interface and types. Those are pretty fundamental concepts and they're absolutely similar. I don't understand this design and I think that only one thing should have left, but may be I'm wrong about it.

I feel the same way. IIRC, earlier versions of Typescript were much more clearly influenced by .NET and other Microsoft idioms, and there were a few features that didn't seem to make much sense coming from the Javascript side of things. I also had a buddy of mine that's a Java developer be very confused about how they were supposed to work.

> Also I think that TypeScript documentation would benefit from more examples with hard concepts, I didn't fully understand its advanced generics concepts. But that's not a big thing and probably more on me.

Absolutely agree on this, although things are getting better. For awhile it seemed like the only documentation for more advanced features was the main website's blog posts and release notes.

Not GP, and not a direct answer to the question… in these discussions a lot of the “benefit of static types” gets boiled down to:

- documentation

- aids tooling (eg improved static references in editor, static analysis by linter, etc)

- catches a whole class of problems before runtime (eg a typecheck-time substitute for certain runtime checks and their corresponding tests)

I often like to add:

- promotes better design

This puts TypeScript’s type system in a unique position, where it’s simultaneously expressive and complex in ways many others are not (because it’s designed to express extraordinarily dynamic idioms used in JS) and equally mundane and simple if you use it from the start (because all that complexity is a good forcing function for deciding whether you all of that dynamism it can express is of value for the thing you’re actually building).

In a more general sense, it strongly encourages developers to think about their interfaces explicitly where they might otherwise “rapidly prototype” a monstrous one.

The vast majority of the time, TypeScript will encourage simpler APIs that don’t need most of TypeScript’s “advanced” type system features. And in terms of productivity, that’s a benefit you only get if you’re starting from the proverbial Dynamic Wild West. So it might not be absolutely more productive than other statically typed languages, but still relatively an enormous productivity boost in its context.

I think the biggest benefit I've found is TypeScript's inference is extremely smart and in fact it's considered a best practice to basically write as little TypeScript as possible and rely as much as possible on TS's inference

In general, if a "best practice" of a language is to write less code that tends to translate to great productivity

> Does your increase in productivity compared to JavaScript simply come from static typing, or is TypeScript itself the source?

As far as I can tell, TypeScript doesn't add any new features or behavior to JS other than static typing.

If you ask me, of course TS isn't as good as the real deal, but it's darn close and way better than vanilla JS or compilers for other languages that target JS.

Can only speak for java. But I'm way more productive with typescript. Typescript has 2 things going for it:

- type system is way more flexible. You can create, merge, pick keys and manipulate types in all kinds of ways. You have better type inference, type conditionals and lots more

-there's an escape hatch. Sometimes you just want to quickly try something, or you're under time pressure and need to either break the types or do a bigger rewrite, or you just don't care about a certain variable's type. Then there's the any/unknown/plain js/@ts-expect-error escape hatches to do just that.

I really dislike how unpredictable the typescript compiler can be. What I mean is, there isn’t a simple set of rules I can understand to know when annotations will be required. Most of the time, this doesn’t matter, but occasionally it blows up and development comes to a screeching halt. Contrast this to, say, Java and ML type-systems, which are highly predictable.

I think the opposite, TS is much more predictable than hindley-milner inference, mostly because the inference only flows forward.

Yes, there are a couple of weird edge cases with arrow functions in generics, and it gets a bit more complicated with narrowing, but aside from that this never a problem I've run into. IMO the verbose error messages for complex types are a much bigger problem, which could be solved with better UIs for error messages (syntax highlighting and code folding).

The rule I tend to follow is "annotate as little as possible". This has worked out great for me so far since TypeScript's inference gets it right 90% of the time and it leads to more maintainable code.

Also after coding 5 days a week for a full year with it I really can't relate to the idea that it is somehow unpredictable. I think, like most things, you eventually get a "feel" for it and don't even have to think about it.

That's what I love most about it. It feels like it takes up no extra mental real estate for me. It's excellent at never "getting in the way" (when used properly)

Use LSP feature that reveals what TS thinks is the type of the identifier under the cursor (I have it bound to Shift+K in Neovim). If not right, annotate (or better go back and type properly whatever means you obtained that value).

When I see things like this I have a visceral reaction that I just can't get over.

https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...

Yeah, not wrapping your hook before sticking it in unknown interfaces is a recipe for visceral disease. They don't teach that in school these days?

Practice safe interactions - say no to unprotected injections.

Code looks fine to me. Classic blame the programmer mentality. Shame on you.

Hey, I think it's mutual responsibility on both API provider and user to engage in communication before mixing parts.

Who to blame is less important when you have an abandoned/orphaned child processes to take care of :/

No kink shaming, tho.

> I think it's mutual responsibility on both API provider and user to engage in communication before mixing parts

And I think it is the responsibility of the type system to at least catch if I'm passing too many arguments to a function.

TypeScript flags when I call a function that takes two parameters max with three arguments as an issue in many contexts, but not in contexts like this.

I understand why they chose to do this, but I reach for better type systems any time I have the choice.

Have you used EdgeDB in prod? I’m itching to try it, but am too worried about general instability. Seems like too many moving parts. Love the DX though, it’s really clean and well thought out.

No, not in production yet. But I'm not really worried.

There is so much wrong with JS, the only reason it is used is because people are literally forced to.

It took a long time for js devs to accept the notion of a compiler with TS. While TS is an improvement, it’s only a localized one. No chance ever, any other language could have replaced it.

> There is so much wrong with JS, the only reason it is used is because people are literally forced to.

There are perhaps at least a hundred (when not hundreds of) compile-to-js languages, yet people still use it. Even in back-end!

> It took a long time for js devs to accept the notion of a compiler

People who write programs in JS cannot be so easily grouped together, I think. There's this eternal September of bootcamp devs writing... interesting... code as we all did when we first started, but I personally went first with C, Perl, then PHP, then JS, then .NET, then Python and now continue mostly in TS and Java. Among them TS is the one I like the most (and the ones starting with P are the ones I dislike the most - not that it matters, use whatever works for you).

On the other hand, Stockholm Syndrome is an underrated and under-researched effect in software engineering.

There are people ready to defend with their life the most obtuse, inane piece of technology, just because they have invested a non-negligible amount of time getting used to its quirks, that they become completely blind to its faults, and start to believe those very quirks are actually positive and to be cherished.

> TanStack Router is built to be extremely type-safe.

This is alludes to my only major complaint about typescript. IMO, something is either type-safe or it ain't. I don't like how the JS bleeds through if you aren't careful.

I'm not a TS hater by any means, I use it regularly and am usually pleased. I just can't help but compare it to the [S,Oca]ML compilers I'm so fond of.

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.

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"

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

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.

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.

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.

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.

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.

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.

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/

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.

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

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)

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.

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.

hmm... I've been using JS/TS for almost as long as they've existed. A lot of these are nice. Some less so. Some quick thoughts:

- Tagged template strings. This just feels dirty to me. Probably won't use, but when I see it in a code base I won't be so confused at least

- matchAll. I've never needed this. I've used match with g a bunch, but I never need the capture group.

- Promise.allSettled. THIS is useful. I've implemented this (under a different name) in almost every code base I've worked on, and got bit HARD by not understanding this behavior long ago (huge production outage that took hours and many engineers to discover)

- globalThis. EW. Don't think I have to elaborate

- replaceAll. It's always annoyed me needing to use RegEx for simple replace all. so Yay!

- ??=, &&=, ||= These seem really useful, but also potentially hard to read, but I think if I get used to their existence they'd become second nature

- # private... not sure why they didn't just use the "private" keyword, but I don't care. I almost always use TypeScript anyways

- static ... YAY! finally. Again, if they could do this i don't see why not "private"

For the TypeScript stuff I'll just say the type system has kinda jumped the shark, but I don't hate it. It's SO robust and of all the new stuff being added I'll maybe use 1/10 of it, but it's good to know I can describe literally anything* with it if needed.

* EXCEPT IF I WANT TO USE AN ENUM/TYPE AS A KEY IN AN DICT WHICH I REALLY WANT TO DO!!

WRT Enum as key in object:

  enum TestEnum {
    Fizz = 0,
    Buzz,
    Bar,
    Baz
  }

  type EnumKeyedObject = Record<TestEnum, string>;

  type EnumKeyedObjectAlt = { [P in TestEnum]: string };

That's still awkward and confusing for what would be one of the most common use-cases, if it were less awkward.

How would you simplify the syntax here?

I'd like to be able to just do...

    type UserType = 'default' | 'admin' | 'manager';

    interface UserTypeCounts {
        [key: UserType]: number
    }

Not the best example, but it gets the point across. When you do this it says the key must be a string type which it actually is. It's just a string limited to specific values.

Yes, I could do an interface with explicitly named keys instead, but if that type (or enum) could have dozens of possible values it's annoying to duplicate it.

"when I see it in a code base I won't be so confused at least"

When I first started using node way back when I discovered all kinds of idioms in use that I had never seen. It was a confusing few weeks for sure.

>* EXCEPT IF I WANT TO USE AN ENUM/TYPE AS A KEY IN AN DICT WHICH I REALLY WANT TO DO!!

It's better just to use an actual array for enums:

myEnum = ["E1", "E2"...] as const

type myEnum = typeof myEnum[number]

That gets you both an enum type and an enum array you can use at runtime

I've used globalThis for polyfills in code that needs to run both in the browser and on node.

"??=, &&=, ||=" Yes they are, i stuck always when i see them. I think we just need more practice and need to see them more often until it becomes normal. Currently i avoid to use them.

Regarding your last point, I think the general consensus in TypeScript is to avoid using enums entirely.

What about union string types?

I'd really like to be able to just do...

    type UserType = 'default' | 'admin' | 'manager';

    interface UserTypeCounts {
        [key: UserType]: number
    }

> - Tagged template strings. This just feels dirty to me. Probably won't use, but when I see it in a code base I won't be so confused at least

What's funny is the go-to example of using it for translations is just wrong: It only does numeric indexing, so can't be reliably used with languages where words would be in a different order. You still need a library or something that builds on top of it to handle that.

Realistically changing word order isn't enough for translation either, you need a special language like ICU message syntax so you can handle grammatical number, gender, etc.

> - Tagged template strings. This just feels dirty to me. Probably won't use, but when I see it in a code base I won't be so confused at least

Tagged template strings are an absolutely brilliant feature and have tons of valuable uses. In particular, many sql libraries in node let you do this:

    const query = sql`select foo from bar where zed = ${param}`;

From a developer standpoint it "feels" just like you're doing string concatenation, but in reality the query variable will contain a prepared statement so that it safely prevents any kind of SQL injection, e.g. it gets parsed to

    {
        sql: "select foo from bar where zed = ?",
        parameters: [param]
    }

There are lots of use cases where things are easily expressed as an interpolated string, but the thing you want back is NOT just a plain string, and tagged template literals are great for that. It's also a nice way to call a parser, e.g. many GraphQL libraries let you do:

    const parsedGraphQLSchema = gql`type Query { foo: Int }`;

Is it really an good thing that a vulnerable sql string interpolation code pattern and this sql tagged string look and feel the same?

I was thinking the same thing... If I do that I'm going to forget the "sql" part at least once and nothing's going to alert me about it.

The way libraries work it's impossible to forget the "sql" part and still have that query be executed - see my sibling comment.

Actually, yes, it is. The way these libraries work, since the thing that is parsed is NOT just a plain string, in most cases it's impossible to have sql injection without doing some deliberately nasty stuff. That is, you can't just do this:

    const query = `select foo from bar where zed = ${param}`; // forgot the sql tag
    await runQuery(query);

In that case, the type of query is just string, but the `runQuery` method doesn't take strings, it takes a parsed query, so that wouldn't work.

After using the tagged template literal pattern for SQL queries exclusively for the past couple years, I can't say enough how awesome it is to use in practice. Libraries even let you do strong typing with TypeScript to define the expected structure of the result, e.g.

    sql<MyExpectedReturnType>`select foo from bar where zed = ${param}`

> Libraries even let you do strong typing with TypeScript to define the expected structure of the result.

The tagged template does not return a string in this case?

No, it usually returns a parsed object. For example the gql tag in the apollo client libraries return a completely parsed query with all its various children and sub-objects.

Why wouldn’t it be? Do you think developers get inspired by this slick API and decide to write functions that talk directly to the database using unescaped interpolated strings? I doubt it.

I fear that syntactic sugar creates as many problems as it solves. For instance, one might wish to sort the results by whitelisted column:

    query = sql`select foo from bar where zed = ${p} order by ${col} asc`;

Unless the lib implements a real SQL parser for the right dialect, it will quote each expression in the same way, and will either fail or produce a broken SQL.

Definitely a lot of misconceptions around how this would work. Just check out something like slonik, https://github.com/gajus/slonik, which is an excellent implementation.

The example you gave actually isn't valid, because what you're doing is generating SQL dynamically, and that doesn't work the way prepared statements work. That is, you can't have a prepared statement like "select foo from bar where zed = ? order by ? asc", because with prepared statements the question marks can only substitute for VALUES, not schema names. So if you wanted to do something like that it slonik, it would fail. With slonik you CAN do dynamic SQL, that is guaranteed to be safe and checked at compile time with TypeScript, because you can nest SQL tagged templates. That is you can do this:

    const colToSortBy = useFoo ? sql`foo` : sql`bar`;
    const query = sql`select col from mytable order by ${colToSortBy}`;

In that case slonik will know how to safely "merge" the parent and child parsed SQL.

We actually did the same for ArangoDB (I think we first did this in 2015, I remember being surprised nobody had done something similar for SQL at the time). Here's the JS driver's current implementation of it:

https://github.com/arangodb/arangojs/blob/main/src/aql.ts#L1...

Basically the `aql` template tag returns an object that can also be fed back into it and we also deduplicate arguments to avoid sending redundant data over the wire. There's also an escape hatch via a helper function (`aql.literal`) in cases where you need to insert literals that aren't known at compile time (e.g. you load query filters from a configuration file).

> - # private... not sure why they didn't just use the "private" keyword, but I don't care. I almost always use TypeScript anyways

One of the reasons was to allow private and public fields of the same name, so that subclasses are free to add own public fields without accidentally discovering private fields of superclasses. There were many more considerations that went into the design: https://github.com/tc39/proposal-class-fields/blob/main/PRIV....

There was a heated debate about this and the choice of the # sigil back in 2015 at the time private fields were being designed: https://github.com/tc39/proposal-private-fields/issues/14.

Isn't Record<EnumType, whatever> working?

Then instantiate like:

``` { [EnumType.First]: ..., [EnumType.Second]: ... } ```

Yep, do this all the time. It's also really nice because when you define a type as

    Record<EnumType, any>

then when you are creating an instance of that Record object, it requires a key for all the EnumType values, and will fail if you forgot one. Still possible to do

    Partial<Record<EnumType, any>>

if you want the keys to be only of the EnumType, but don't require all the EnumType values to be used as a key in the Record.

> Tagged template strings. This just feels dirty to me. Probably won't use, but when I see it in a code base I won't be so confused at least

A while back I wrote that "Tagged Template Literals Are the Worst Addition to Javascript" https://dmitriid.com/blog/2019/03/tagged-template-literals/ and I still stand by it.

The fact that someone uses them in a somewhat nice fashion in an sql library doesn't change the fact

> - Promise.allSettled. THIS is useful. I've implemented this (under a different name) in almost every code base I've worked on, and got bit HARD by not understanding this behavior long ago (huge production outage that took hours and many engineers to discover)

You and your team didn't understand how Promise.allSettled behaved?

I'm guessing the more common error, which I've definitely hit years ago, is not knowing that Promise.all returns immediately if any of the included promises reject.

That's what I'm guessing, too.

Correct. It was millions of lines of code in a huge code base at a giant enterprise company with 100s of engineers. Somewhere buried in there there was a Promise.all that someone assumed would finish ALL of the promises, and didn't account for the fact that it bails on the first error.

No, Promise.allSettled didn't exist yet. It was Promise.all.

Someone basically made the assumption that await Promise.all would wait until ALL promises finished. Which is true..... unless one of them throws. In which case it continues. This caused a race condition. It was an extremely complex code base with 100s of engineers and the error very rarely happened, and when it did happen the app would get stuck on a loading screen forever. Also, it turns out "rarely" happens to a lot of people when you have millions of users.

"The only programming languages that people don't hate on are the ones nobody uses." - someone online

Negative indexes might actually be useful.

At some point I actually need to read the actual language specs, I guess.

For reference, here's the current spec...all 833(!) pages of it.

https://www.ecma-international.org/publications-and-standard...

The author of C++, so maybe take that with a little grain of salt.

C++: an octopus made by nailing extra legs onto a dog. — Steve Taylor

But more seriously, languages that are less formally made and have grown organically all deal with these types of things. PHP is a great example of a language with a TERRIBLE core library filled with numerous "don't use this" and "yes this doesn't make sense" and esoteric foot guns.

Of course, these languages are the ones that took off and people use everywhere. And languages like PHP have made great strides to the point that using PHP8 with a modern set of libraries is not so bad.

Yes, but Go is also popular and famously resists doing that as much as possible. Maybe language popularity isn't a good metric, since there could be other reasons a language becomes popular. Worse is better, and what not.

“Haha, C++ bad meme.”

tbf that statement is only usefull if you have a choice, but is there really a choice for typescript/javascript? you can't have rich apps without it. and wasm isn't there yet.

Object.hasOwn(obj, name): Finally! That took long. Why would you even think that obj.hasOwnProperty(name) would be ok? If its unclear what properties there are you can't expect that the hasOwnProperty property to be working correctly. Always had to do the Object.prototype.hasOwnProperty.call(obj, name) dance.

We need an equivalent "All AI breakthroughs in the last week explained"

Two Minute Papers is a relatively good proxy for this! https://www.youtube.com/channel/UCbfYPyITQ-7l4upoX8nvctg

too bad i simply can’t stand the way he talks :( am i the only one?

Probably not, I dislike video / audio as a means to explain and update things, I'll watch the news (because the video adds to the story) but I'd rather have a text version if it's about software things.

Something grating going on with him. I think it might be the way he tries to make it sound exciting for a general audience.

>I think it might be the way he tries to make it sound exciting for a general audience.

Looking at other videos of Károly Zsolnai-Fehér speaking at a podium to an audience, I think he's genuinely enthusiastic about the subject instead of putting on an act. However, when combining that unusual enthusiasm with a Hungarian accent, some listeners may find it odd sounding.

Example vid: https://www.youtube.com/watch?v=-JdmOBA0WQ0&t=1m49s

"Two Minute Papers"...

...ironically in video format.

That's not ironic to me, the intent seemed to be "papers presented in two minutes", although maybe there's some irony in exceeding that length in every video?

Sure.

What is the irony?

a paper in video format?

I actually hate videos, it's easier for me to read than to listen to someone taking 5 minutes to explain a paragraph's worth of stuff.

"It's longer because monetization."

How is that ironic? I wonder if people actually know the meaning of irony these days.

Definition: "a state of affairs or an event that seems deliberately contrary to what one expects and is often amusing as a result"

A YouTube vblog calling itself two minute papers seems pretty ironic to me. The word "papers" is key here.

It discusses papers in two minutes, not sure how that's ironic at all, unless you are deliberately expecting that a YouTube channel somehow has written papers rather than videos. These papers would also take one longer than two minutes to read and might not have context from someone in the field, so I'm happy for the expert to go over it for me.

Two minute papers-- but they are videos.

I feel like I am repeating myself.

Definition of irony...

Just because two things sound odd doesn't mean there is anything ironic about it. I could also name my YouTube channel something like Full Orchestral Performances but have them be videos and not music. That's not the definition of irony, but I don't think me explaining it further will make you understand what irony is.

This is a false analogy though. If you had a YouTube channel called Two Minute Full Orchestral Performances I would expect Full Orchestral Performances of two minutes, basically a musical performance.

Since we consume either articles (which are often rated as "This will take you 3 minutes to read") or video, the title is deceiving. Particularly as someone who finds consuming information infuriatingly slow in videos, and prefer to read or scan articles, I find it has a sense of irony to it.

Right I agree with this. I hate videos too, it's the worst way to compress information.

@eluna.ai posts summaries on ig

My friend runs a newsletter called Bot Eat Brain which is precisely this.

https://www.boteatbrain.com/

I took the time to explain all the latest (and some older) JavaScript and TypeScript changes, including code examples.

Symbols are not an ES2022 feature. I believe they were introduced in ES2015.

Just looked it up, you are of course correct. I will move them into the "Past" part.

Thanks for doing this! I found this post very helpful to get exposed to recent changes from the last couple years.

Looked up on MDN (and from there the ES spec), import assertions don't seem to actually be standard. You might want to mark that somehow (or drop it).

You are correct, I added a note.

As a swe that works with typescript / javascript, I find this post exhausting.

Am I the only one? Am I a shit swe?

Edit - comments seem to suggest I was asking this question seriously. I was not, I was just (sort of) joking.

That being said, front end engineering is rapidly changing all the time, so the confidence I have in knowing I will always have work to do (read that to mean: a job) is satisfying.

It’s exhausting because: _____

If you find yourself struggling to articulate it, seriously and honestly consider whether you’re simply choosing to be stressed about it.

I’m speaking from experience here.

I don't think it's that bad but I wish they'd focus more on improving the terrible JS web API rather than adding language features.

I mean they are adding features like static initialisation blocks when we only just got String.replaceAll(), and they somehow managed to fuck that API up despite it being explicitly a replacement for an existing bad API!

Where are all the containers? Sorted sets/maps? Why can't I even map an iterator?

> focus more on improving the terrible JS web API

That's W3C’s job, not ECMA’s.

> Where are all the containers?

> Sorted sets/maps?

Sets and Maps are sorted (by insertion order)

> Why can't I even map an iterator?

It's coming, but someone will likely be exhausted by that addition. https://github.com/tc39/proposal-iterator-helpers

> Sets and Maps are sorted (by insertion order)

That's not what a "sorted set" is. C++ and Rust provide sets (and maps) that sort based on an arbitrary comparison operator.

> ?

> but someone will likely be exhausted by that addition

I suppose. I guess it's one of those things that they really should have got right the first time. Like String.replaceAll(). I guess they will never add String.replaceAllSafe() - well just have to rely on linters to tell us that the API is terrible forever.

By sorted sets/maps, I think they are referring to a binary-search-tree-backed implementation that is efficient for operations like find all keys between x and y, e.g. something like Java's SortedSet[1].

[1] https://docs.oracle.com/javase/7/docs/api/java/util/SortedSe...

I think one can both learn about the new features without feeling the need to use them all or refactor old code.

My biggest learning while writing this was just how much is possible in JavaScript and TypeScript now, but I also realize that a lot of this I will not use myself or only use to understand some really specific code.

You're certainly not the only shit SWE if you are one. I used to be a good all-rounder, but I've stagnated badly for years everywhere but the database. I should probably have shuffled to management (I understand more than I can do!) but I hate the very idea.

I don't find it exhausting. There's some stuff I already use, some I'll remember, some I'll forget, and one day I'll probably google for one of these features, but until then it's not going to weigh on me.

Yeah I'm the same. I try not to worry and learn everything, but I try and at least read on new changes just so I'm familiar with them.

Then when I see it in the code, I'll know what it does or I'll be like "Oh wait, that new feature I read about, maybe that could be of use here".

I'm never going to remember everything and I'm okay with that :)

It's understandable of you haven't touched JS for a few years. But if you work with JS/TS a lot and are not aware of/already using many of the features listed here, you need to ask yourself (or maybe your company) if that's ok. A lot of these are very nice features that are used daily -- they help code to be cleaner and more concise, and you can work more productively.

Not to mention -- most of these features have been in other languages for years. So in this case, JS/TS have been behind and are just catching up to what you'd find everywhere else.

> #private: […] This is not recommended for TypeScript projects, instead just use the existing private keyword.

Why not? I was told the opposite: now that the feature is in JS natively, it can be used.

The Deno style guide encourages the use of `#prop` over `private prop` [0]. Other guides such as the Google TypeScript Guide discourages their use [1] for now because they are transpiled to slow code.

What I could conclude is: use `#` over `private` for runtimes that support them or projects that can target recent runtimes and browsers.

[0] https://deno.land/manual@v1.29.3/references/contributing/sty...

[1] https://google.github.io/styleguide/tsguide.html#private-fie...

Probably so that tsc can transpile it differently for older browsers.

Not to be the perpetual Luddite, but I hate how much programming languages change. I don’t particularly like go as a language (good board game though), but the minimal changes over time starts to feel really correct.

C doesn't seem to have substantially changed in 20+ years.

The C99 changes were pretty radical, but couldn't be broadly used until around 2016 when the Microsoft compiler finally caught up and started to implement the most important C99 features.

C11 provides a lot of useful goodies too. I don't relish the idea of writing C89 and giving up all the improvements.

C23 adds support for type inference.

It has.

To be fair, now that almost all professionally-written passes through a rewriting compiler, Javascript actually has evolved to a ecosystem that _can_ handle rapid (non-breaking) changes to a language spec.

I'd also argue that the majority of these changes are to the standard library (new methods on String, Array, RegExp, etc). Not really core language changes. I don't know how often the go libs update but surely faster than the language spec?

> To be fair, now that almost all professionally-written passes through a rewriting compiler,

What?

They're likely referring to Babel and TypeScript. In short, it doesn't matter what you're writing as long as your transpiler has the right `target` so it works in older browsers/engines too.

There are popular JavaScript tools that nearly everyone uses, that reimplement Lisp poorly by source-to-source compiling stuff written against the latest new hotness spec into something that can be run by some old-and-busted JavaScript runtime (e.g., in browsers).

In fact this is how TypeScript is implemented.

A pass to strip some type annotations isn't a poor reimplementation of Lisp, jeez.

I know the quote you're referring to but you're stretching a mile to get there.

To add the above - I also meant to write "Professionally-written Javascript" in case it was the grammar that threw you off. Sorry!

Thanks. :) Wasn’t able to fill in the dropped word.

The changes aren't breaking. Javascript from the 90's still works.

I don't think the issue is that languages change per se - it's that they borrow features from other languages, that people ask "can we have $feature from $language please?"

in JS (and years before that, PHP), one example was object-oriented programming / classes, except in both JS and PHP it was never implemented fully, with JS not even having access modifiers for a long time. JS didn't need classes and the implementation is lacking, but someone decided it should be added.

Likewise, Java had functional programming bolted on; they never extended the base List types with functional modifiers, so now you have to transform or wrap your List in a Stream to make it work with Java's attempts at functional programming. Personally, I think if you want to do FP or FP-style coding on the JVM, you should rewrite things in Scala. You can write Scala and Java side-by-side.

Same with JS, you want JS but with types? You can have Typescript. I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.

My second love was LISP. I love me some functional programming.

But I greatly dislike multi-paradigm programming languages. Mostly because I've worked with other programmers.

Borrowing features (idioms) from other languages is great. Pattern matching is nice. For Java, I'm looking forward to (interpolated) string templates and implicit classes. Destructuring would be nice too.

But for the love of Larry, where are intrinsic regex expressions?

Path expressions?

Most of our work is data processing.

Input -> munging -> output.

Meaning cutting and pasting strings.

So I mostly want new features related to string and data processing.

The evergreen fetish (kink) with arcana like type systems, monads, and metaprogramming is just so besides the point. That's what Lambda the Ultimate and HN are for.

For "commercial" languages, just give me tools for work.

Fussing with novel languages is for my hobby projects.

What does "intrinsic regex" mean?

Sorry. I should have written "regex intrinsics". Meaning native to the language, vs implemented as a library. Just like Perl's syntax for regex.

So like the /^regex(.*)syntax$/g that we have in vanilla JS?

(I agree with your overall point BTW.)

Yup.

I just checked; the MDN docs refer to them as "regular expression literals".

> I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.

Jeremy tried https://arcturo.github.io/library/coffeescript/03_classes.ht...

> I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.

I think the classes were a good thing. Better would have been to change the OO model entirely, but if you're going to have one and can't change it, nice to at least have some sugar to make it usable. IDK if it's better elsewhere, but prototypal OO was pretty clearly a miss-step for Javascript, and sugar to make the OO system usable and less-obtuse (while making it easier to ignore the parts that should basically never be used, which parts amount to all the distinctive things about prototypal OO) is a decent move.

> Same with JS, you want JS but with types? You can have Typescript. I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.

Wow, relevant username for this take, as you'd end up with an eldritch creature as soon as people tried to bolt these DSLs together into their opinionated bags of features, and a meta-language landscape that resembles the already fragmented frontend landscape of today

If it's any consolation, the guy from nomadlist is building AI businesses with jQuery and PHP: https://twitter.com/levelsio/status/1633422349012992007

How does it work, though?

I'm more annoyed that the direction of change is mostly converging. Maybe that's a good thing, but it seems every language needs to add every popular feature of other languages until it's possible to code any language as any other language except in incompatible syntax.

In the case of TypeScript, we have the base JavaScript, template literals, and the type system all playing this game in the same file. Three systems trying to out feature each other. Tagged template literals, template literal types, etc.

Template literal types (a) have nothing to do with tagged template literals, and (b) are a game-changing feature, allowing you to write compile-time string parsers.

> allowing you to write compile-time string parsers

I’m not entirely sure this is a good thing. But it’s certainly convenient in some instances.

I, for one, love that my ORM can statically check my SQL statements.

It’s a cutesy thing that basically always comes with a “don’t actually do/use this!” disclaimer. The thing that’s actually good about template literal types is that they allow for modeling a whole class of real world JS that wasn’t possible otherwise. That is and always has been the fundamental goal of TS.

Go helped me realize that how much you like a language can partially be a function of how you try to use it.

I used Go wrong for years. Once I stopped doing dumb stuff with it (especially with the type system), it got a lot more pleasant. I don’t think I’d design it the same way, but I’m quite a bit happier using it now.

It’s kind of like using a hammer to drive a screw. The problem isn’t the screw or the hammer. Go seems to be a hammer-screw situation for a lot of people, but there really is a happy path.

Not saying this because I think you’re unaware — mostly thinking out loud because I used to feel like Go needed new features and your comment reminded me of this. I also like the relative stability of Go now, though. It has a great foundational toolset and good design overall, so to its credit, it hasn’t really needed to change so much. I only thought it did because I used it wrong.

There is another list with concise code samples

https://www.javascripttutorial.net/es-next/

For me, the most awesome and useful change to Javascript has been the addition of private and static modifiers, although the implementation is kinda weird (why use “static” keyword but not “private” and the # sigil instead?). I use both TS and JS professionally but much prefer native JS and use it in my personal projects, however, the closer native JS can get to TS, the better, as I really do appreciate many of it’s features.

The # sigil has always bummed me out too.

Supposedly it's because of this:

> Why isn't access this.x?

> Having a private field named x must not prevent there from being a public field named x, so accessing a private field can't just be a normal lookup.

https://github.com/tc39/proposal-class-fields/blob/main/PRIV...

Combined with this:

> Why aren't declarations private x?

> This sort of declaration is what other languages use (notably Java), and implies that access would be done with this.x. Assuming that isn't the case (see above), in JavaScript this would silently create or access a public field, rather than throwing an error. This is a major potential source of bugs or invisibly making public fields which were intended to be private.

https://github.com/tc39/proposal-class-fields/blob/main/PRIV...

But I still think it's weird.

Because they awkwardly bolted C++-like class syntax on top of prototype-based language and are now fighting that.

Same goes for methods that you have to manually bind to `this` in the constructor etc.

It literally is one of the "they didn't think if they should" parts of the language.

This is why I appreciate TypeScript, as it fixes a lot of Javascript’s syntactic goofiness, but of course I can’t use it natively, which takes it off the table for some projects.

The # for private throws me every time I look at my code. Keyword "private" would have been so much cleaner and in line with most programming languages out there.

" Negative indexing (.at(-1)): When indexing an array or a string, at can be used to index from the end. It’s equivalent to arr[arr.length - 1) " sic arr[arr.length-1)

This is wrong. Array.at can get, but not set the value. So they're not equivalent.

console.log( arr[arr.length-1] ); // works

arr[arr.length-1] = 1; // works

console.log( arr.at(-1) ); // works

arr.at(-1) = 1; // ReferenceError: Invalid left-hand side in assignment

Thanks, I edited it to include this, just to make it clear.

Is it me or are Tagged templates a recipe for hard to read code?

Just the way it extracts the substrings into arguments for unpredictable strings. It doesn't translate to readable code.

I'd much rather use repetitive template strings. Unless I was doing some really fancy string manipulation. Or make my own functions with explicit arguments.

Matching up the template strings with the values is a little wonky because there’s always one more string than value. But it’s pretty rare that you’d write lots of different tagging functions, usually you write a generic one to use with many different types of templates. Tucking away complexity into a function to make nice and easy-to-use templates is a reasonable trade off I think.

They've allowed "styled-components" to work though, which is pretty nice. I always thought of them as providing a way to parse DSLs directly in your code. For example, a fictional way to generate some config could look like this (using tagged templates):

  const thingies = ["a", "b"];
  const config = yaml`
    - foo
    - bar
    - baz
    - thingies: ${thingies.map(thing => yaml`- thing: ${thing}`)}
  `;
  // config = ["foo", "bar", "baz", { "thingies": [{"thing": "a"}, {"thing": "b"}] }]

At a company I worked at people were generating YAML using Jinja templates, but tagged templates to me would be a better approach. Is it hard to read? It can be, but compared to the alternatives it's not too bad.

  const thingies = ["a", "b"];
  const thingToYaml = thing => 
    yaml`- thing: ${thing}`
  const thingiesYaml =
    thingies.map(thingToYaml)

  const config = yaml`
    - foo
    - bar
    - baz
    - thingies: ${thingiesYaml}
  `;

It doesn’t have to be hard to read

In this example, why use YAML at all?...

    const thingies = ["a", "b"];
    const config = [
      "foo",
      "bar",
      "baz",
      {
        thingies: thingies.map(thing => ({ thing })),
      },
    ]
    // config = ["foo", "bar", "baz", { "thingies": [{"thing": "a"}, {"thing": "b"}] }]

Right, it's not a great example since yaml is intentionally equivalent to JS objects.

Well, styled components also has a plain object syntax which I think a lot of people prefer me included.

To me, the single best example, is a function that turns a template into a parameterized query, and then makes an async database request...

    var result = await query`
      SELECT * FROM foo.bar where baz = ${baz}
    `;

There are libraries that allow for construction of queries as well using template strings. I don't know of too many instances beyond this where there's custom functions for tagged templates, vs just string building with parameters.

Can confirm. This is the best use case I've come across. You can dynamically compose queries and not even think about argument positioning. No concern about injection. Better performance than named variables that are translated into positional.

I agree this is pretty much the best example of this feature in action... which is why I don't think it should have been made a language feature.

It's nifty, but not nearly better enough to justify its existence, IMO. Here's the alternative:

    var result = await query(
        'SELECT * FROM foo.bar where bar = :baz',
        {baz}
    );

I get it... there's that extra level of indirection. But people are working hard, as we speak, to abuse the feature.

I'd rather have the language settle on one single templating syntax rather than every library and their son bake a half-assed one. "Oh, does query use the : syntax? The $ one? Does it take the template string first, or the arguments?" And with your example, `query` needs to figure out how to parse the string, extract the template slots, and pass the correct arguments into the correct slots. It's a recipe for disaster if every library needs to reimplement that.

Well, people could settle on a common templating syntax without making it a language feature. The fact that they haven't tells you it's not that important, relative to other concerns.

It's not like "figure out how to parse the string, extract the template slots, and pass the correct arguments into the correct slots" is rocket science.

And it's not like people are going to rewrite the numerous existing libraries for this kind of thing. The new tagged-template APIs are going transform their arguments and call the existing APIs.

I guess it's nice that new Javascript-specific templating languages can have common escaping syntax. It's just hard to get excited about the 15th standard.

I like tagged template strings but nowadays most libraries use TS (or at least JSDocs) and any serious IDE will be able to quickly answer your question of what type of parameters a function is expecting

In this case - the thing I personally value in the template version is I don't have to name the parameters and specify them in a separate place. It's especially useful in larger queries.

    var result = await query(
        'SELECT * FROM foo.bar where bar = :baz
          -- 100 more lines of where clauses, CTEs, etc.
        ',
        {baz} // where did I use this again?  I'd need to scroll up.
    );

versus

    var result = await query(
        sql'SELECT * FROM foo.bar where bar = ${baz}
          -- 100 more lines of where clauses, CTEs, etc.
        `);

I find them to be really useful for simple and targeted tasks. For example, simplur[1] for pluralizing strings and dedent[2] just for developer ergonomics.

[1] https://www.npmjs.com/package/simplur

[2] https://github.com/dmnd/dedent

Is there a difference between

   dedent`something ${code}`

and

   dedent(`something ${code}`)

? Not sure to understand the advantage of tagged strings here...

The difference is on the tag side. "Tag functions" receive the string segments separately from the interpolated values, so like:

    function exampleTag(stringSegment, ...values) {
      console.log(stringSegment);
      console.log(values);
    }

    const myNumber = 123;
    
    exampleTag`foo ${myNumber} bar ${myNumber}`;

    // Prints:
    // ['foo', 'bar', '']
    // [123, 123]

This gives the tag function a way to access the interpolated values themselves, before they get coerced to a String. You're correct, though, that it really doesn't make much of a difference for a dedent function.

It is actually important for a dedent function when the interpolands contain newlines. Consider this example:

    function fmt(q, a) {
      return dedent`\
        Question: ${q}
        Answer: ${a}
      `;
    }

Since `dedent` is basically syntactic sugar for developer convenience, we want this function to be equivalent to this:

    function fmtDesugared(q, a) {
      return `Question: ${q}\nAnswer: ${a}\n`;
    }

Now consider this input:

    console.log(fmt("a\nb", "c\nd"));
    // should print:
    Question: a
    b
    Answer: c
    d

But if `dedent` only got to see the string after interpolation—like this—

    function fmtWrong(q, a) {
      return dedent(`\
        Question: ${q}
        Answer: ${a}
      `);
    }

then the input to `dedent` would be

      Question: a
    b
      Answer: c
    d

and so `dedent` would not strip any indentation. That is, `dedent` is meant to identify the maximal common leading indentation in the template as written by the developer, which should not depend on the values of the interpolands.

A stale GitHub issue on the dmnd/dedent repo has a real-world example where this matters and led to a subtle bug: https://github.com/dmnd/dedent/issues/22

That is an absolutely fantastic point, and one I hadn’t considered. Thanks for the explanation, and also for teaching me the word “interpolands”. :)

I love tagged templates and am so relieved to finally have something like Perl/Ruby/PHP's heredocs.

We should be able to write multi-line strings without having to break our linter's tab rules or write some silly post processing function!

Not mentioned: importmap is supported in Firefox as of February. Also supported in Chrome and upcoming for Safari. Just in time as I finally started getting more into cutting edge JS with a personal project - job's been stuck on older JS for a long time and I haven't done personal projects in just as long.

I've been running this project straight in the browser with no JS compiler. Are JS compilers going to be on the way out now?

Import map is an HTML feature and not in any JavaScript specification. JavaScript language does not care about how to find files.

Is there a complete list of proper modern JavaScript features and examples covering all and only the features and styles which are modern (not neccesarily this new, perhaps some are 4-year-old) and relevantant + those which have never been replaced by any newer so are sill relevant although old but excluding outdated features and styles?

I haven't found one yet, but I'm sure there's one somewhere out there. I will try to keep updating this article so someday it will be what you're looking for.

Can you make an example of features/styles that have been replaced? I'm not really sure what you mean by that.

As an example, the immediately invoked function expression (IIFE) has been superseded by ES 6 modules.

The classic example is .then .catch callbacks vs async await, though .then is still occasionally useful.

Others have provided great examples of what I meant.

I’m not sure if this matches what you want, but I made a note of this site when I ran across it for a similar reason:

https://javascript.info/

straight legs jeans instead of bell-bottom jeans because less fabric required. Hats have been replaced by caps, or just go without either, because we are mostly inside anyway. We still use suits, but it's not required. Most people use jeans, because SWE's can't afford wool.

Ohh, sorry, you mean JavaScript... const is the new var because Java programmers don't understand function scope. ()=>{} is the new function declaration because many people want to go back to Perl like syntax. class instead of prototype because Java programmers don't understand prototype. TypeScript instead of JavaScript because Java programmers can't live without type annotations and editor autocomplete. async/await instead of Promise because what we can't see (async code) can't hurt us. import instead of require because JetBean intellicense could not autocomplete dynamic require/imports.

I don't know why this got downvoted but this is a great comment.

I want this for TypeScript, but also for C#, and C++, who have all been modernizing quite quickly.

If you asked me what the biggest areas were where JS needs work, it wouldn't be "syntax sugar for separating numeric literals", it would be stuff like "integers".

At this point I'm almost afraid to ask, but if JS can evolve in major ways like this, why can't we address some of the basic shortcomings of the language?

Is BigInt not what you want? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Ironically this is the only JavaScript change (except for top level await) I did not include, maybe I'll edit it and add it.

Those are 2 of the most significant (and eagerly awaited) new(er) features though (although I thought BigInt was more like 5-6 years old)

edit: Edge and Safari only added support in 2020, so it has only been useable without polyfills for a few years

I added them now so the article is complete.

I develop with JavaScript professionally and I rarely think about floating point number/integers when building UI or Node.js code. The "number" type is good enough in 99% of use cases. If you really need integers, there are specialized uint arrays and BigInt that handle various use cases.

None of these changes are that major. They don't breaking existing code.

Breaking existing code is a pretty major line to cross for anyone maintaining a language, library or tool. (Even though some people do it willy nilly....)

> String.prototype.replaceAll

14-year old me hacking up my first JS on Freewebs.com is doing backflips right now.

...And 31-year old me is saying "What the fuck took them so long?"

There must be a mistake in the "Exact Optional Property Types" section?

Hey, if you think you found a mistake, please also tell me what it is so I can fix it.

The error message talks about having flags set wrong and doesn't complain about anything the code is doing.

Also your code for "Tuple Optional Elements and Rest" is broken. Pad is declared twice and it's returning the wrong thing.

Thanks, I fixed both of them.

I think you mean to have undefined after the equal sign, otherwise I don’t see how there could be an error

Yes, the error was also wrong, fixed it.

I'd also assign undefined to 'age' to show that it's not erroring

Good point, done.

Are * and default the same?

Can you clarify the question? In what sense are you asking if they're the same / not the same?

In general, `import * from X` will pull every exported symbol of X into your current module at the top level (generally not recommended except for special cases like testing libraries; you shackle yourself to an assumption that the imported module won't ever add new symbols that might interact surprisingly with the importing module). `import * as Y from X` is slightly safer; it'll pull in all the exported symbols from X, but will wrap them in a Y namespace (so X's `foo` function is now `Y.foo`, etc.). `import {foo} from X` will just import the `foo` symbol from X and make it available in your module. Finally, `import foo from X` imports the single export in X that is tagged as default and names it `foo` in your module.

(To my money, I don't like defaults very much. I much prefer `import {foo} from X` over `import foo from X` for clarity, even if `foo` is the only symbol X exports. It allows for future growth of X and avoids the unsightly `import foo, {bar} from X` that some modules end up growing in the future).

No. The former imports all the exports, and the latter imports the default export only.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

`*` is the namespace object. `default` is a special named property on the namespace object.

someModule.js:

    export default 'foo';
    export const bar = 'bar';

namespaceImport.js:

    import * as SomeNamespace from './someModule.js';
    console.assert(SomeNamespace.default === 'foo');
    console.assert(SomeNamespace.bar === 'bar');

defaultImport.js:

    import foo from './someModule.js';
    console.assert(foo === 'foo');

namedImports.js:

    import { default as foo, bar } from './someModule.js';
    console.assert(foo === 'foo');
    console.assert(bar === 'bar');

Note that there's an error on the default export:

    - export default foo = 'foo';
    + export default 'foo';

thanks, fixed

A lot of 'x1' should be 'x2' in the examples

lmao negative indexes in 2022

Reply on news.ycombinator.com