迈向更好的GUI编程基准

GUI 编程 具有挑战性 。 我们努力寻找更好的GUI编程方法，并且确实取得了进步。 存在无数具有不同方式来开发GUI的GUI工具包的事实表明，未来的路还很长。 如果有一个基准可以将GUI程序相互比较。 然后，找出好的想法将变得容易得多。

在本文中，我介绍了7GUI：GUI编程基准 。 我对此进行了思考，并通过思考更好的GUI编程基准如何表现出来来展望下半年的未来。

回顾7GUI

7GUI是我创建GUI编程基准的尝试。 在传统的基准测试中，将竞争实现的资源消耗进行比较。 在7GUI中，根据符号对实现进行比较。

为此，7GUI定义了七个任务 ，这些任务代表着GUI编程（ 实时版本 ）中的典型挑战。 已经有很多实现 ， 您的实现可能就是其中之一。 此外，7GUI提供了一组建议的评估维度 。

该项目被认为是2014年以来我硕士论文的副产品。从那时起，GUI编程领域一直在发展。 四年后，我回头看看。

最近更新

长期以来，我对GitHub项目的结构不满意。 我也不擅长回应请求。 尽管如此，人们仍在为存储库添加书签并添加实现。 非常感谢所有贡献者！

然后，我的论文导师给我发送了一封电子邮件，询问他是否可以协助提出请求。 总的来说，这导致我决定改进该项目。 目标 ：使其表示和所有权更清晰，并减少我这一边的维护工作。

现在，没有专用的网站，而没有使用GitHub Wiki作为文档。 存储库（大部分）包含指向实现的链接，但不再包含实现本身的链接。 另一个补充是React / MobX中7GUI任务的实时版本 ，因此您可以在浏览器中方便地使用生成的GUI。

我对一切的结果感到满意，但要判断目标是否实现还为时过早。 无论如何，我很乐意提供反馈！

呼吁捐款

我希望看到更多有帮助的实现。

例如，我的Elm实施过时且不完整。 您是否不想展示Elm如何处理7GUIs任务？ 那么在流行的SPA框架（如React，Ember，Angular或Vue）中的实现又如何呢？

我认为您将无法创建比我的React / MobX版本更好的实现。 证明我是错的！

影响力

当我回顾该项目时，我想知道：

7GUI是否达到了为框架设计人员和GUI实现者提高GUI编程方法可比性的目标？

在某种程度上可以肯定。 但是，很难给出确切的答案。 我收到的大量实现，论坛讨论和一些电子邮件表明7GUI迫在眉睫。

但是，据我所知，尚未创建任何书面比较。 根据经验，我知道编写比较是多么困难。 或者，根本就没有分析的需求。 也许这就是全部。 另一方面，我相信基准的某些方面可以做得不同，以引起更多的比较（请参阅本文的其余部分）。

总而言之，尽管缺少明显的比较，但7GUI似乎仍然有用，但是拥有它们会更好，并且有可能使它们更有可能。

缺点

在7GUI诞生之后的四年中，我在构建GUI方面获得了更多的经验。 我注意到7GUI并未涵盖一些重要的GUI编程挑战。

7GUI更加关注传统的桌面应用程序。 不管喜欢与否，现在比以往任何时候都最重要的向用户提供GUI的平台是浏览器和互连的Web。

此外，我研究了类似的项目，例如TodoMVC和HNPWA，并试图确定哪些方面使它们成功。

需要明确说明的是：我坚信7GUI仍然有用 。

尽管如此，我也认为有可能建立更好的基准。 我的反思结果将在下一部分中介绍。

迈向更好的基准

如果我今天创建了GUI编程基准，那么与7GUI有什么不同？

挑战性

正如引言中所暗示的那样，7GUI并未涵盖我作为软件工程师的专业经验中所观察到的所有相关挑战。 我只列出挑战，而没有更深层次的解释，我认为值得在更完整的基准中解决。 请注意，这既不是完整的集合也不是必需的集合，而是假设的新基准的良好起点：

• 处理不稳定的远程API。 不仅读取，而且还进行变异操作（例如POST请求）。 这意味着要处理加载和错误情况，缓存和处理竞争条件。
• 以一种聪明的方式处理加载。 例如，仅在一定时间后才显示加载指示器。 在最短的时间内显示它以防止闪烁。 如果先前已获取，则在加载期间显示部分数据。
• 乐观更新
• 预取
• 变化传播
• 呈现可过滤或可搜索的大型项目列表，可远程获取结果
• 撤销重做。 可能与远程同步一起使用。
• 屏幕之间的导航/路由。 防止导航（例如未保存的更改）
• 标签内容
• 模态。 可能会通过向导完成多个步骤：对话框控件
• 分页或无限加载
• 自适应/响应式布局
• 约束（表格）
• 通知/敬酒。 可能由远程事件或计划任务触发。
• 状态还原
• 离线支持
• 相同数据的两个替代视图
• Rx通常可能适合的某些功能：对过去事件的操作，协调多个相互依赖的请求。

