By type checking I mean something like typescript which is able to statically verify whether the right types of attributes are passed to the right component, or whether expressions embedded in the template are of the right type.
Re encapsulation, the way that JS provides it is scope. JavaScript's lexical scope ensures that things you define in a function are only visible in that function, or that things you define in an ES6 module are only visible in that module. Even with the tiny quirks of function based lexical scope, its natural and intuitive: if you can see the definition (or import) in the (function/module) parent(s) of the code you're looking at, its available. Its a tried and true solution.
Template languages don't always bother to add something like "import" or the concept of lexical scope, so when you want to share something from JS (or other templates) with them (like data, or processing functions, or components) you need to somehow put it in their own custom scope. Many template based frameworks make the mistake of working around this not by adding import mechanisms to the template language, but by registering things globally - e.g. when you register a component in Angular or Vue it becomes globally available. This has the same problem any other global variables have. (I suspect this in Angular 1 is what led to the totally parallel "module system" with dependency injection, although maybe they just didn't like the existing ones)
Regarding supporting first class components in template languages, its not really that difficult. Its just that we believe the fallacy that we need the template language to be underpowered. Also, once you add support for first class components and JS scope sharing (or at least import/export) mechanisms to a template language, you've basically reinvented JSX (perhaps with a different syntax)
Sandboxing isn't harmful, its just extremely hard. Angular spent years trying to write a proper expression sandbox and every new version of it was broken successfully - thats why 1.6 removed the sandbox.
What I'm hoping for is that someone works out what contributes the most to popular framework's size, takes the common parts and provides them as built in API in the browser in such a way that the frameworks can take advantage of that instead of writing their own implementations.
Re encapsulation, the way that JS provides it is scope. JavaScript's lexical scope ensures that things you define in a function are only visible in that function, or that things you define in an ES6 module are only visible in that module. Even with the tiny quirks of function based lexical scope, its natural and intuitive: if you can see the definition (or import) in the (function/module) parent(s) of the code you're looking at, its available. Its a tried and true solution.
Template languages don't always bother to add something like "import" or the concept of lexical scope, so when you want to share something from JS (or other templates) with them (like data, or processing functions, or components) you need to somehow put it in their own custom scope. Many template based frameworks make the mistake of working around this not by adding import mechanisms to the template language, but by registering things globally - e.g. when you register a component in Angular or Vue it becomes globally available. This has the same problem any other global variables have. (I suspect this in Angular 1 is what led to the totally parallel "module system" with dependency injection, although maybe they just didn't like the existing ones)
Regarding supporting first class components in template languages, its not really that difficult. Its just that we believe the fallacy that we need the template language to be underpowered. Also, once you add support for first class components and JS scope sharing (or at least import/export) mechanisms to a template language, you've basically reinvented JSX (perhaps with a different syntax)
Sandboxing isn't harmful, its just extremely hard. Angular spent years trying to write a proper expression sandbox and every new version of it was broken successfully - thats why 1.6 removed the sandbox.
What I'm hoping for is that someone works out what contributes the most to popular framework's size, takes the common parts and provides them as built in API in the browser in such a way that the frameworks can take advantage of that instead of writing their own implementations.