ServiceStack SharpScript 未来

Posted 2023-02-19

【中文标题】ServiceStack SharpScript 未来

【英文标题】：ServiceStack SharpScript Future

【发布时间】：2021-11-05 19:40:23

【问题描述】：

美好的一天，我已经使用 ServiceStack 很多年了，我目前正在设计和计划一个 ASP MVC (Razor) 项目的重写。 #Script 似乎是一个几乎完美的契合，如果没有对技术的实际经验，我有一些疑问和问题。

我的问题是今天#Script 的相关性以及这项技术的未来计划是什么。我问这些问题是因为当我查看 GitHub 示例时，我注意到没有很多活动，并且在互联网上搜索我也找不到围绕它的社区。​​p>

【参考方案1】：

作为#Script 的作者，我想说#Script 是一个完整的库，它的设计目的是作为embeddable sandboxed .NET 脚本和模板语言，非常适合exploratory programming 和seamless integration into .NET APIs（包括@ 987654325@) 包括一个庞大的 filters 内置库 (1000+)，它可以轻松且高度可扩展，甚至可以在同一页面内原生支持 multiple languages (inc. built-in LISP Repl)得益于其内置的 Hot Reloading 支持，在保存时可以立即看到更改，因此开发过程很愉快 - 因此在技术方面 IMO 非常棒。

如果我们将它与其他语言（如 Ruby's Liquid）中的可比较库进行比较，则应该很明显，#Script 在从用户友好的模板语言扩展到强大的脚本语言时，它的功能要强大得多。能够开发整个Windows Desktop Apps that fits in a Gist。

在活动方面，Liquid 也是一个已建立的低活动库，只有一个 handful of commits in 2021，不同之处在于它是 vastly more popular 并用于 Jekyll 等流行产品中，就像在 GitHub Pages 中使用的那样，这确保了它将始终拥有一个丰富、充满活力的生态系统，这是评估技术寿命的最重要指标。

技术不如生态系统重要

但最终，这项技术并不像它背后的用户群、社区和生态系统那么重要，而这正是#Script 严重缺乏的地方。不幸的是，与 Microsoft 的默认设置（如 Razor）竞争的库就是这样的现实，这些库专门针对 .NET 进行推广，并且将始终在 .NET 中保持大部分采用。

#Script 是一个“完整”的库，因为我已经添加了我为它计划的所有功能，基本上我想不出任何东西可以添加到它以使其更具吸引力，但面临着无限期的实现缺乏采用我不建议将它用于大型生活（即多年）网站，因为它永远不会拥有其他生态系统所享有的社区和采用，因为社区和生态系统的好处最终是最重要的属性继续投资于一项技术。

继续得到积极支持

与所有ServiceStack 一样，#Script 仍然是一个受到no outstanding issues 积极支持的库，因此使用起来很安全，如果您愿意，任何问题都会得到及时解决。

网站开发建议

我会说它仍然是小型确定范围项目的好选择，因为它的无编译时间和热重载为服务器生成的动态页面提供了非常高效的 Dev UX。然而即便如此，我还是会首先评估像Jekyll、Hugo 或其他popular static generators 这样的静态生成框架是否更合适，因为他们喜欢充满活力的社区，并且静态生成的网站会产生更高的性能、弹性和更便宜托管和部署网站。

静态站点生成器

最近重新开发了servicestack.net 网站，将其拆分为使用 Jekyll 用于静态内容和ServiceStack.Razor 用于动态内容，my recommendation for large websites 具有大型静态和动态组件是使用静态站点生成器来生成其静态内容产生几个好处：

虽然在设置时确实需要相当多的开销，因为您正在有效地维护 2 个不同的网站，但是如果静态内容被积极更新，它会大大受益，因为在静态生成的网站上更改和更新内容的摩擦要小得多然后是动态的，它可以带来出色的最终用户 UX，这要归功于 CDN Edge 缓存，从 GitHub Pages 和 Netlify 等免费网站托管也更便宜。

