Blitz.js宣言（一个全新的全栈React框架）
AWS 安全直播！
Blitz.js是一个全新的 Javascript 框架，用于构建单体式、全栈式、无服务器 React 应用，无需数据获取，也无需客户端状态管理。
背景
技术的发展遵循着打包与解包的循环往复。Ruby on Rails 诞生于 2005 年，它迅速成为一股强大的打包力量，使 Web 应用开发比以往任何时候都更加便捷易用。这惠及了所有人，从编程初学者到构建生产系统的资深人士。
2013 年 React 的发布带来了一次重大的解耦。React 是一个高度专注于渲染的层，它对样式、状态管理和路由等问题没有任何预设。随着 React 的流行，其他所有组件的选择也随之增多，导致开发者在创建新应用时需要做出数百个决定。虽然这加剧了 JavaScript 疲劳，但也成为推动前端快速创新的强大动力。
如今，2020 年正是推出另一项重大软件包的绝佳时机。开发者们渴望一种更轻松、更简便的方式来构建 Web 应用程序。初学者需要有人指导他们构建一个强大的应用程序，而资深开发者则需要一个框架，该框架能够消除繁琐的任务，同时提供高度可扩展的架构以及所有必要的安全机制。
因此，闪电战应运而生。
闪电战是做什么用的？
Blitz 适用于构建从小到大的数据库驱动型 Web 应用程序（未来还将支持移动应用程序）。它不适用于构建像 Facebook.com 那样的超大型 Web 应用程序。它也不适合构建内容网站，尽管您可以轻松地向 Blitz 应用添加完全静态的页面，这样您的营销网站就不需要单独的托管服务了。
基本原则
- 全栈和单体架构
- 后端 API 可选
- 约定优于配置
- 随意的观点
- 易于上手，易于扩展
- 稳定
- 社区超越代码
1. 全栈式架构和单体架构
全栈单体应用比前后端分别开发和部署的应用更简单。单体架构并不意味着运行缓慢或难以扩展到大型团队。单体架构也不意味着缺乏关注点分离。单体架构意味着你可以将应用视为一个整体来思考。
2. 后端 API（可选）
选择 React 作为视图层并不意味着你必须构建后端 API。通常情况下，你只需要一个 API 来获取前端数据，除非你需要一个面向第三方或移动应用的公共 API。构建和维护一个仅供前端使用的 API 成本极高，因为它会增加许多不必要的复杂性，导致开发速度变慢、维护难度增加、部署更加复杂。
在 Blitz 应用中，你需要为所有 CRUD 操作编写服务器端控制器。这些控制器可以直接访问数据库。你只需将它们连接到需要数据的页面，Blitz 就会自动安全地将数据从后端控制器传递到前端组件。你无需进行任何客户端数据获取调用、处理全局状态管理或进行客户端数据缓存。变更操作的工作方式也类似。
Blitz 应用的开发方式类似于传统的服务器渲染框架（如 Rails），但最终用户体验是 React 单页应用。
如果将来确实需要 API，您可以轻松添加带有自动生成解析器的 GraphQL API。或者，如果您更喜欢 REST，也可以将其添加到您的 Blitz 应用中。
3. 约定优于配置
在开始开发一个新应用时，你应该能够立即开始开发核心应用功能，而不是花费数天时间来配置 eslint、prettier、husky git hooks、jest、cypress、typescript，确定文件结构，设置数据库，添加身份验证和授权，设置路由器，定义路由约定，设置样式库，以及所有其他初始应用设置的琐碎任务。
Blitz 会尽可能多地为您做出决策并完成工作，让您能够以闪电般的速度启动真正的开发。这也极大地惠及了社区。通用的项目结构和架构模式让您可以轻松地从一个 Blitz 应用迁移到另一个 Blitz 应用，并立即上手使用。
约定优于配置并不意味着完全不需要配置，而是意味着配置是可选的。Blitz 将提供您所需的所有扩展功能和配置选项，以实现个性化定制。
4. 不成熟的观点
Blitz 有其自身的设计理念。其开箱即用的默认设置引导您走上一条适合大多数应用场景的道路。然而，Blitz 并不傲慢。它完全理解偏离常规的做法有其充分的理由，并允许您轻松地做到这一点。例如，Blitz 拥有一个标准的文件结构，但除了少数例外情况外，它并不强制执行该结构。
当 React 社区对某件事没有达成共识时，blitz new它会提示你选择你想要的方法，例如 Tailwind CSS、Theme UI 或 styled-components。
5. 易于上手，易于扩展
一个框架如果只在应用程序生命周期的某个阶段容易使用，那就不是一个好的框架。启动和扩展都必须容易。
易于上手包括对初学者友好，以及易于将现有的 Next.js 应用迁移到 Blitz。
扩展性在各个方面都很重要：代码行数、参与代码库开发的人员数量以及生产环境中的代码执行。
6. 稳定性
在瞬息万变的 JavaScript 世界里，稳定且可预测的发布周期犹如一股清流。稳定的发布周期能最大限度地减少破坏性变更，并确保你确切地知道何时会发生哪些破坏性变更。它还能通过确保功能在 beta 阶段停留的时间最短，从而最大限度地减少稳定版本中的 bug。在这方面，Ember 堪称典范。
Blitz 版本发布周期的具体细节尚待确定，但我们将遵循与 Ember 类似的模式，严格遵循 SemVer 规范，每 6 周发布一个稳定版本，每 6 个月发布一个 LTS 版本。
Blitz 将遵循公开的 RFC（征求意见）流程，以便所有用户和公司都能参与提出和评估新功能。
如果需要移除某个 Blitz API，我们会在次要版本中将其弃用。主要版本只会移除之前版本中已经弃用的 API。
7. 社区高于代码
闪电战社区是整个框架中最重要的组成部分，没有之一。
我们制定了一套全面的行为准则。我们尤其欢迎 LGBTQ+ 群体、女性和少数族裔加入。
我们同舟共济，无论老幼。我们之间的共同点远多于差异。我们能够也应该携手解决问题。我们应该向其他社区学习，而不是与他们竞争。
现接受赞助和捐款
资金将用于弥补我的咨询收入损失，这样我就可以投入更多精力开发 Blitz，并尽快使其达到上线状态（可能在第二季度末）。如果资金充足，我们也会支持其他贡献者！
这是让您的企业接触早期用户的绝佳机会！
文章来源：https://dev.to/flybayer/the-blitz-js-manifesto-a-new-react-framework-1gg7