3

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

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

4

1 回答 1

4

作为#Script的作者，我会说这#Script是一个完整的库，它的设计目的是作为一种可嵌入的沙盒.NET 脚本和模板语言，非常适合探索性编程与.NET API （包括Win32 API ）的无缝集成，其中包括大量内置过滤器库（1000+），易于扩展，甚至可以在同一页面内原生支持多种语言（包括内置 LISP Repl），这得益于其内置热重载支持在保存时立即看到更改 - 所以技术方面的 IMO 它非常棒。

如果我们将它与其他语言（如Ruby 的 Liquid）中的可比库进行比较，那么它应该非常清楚，#Script它从用户友好的模板语言扩展到能够开发整个Windows 桌面应用程序的强大脚本语言的能力要大得多符合 Gist。

在活动方面，Liquid 也是一个成熟的库，在 2021 年只有少量提交，活动量很少，不同之处在于它更受欢迎，并在GitHub Pages中使用的Jekyll等流行产品中使用，这确保它总是有一个丰富、充满活力的生态系统，这是评估技术寿命的最重要指标。

技术不如生态系统重要

然而，最终该技术并不像它背后的用户群、社区和生态系统那么重要，而这正是其#Script严重缺乏的地方。不幸的是，这是与 Microsoft 的默认值竞争的库的现实，例如 Razor，它们专门为 .NET 推广，并且将始终保留在 .NET 中的大部分采用。

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

继续得到积极支持

像所有的ServiceStack一样，#Script它仍然是一个积极支持的库，没有未解决的问题，因此可以安全使用，如果您愿意，任何问题都会得到及时解决。

网站开发建议

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

静态站点生成器

最近重新开发了servicestack.net网站，将其拆分为使用 Jekyll 处理静态内容和使用ServiceStack.Razor处理动态内容，对于具有大型静态和动态组件的大型网站，我建议使用静态站点生成器来生成静态内容，从而产生几个好处：

在此处输入图像描述

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

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

SPA 或剃须刀

对于不会从内容站点拆分中受益的小型网站或大多数动态网站，如果您更喜欢 TypeScript，我建议您使用SPA 项目模板；如果您更喜欢 C# ，建议使用已建立的 SPA FX，例如Vue、React、Svelte或Angular或Razor 或 MVC服务器生成的网站。

渐进增强

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

客户端 jQuery示例在没有tsc -w监视构建步骤的情况下完成了同样的事情，其表单和验证绑定利用了旧的 jQuery ss-utils.js 库，但这确实意味着您需要在更旧的广泛支持ECMAScript 5的 JS 版本中编写逻辑。

的未来#Script

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

仍然是一个关键的 ServiceStack 组件

#Script 仍然是 ServiceStack 的关键组件，它用于提供集成的 SPA 模板，因为它能够从*.html不能使用 Razor 页面的 npm dev 热重载服务器中的静态页面呈现动态网站*.cshtml。这也是使 ServiceStack 的声明式验证成为可能的原因，其中验证规则可以在无依赖 DTO 上定义，因为它允许在无依赖属性中定义二进制解耦逻辑。这也是使vuedesktop.com桌面应用（如ServiceStack Studio）以及命令工具（如 Post Command - HTTP API 命令行实用程序和跨平台 dotnet 脚本）成为可能的原因它利用了它的内部功能，因此它将继续作为一个积极开发和支持的库。

良好的未来用例#Script

但是，我会将任何#Script 的使用限制在它擅长的地方，例如，作为一个可嵌入的脚本 .NET 沙箱，因为它比 Razor 更通用和灵活，用于渲染电子邮件、创作和渲染实时文档等任务（例如，如果需要维护实时用户-在 RDBMS 中生成报告）或作为可嵌入模板、JS 或 LISP DSL 或用于评估即席JS/LISP 表达式或 .NET 逻辑。

未来替换项目模板

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

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

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

于 2021-09-09T10:04:18.690 回答