NativeScript has always walked on the forefront of technology. TypeScript was adopted in it's infancy as it was clearly important to provide some strong type checking throughout the framework since it provides direct interaction with strongly typed languages like Swift, Objective C, Java and Kotlin. Now that the underlying JavaScript engines fully support ES2017+, the team has been eager to move the bar from ES5 onto ES2017.
With version 7, full support for ES2017 as a valid output target has landed and now the default for the framework. Additionally targeting even higher versions is now possible given both iOS and Android engines are using the same up-to-date v8 engine which powers projects like NodeJS and Chromium.
TypeScript will no longer have to convert await/async into extraneous lines of code. Since the underlying JavaScript engine has had full support for async/await a considerable time now.
class directive is actually supported, and not transpiled into code that is much harder to step through and isn't nearly as performant as just letting the engine do the work for us. This will allow your code to target even more modern features like the new Nullish Coalescing operator, or the Optional Chaining. You can see a full feature list of JavaScript features that NativeScript engines support here.
Advanced tree shaking along with the simplicity of single barrel symbol management. With 7.0, everything is available simply from @nativescript/core.
https://webpack.js.org/guides/tree-shaking/
The webpack 2 release came with built-in support for ES2015 modules (alias harmony modules) as well as unused module export detection. The new webpack 4 release expands on this capability with a way to provide hints to the compiler via the "sideEffects" package.json property to denote which files in your project are "pure" and therefore safe to prune if unused.
We will be sharing some deeper analysis on tree shaking in a post soon.
Improved clarity to compiled code.
Improved project maintenance by streamlining NativeScript symbol management allowing for deeper under hood refactorings to occur without having to deal with breaking import path changes in the future. This also allows for improved code migration scripts to be introduced if in fact a breaking change is introduced in the future to core symbols.
