Optional chaining ?. is safer to use than non-null assertions !.

Consider the following interface:

interface Foo {
    bar?: {
        baz: string;
    }
}

The bar property is optional. If it doesn't exist it will be undefined when you read it. If it does exist it will have a baz property of type string. If you just try to access the baz property without making sure that bar is defined, you'll get a compiler error warning you about a possible runtime error:

function oops(foo: Foo) {
    console.log(foo.bar.baz.toUpperCase()); // compiler error
    // -------> ~~~~~~~
    // Object is possibly undefined
}

Optional chaining has actual effects at runtime and short-circuits to an undefined value if the property you're trying to access does not exist. If you don't know for sure that a property exists, optional chaining can protect you from some runtime errors. The TypeScript compiler does not complain with the following code because it knows that what you are doing is now safe:

function optChain(foo: Foo) {
    console.log(foo.bar?.baz.toUpperCase());
}

optChain({ bar: { baz: "hello" } }); // HELLO
optChain({}); // undefined

You should use optional chaining if you are not sure that your property accesses are safe and you want runtime checks to protect you.

On the other hand, non-null assertions have no effect whatsoever at runtime. It's a way for you to tell the compiler that even though it cannot verify that a property exists, you are asserting that it is safe to do it. This also has the effect of stopping the compiler from complaining, but you have now taken over the job of ensuring type safety. If, at runtime, the value you asserted as defined is actually undefined, then you have lied to the compiler and you might hit a runtime error:

function nonNullAssert(foo: Foo) {
    console.log(foo.bar!.baz.toUpperCase());
}

nonNullAssert({ bar: { baz: "hello" } }); // HELLO
nonNullAssert({}); //  TypeError: foo.bar is undefined

You should only use non-null assertions if you are sure that your property accesses are safe, and you want the convenience of skipping runtime checks.

Playground link to code

When accessing a property using bracket notation and optional chaining, you need to use a dot in addition to the brackets:

const value = a?.[b]?.c;

This is the syntax that was adopted by the TC39 proposal, because otherwise it's hard for the parser to figure out if this ? is part of a ternary expression or part of optional chaining.

The way I think about it: the symbol for optional chaining isn't ?, it's ?.. If you're doing optional chaining, you'll always be using both characters.

Firstly the TS compiler complains about Object is possibly 'undefined'.ts(2532) at obj. I don't get it since it looks to me like the object is indeed defined, it is just according to the interface the b and c property can be undefined.

Yes, compiler shows that b can be undefined. This message is not about the a. You can easily check this by changing if (obj.a === 1) - no error now.

The construction if (obj.a.b?.c === 1) will be converted to if (((_a = obj.a.b) === null || _a === void 0 ? void 0 : _a.c) === 1) after compile. I prefer using old good guards:

Copyif (obj.a.b && obj.a.b.c === 1) {
  console.log("here");
}

However this time the compiler says there is a syntax error

This is strange. Since TS 3.7 this should not be an error. Take a look on another online sandbox: click. You will see there is no error here.

At time of writing, TypeScript does not support the optional chaining operator. See discussion on the TypeScript issue tracker: https://github.com/Microsoft/TypeScript/issues/16

As a warning, the semantics of this operator are still very much in flux, which is why TypeScript hasn't added it yet. Code written today against the Babel plugin may change behavior in the future without warning, leading to difficult bugs. I generally recommend people to not start using syntax whose behavior hasn't been well-defined yet.