|
|
|
|
|
|
by Someone1234
2824 days ago
|
|
|
> It's funny because the article says the exact opposite of these things. It what now? > In addition, the API is designed with TypeScript type inference in mind. The 3.x codebase will itself be written in TypeScript, and providing improved TypeScript support. (That said, usage of TypeScript in an application is still entirely optional.) And: > Top level APIs will likely receive an overhaul to avoid globally mutating the Vue runtime when installing plugins. Instead, plugins will be applied and scoped to a component tree. And: > We are breaking some internal functionalities into individual packages in order to isolate the scope of complexity. For example, the observer module will become its own package, with its own public API and tests. [...] Decoupling the observer and scheduler into separate packages And: > The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support. Most of the ES2015 features used can be transpiled / polyfilled for IE11 The above is exactly what I referred to and all taken verbatim from the article. It is Angular 2.x+ all over again. |
|
|
If I got that right, they plan a first-class TypeScript interface, and a second class Javascript one compiled from it. You choose whatever you want.
Their problem is that you can not derive a good TypeScript interface from Javascript. But there is no problem on doing the reverse. None of that implies in any development-time or runtime requirement.
> Top level APIs will likely receive an overhaul to avoid globally mutating the Vue runtime when installing plugins.
That is a breaking change, yes. But not a large one.
> We are breaking some internal functionalities into individual packages
That is clearly not a breaking change.
> The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support.
That one implies on development-time requirements. They still can remove that requirement from the JS compiled distribution.