您可能已经注意到，许多挑战涉及与远程API的通信。 世界之间的联系日益紧密，这在当今构建和使用的应用程序中得到了体现。 一个好的基准应该考虑到这一点。

人工性

对于7GUI，我有意识地决定要有一系列隔离的任务。 这种方法的副作用是增加了人工性。 就其本身而言，这不是一件坏事，但这是一个权衡。

通过关注每个任务的一些挑战，可以更轻松地了解如何解决它们。 同样，比较解决方案应该更容易。 如上所述，问题是这是否重要。 虚假性的缺点是，可能会遗漏挑战或方法之间的可能相互作用。

但是最大的缺点是编写一个“真实的”应用程序只会更加有趣 。 如果您创造了一些东西，同时又解决了相当抽象的挑战，那么您可以实际使用它们并在实践中使用它，那么您会更加投入其中。 最终，任务越参与越多，更多的人会花更多的精力在任务上，这导致思想交流更多—至少这是我的印象。

具体来说，电影浏览/查看应用程序非常适合。 绘制所有相关挑战通常是足够的，而要有趣则足够真实。

需要的努力

如果基准太小，就无法涵盖足够的有趣挑战。 它还可能鼓励非常专业的解决方案。 如果基准太大，则完成基准所需的工作可能会阻碍某人编写实现。

现在，我最近在React / MobX中重新实现了7GUI，我注意到它感觉太大了。 尤其是“圆形抽屉”和“单元”任务可能是他们自己的基准。

原始形式的TodoMVC感觉太小了。 另一方面，HNPWA感觉太大了。 但是，如果基准测试涉及创建非人工应用程序，那么我相信开发过程中增加的乐趣会抵消需要付出的更大努力。

因此，对我而言，理想的基准将位于TodoMVC和HNPWA之间，但更接近HNPWA。

标准的特异性

接受标准应该有多具体？

过于具体，您可能会偏向某些解决方案。 这也将减少乐趣，因为您希望能够在实现中“打上自己的烙印”。 太宽容，您将很难比较缺少基准测试点的实现。

总的来说，我认为您应该从非常具体的事情开始，一旦人们开始抱怨某些阻止良好方法的标准，就放松他们。 随着时间的流逝，您应该达到一套良好的接受标准。

衡量实施

当涉及到一套将实现之间进行比较的标准时，我仍然是符号的认知维度（CDs）框架的拥护者 ，该框架是“一种分析信息伪像可用性的方法”。

但是，我承认其介绍是干的。 我试图使它对于7GUI 更易于理解，但是我觉得尺寸仍然很难在实践中应用。

在我看来，为每个维度提供具体的小型JavaScript代码段会有所帮助。 一个好的和不太好的JavaScript版本，可以解决一个小问题。 然后简短解释为什么根据所讨论的维度，好的版本比不好的版本更好。

总体而言，以非主观，简单和有用的方式来衡量实现的源代码是一个难题，因此，我想在这里看到更多的想法。

邀请捐款

我注意到，对7GUI的一些贡献并没有给它们的展示带来太大的价值。 完全没问题，因为这不是必需的。 但是，更高的需求贡献实际上可以导致更多的贡献。

这样做的想法是使它被列为一份贡献。 反过来，这应该会使您的贡献更具吸引力。 另外，将实现相互比较也将变得更加容易。

有关要求的一些具体想法：明确说明如何运行项目，截图，完整实现，易于浏览您的源代码（例如，将其托管在GitHub上），提供描述您的优点/特色的文章/文档实施，请其他人担保您的贡献，由陪审团判断您的贡献（“同行评审”）。 在宽大和严格之间很难找到一个很好的平衡，但是严格一点可能最终可以锻炼得更好。

应该明确的是，您必须具有高质量的参考实现：以身作则！

线程

在研究期间，我最近偶然发现Threadit.js 。 我粗略浏览了一下，这个基准似乎朝着正确的方向发展。

这是一个“真实”的应用程序。 它提供了一个不稳定的远程API，因此强制实现处理错误和加载状态。 它提供了实用程序代码，因此您可以专注于核心挑战。 它是基于网络的。

Threadit.js有很多好主意，至少可以作为起点。 不幸的是，在线网站http://threaditjs.com/关闭。

结论

TodoMVC，HNPWA和7GUIs等项目表明对GUI编程基准有需求。 7GUIs有用，但也有缺点。 ThreadIt.js通常接近我认为是更好基准测试的正确方向。 我不会成为推动这样一个项目的人。 在本文中，我仅设想了一个更好的基准。 不过，我坚信结果会产生影响，因此我愿意支持建立基准。 你有什么想法？

From: https://hackernoon.com/towards-a-better-gui-programming-benchmark-397aca3542b8

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！