您可能已经在 Rob Lauer 的推文中看到过（如下），几周前我们聚在一起，集思广益，探讨 NativeScript 在 2019 年的发展方向。我们与团队经理、优秀的 DevRel 倡导者以及特邀嘉宾 👉 Eddy Verbruggen 和 Igor Randjelovic 进行了一天的会议！
.@NativeScript in 2019 ladies and gentlemen!#Vuejs #Angular #BeyondMobile pic.twitter.com/vZiNOjgCkZ
— Rob Lauer (@RobLauer) 2018 年 11 月 15 日
我不会详细介绍当天的结构和组织方式，而是更愿意关注结果以及我们对框架在接下来一年的演变的看法。
我想指出的一点是，一切还没有确定下来——我们欢迎来自您（我们的社区）的任何反馈！
那么，让我们开始吧！
Nativescript-Vue 在 2018 年获得了快速发展，我们将继续支持 Igor 和所有贡献者。核心团队将特别关注 NativeScript UI 插件对 Vue 的支持，并确保消除 Vue.js 集成中的任何障碍。当前插件作者可以做些什么来加强对 Vue.js 的支持？那就是审查他们的插件，并确保它们与 NativeScript-Vue 兼容。有关更多详细信息，请查看 {N} 和 {N}-Vue 的下一个版本。
这一切都为 NativeScript-Vue 在 2019 年初成为 NativeScript 核心框架的一部分提供了一条途径！
团队将继续致力于使用 HMR 和 Webpack 改善开发体验，目标是让 Webpack 成为使用 NativeScript 的**唯一方式**。不用担心，这会逐步进行。
tns run 无需提供 --bundle 标志。我们已经证明，使用 Webpack 开发可以实现 HMR，在开发过程中提供更快的构建时间，并在启动时间方面优化应用程序，因此我们认为应该让所有用户都能够开箱即用地使用这种功能，而无需使用不同的选项，例如 --bundle 或 --hmr。我们相信这将让所有 {N} 爱好者受益匪浅。
根据 NativeScript 调查结果，"不明确的错误消息"被认为是开发 NativeScript 应用程序时的首要问题，因此，我们将审查当前的错误处理机制，并改进 CLI 中错误的呈现方式。
此外，我们将在**智能感知**和**稳定性**方面更加关注 当前的 VS Code 扩展，并将其作为开发过程中的首选工具。
我们在 2018 年引入了 Angular 的代码共享功能，我们致力于继续发展这种选项，同时提供所有必要的工具，以实现更高比例的代码共享。我们的目标是让您能够共享比现在更多的代码，并通过提供的工具以简单、自动的方式完成。
我们将投入时间来**构建更好的入门模板**，该模板将允许您
我们还将制定一个**样式指南**，该指南将提供有关以下方面的强有力建议：
NativeScript 和 Vue.js 的全面代码共享故事也将在 2019 年出现！
为什么在 Web 和移动设备之间**共享**代码，当我们可以直接在 Web 上**使用**相同的代码时呢？
这就是我们提出的一个**非常实验性**的想法——nativescript-web 背后的理念。其理念实际上是从您现有的 NativeScript 应用程序生成 100% 的 Web 代码（特别是 PWA）。这将实现所有平台之间的 100% 代码共享，甚至可以通过 Electron 为 macOS、Windows 和 Linux 桌面提供支持！
请记住，到目前为止，这是我们路线图中最具实验性且定义最不明确的功能！我们必须看看 🎁 2019 年会带来什么...
目前，可以使用 分析 和 Crashlytics，但没有太多关于此主题的文档或内容。我们也意识到，记录的错误并不总是很有用且足够清晰。首先，团队将重点放在提供有意义的本机堆栈，而不是内存指针和行号。
我们将改进的第二个领域是将 JavaScript 代码中的错误公开给错误报告服务——这些错误通常包含应用程序的业务逻辑，而目前这些错误完全被隐藏。错误虽然不是崩溃，但对于应用程序的健康运行仍然很重要。它们也需要出现在您的仪表板中！此外，我们将更好地记录与现有分析和 Crashlytics 服务的集成。
团队将投入时间来启用过去一年中一些**最受欢迎的 CSS 属性**。我们很快将在 GitHub 上开启讨论，以确定要从哪些属性开始。由于可能有许多 CSS 属性会被启用，因此我们将**欢迎社区提供任何帮助**！
我们也知道，大多数人都拥有 Web 经验，并且喜欢使用 Chrome Dev Tools，因此我们也将添加对**Chrome Dev Tools CSS 检查**的支持。
最后但并非最不重要的一点是，我们将与社区合作，让**Material Design** 的功能发挥到极致。
我们将投资于改进**入门体验**，提供更多示例、改进的文档内容以及在环境设置过程中提供更好的错误消息。
我们还意识到，框架当前提供的**单元测试**方法存在一些 问题，因此，我们将努力对其进行稳定。
**性能**是一个可以不断改进的方面，也是一项永无止境的任务。我们预计，前面提到的所有 Webpack 集成和优化将有助于提高应用程序启动时间和应用程序内体验的性能。
很高兴您问到这个问题！
👀 您是否已经找到了上面提到的某个方面，您已经取得了一些进展，或者只是想与团队合作并进行 PR？只需 发布一个 GitHub 问题 与我们联系，并讨论您未来的贡献。
🎉 您是否创建了很酷的选项卡栏、操作栏或其他引人注目的 UI？请通过 与我们分享您的成果，我们将将其添加到 NativeScript 示例 中！
📊 您是否已经集成了分析服务和/或 Crashlytics？您的应用程序中有大量的单元测试吗？请在**博客文章**中分享您的经验，并告知我们！
📢 在您的本地地区**宣传** NativeScript。
📝 开箱即用地**100% 访问本机 API** 为集成和使用框架提供了无限的机会。请撰写博客文章，分享您使用 NativeScript 的经验（联系 Rob Lauer，我们将将其发布在 NativeScript 博客上！）。
🔌 通过 构建插件 或一个漂亮的 示例应用程序 为生态系统做出贡献。
💡 在 Github 上发布并回答问题！
👫 在 NativeScript 社区 Slack 或 Stack Overflow 中帮助社区成员。
🎲 想做出贡献，但不知道从哪里开始？挑战自己，选择任何一个 适合初学者的问题 来尝试一下，按照相应仓库的 贡献指南 来设置您的开发环境，并找到有关如何进行拉取请求的说明。
📚 改进 文档！
🎨 您是否使用 {N} 创建了一个外观精美的应用程序？请展示您的作品，并将其 提交 到我们的 展示案例 中。
这是我们工程团队、DevRel 团队以及社区（包括**您**）共同努力的结果。这是一个切实可行且雄心勃勃的计划，它将使 NativeScript 变得更加出色！
祝您 NativeScript 开发愉快，并祝愿🎆 2019 年比 2018 年更加成功！