为了保留现有 URL，我们需要静态主机无法提供的额外功能，因此我们的静态内容部署到 S3 存储桶，我们使用 CloudFront 进行 CDN 边缘缓存，CF 行为代理“外部静态”路由到我们的 @ 987654347@ 和一个支持漂亮 URL 的 CF 函数。对于内部部署的网站，您将能够使用反向代理和重定向规则完成类似的功能。

SPA 或剃须刀

对于不会从内容站点拆分中受益的小型网站或大部分动态网站，如果您更喜欢 TypeScript，我建议您使用 SPA Project Template 和已建立的 SPA FX，例如 Vue、React、Svelte 或 @ 987654352@ 或 Razor or MVC 如果您更喜欢 C# 服务器生成的网站。

渐进式增强

我个人的偏好是读取繁重的动态站点使用 ServiceStack Razor，利用 API First Development 方法，以便所有写入都对移动和桌面应用程序也会调用的相同的干净 ServiceStack API 进行。这通常涉及使用某种渐进增强，例如我们的 Client TypeScript 验证示例，它利用 Form & Validation Binding in @servicestack/client 接管 <form> 提交来执行 TypeScript API 调用并将任何验证错误应用回表单的 UI。

Client jQuery 示例在没有 tsc -w 监视的构建步骤的情况下完成相同的事情，其 form & validation binding 使用较旧的 jQuery ss-utils.js library 但这确实意味着您需要在较旧的广泛支持的 ECMAScript 5 中编写逻辑JS 版本。

#Script的未来

由于我不认为 #Script Pages 会实现自我维持的主动开发所需的任何有意义的采用，因此我们不太可能继续投资于进一步开发以用于动态网站（即 script 项目模板)，它是一个完整且可扩展的库，因此不需要进一步开发，因为它可以使用您自己的本地插件、方法、转换器和块轻松扩展。但这确实意味着我们不太可能在库 OOB 中创建和包含为动态网站设计的新方法/插件。

仍然是一个关键的 ServiceStack 组件

#Script 仍然是 ServiceStack 的关键组件，它用于提供集成的 SPA 模板，因为它能够从无法使用 Razor 的 *.cshtml 页面的 npm dev 热重载服务器中的静态 *.html 页面呈现动态网站.这也是使 ServiceStack 的Declarative Validation 成为可能的原因，其中可以在无依赖 DTO 上定义验证规则，因为它允许在无依赖属性中定义二进制解耦逻辑。这也是使 vuedesktop.com 像 ServiceStack Studio 这样的桌面应用程序以及像 Post Command - HTTP API Command Line Utils 和 cross-platform dotnet scripts 这样使用其内部功能的命令工具成为可能的原因，因此它将继续作为积极开发和支持的工具图书馆。

#Script 未来的好用例

但是，我会将任何#Script 的使用限制在它擅长的地方，例如作为一个可嵌入的脚本 .NET 沙箱，因为它比 Razor 更通用和灵活，用于Rendering Emails、创作和渲染Live Documents（例如，如果需要在 RDBMS 中维护实时用户生成的报告）或作为可嵌入模板、JS或 LISP DSL 或用于评估 adhoc JS/LISP Expressions or .NET logic。

未来替换项目模板

为了使用 ServiceStack 开发服务器生成的网站，我们正在考虑提供几个新模板，其中包含我们最新的建议（例如，采用 API 优先开发风格），如果它们能够带来我们正在关注的出色开发 UX ：

生成的集成静态（例如 Hugo/Jekyll）+ 动态项目模板 具有集成渐进增强功能的 API First MVC Pages + ServiceStack 模板

请关注@ServiceStack，以便在它们可用时尽快得到通知。

【讨论】：

感谢您的全面回答。我的应用程序是一个业务应用程序，基本上是一个流程系统（用于仓库），您有一个包含 x 个步骤的流程，每个步骤执行一个 API 调用，但是有很多选项，例如，必需、静默步骤、执行 SQL 存储过程，可以返回html。它基本上是一种带有输入框的通用表单，每个控制器/视图输出一些基本的 html（部分视图）。它是 C# 密集型的，但 UI 非常纤细，它是 SQL 密集型的，因为它允许人们使用存储过程配置一个步骤。