GUI 编程 具有挑战性 。 我们努力寻找更好的GUI编程方法,并且确实取得了进步。 存在无数具有不同方式来开发GUI的GUI工具包的事实表明,未来的路还很长。 如果有一个基准可以将GUI程序相互比较。 然后,找出好的想法将变得容易得多。
![](https://i-blog.csdnimg.cn/blog_migrate/e4ded3cb7411f4b12e6ecb830eae3efd.png)
在本文中,我介绍了7GUI:GUI编程基准 。 我对此进行了思考,并通过思考更好的GUI编程基准如何表现出来来展望下半年的未来。
回顾7GUI
7GUI是我创建GUI编程基准的尝试。 在传统的基准测试中,将竞争实现的资源消耗进行比较。 在7GUI中,根据符号对实现进行比较。
为此,7GUI定义了七个任务 ,这些任务代表着GUI编程( 实时版本 )中的典型挑战。 已经有很多实现 , 您的实现可能就是其中之一。 此外,7GUI提供了一组建议的评估维度 。
![](https://i-blog.csdnimg.cn/blog_migrate/5a6106d9680b312d4119d410ea00de32.png)
该项目被认为是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有什么不同?
![](https://i-blog.csdnimg.cn/blog_migrate/b492ae255399dae73eb588eaf2f6d8d8.png)
挑战性
正如引言中所暗示的那样,7GUI并未涵盖我作为软件工程师的专业经验中所观察到的所有相关挑战。 我只列出挑战,而没有更深层次的解释,我认为值得在更完整的基准中解决。 请注意,这既不是完整的集合也不是必需的集合,而是假设的新基准的良好起点:
- 处理不稳定的远程API。 不仅读取,而且还进行变异操作(例如POST请求)。 这意味着要处理加载和错误情况,缓存和处理竞争条件。
- 以一种聪明的方式处理加载。 例如,仅在一定时间后才显示加载指示器。 在最短的时间内显示它以防止闪烁。 如果先前已获取,则在加载期间显示部分数据。
- 乐观更新
- 预取
- 变化传播
- 呈现可过滤或可搜索的大型项目列表,可远程获取结果
- 撤销重做。 可能与远程同步一起使用。
- 屏幕之间的导航/路由。 防止导航(例如未保存的更改)
- 标签内容
- 模态。 可能会通过向导完成多个步骤:对话框控件
- 分页或无限加载
- 自适应/响应式布局
- 约束(表格)
- 通知/敬酒。 可能由远程事件或计划任务触发。
- 状态还原
- 离线支持
- 相同数据的两个替代视图
- Rx通常可能适合的某些功能:对过去事件的操作,协调多个相互依赖的请求。
![](https://i-blog.csdnimg.cn/blog_migrate/6b95d68c76e6a7b2600edec0669d3821.png)
您可能已经注意到,许多挑战涉及与远程API的通信。 世界之间的联系日益紧密,这在当今构建和使用的应用程序中得到了体现。 一个好的基准应该考虑到这一点。
人工性
对于7GUI,我有意识地决定要有一系列隔离的任务。 这种方法的副作用是增加了人工性。 就其本身而言,这不是一件坏事,但这是一个权衡。
通过关注每个任务的一些挑战,可以更轻松地了解如何解决它们。 同样,比较解决方案应该更容易。 如上所述,问题是这是否重要。 虚假性的缺点是,可能会遗漏挑战或方法之间的可能相互作用。
但是最大的缺点是编写一个“真实的”应用程序只会更加有趣 。 如果您创造了一些东西,同时又解决了相当抽象的挑战,那么您可以实际使用它们并在实践中使用它,那么您会更加投入其中。 最终,任务越参与越多,更多的人会花更多的精力在任务上,这导致思想交流更多—至少这是我的印象。
具体来说,电影浏览/查看应用程序非常适合。 绘制所有相关挑战通常是足够的,而要有趣则足够真实。
需要的努力
如果基准太小,就无法涵盖足够的有趣挑战。 它还可能鼓励非常专业的解决方案。 如果基准太大,则完成基准所需的工作可能会阻碍某人编写实现。
现在,我最近在React / MobX中重新实现了7GUI,我注意到它感觉太大了。 尤其是“圆形抽屉”和“单元”任务可能是他们自己的基准。
原始形式的TodoMVC感觉太小了。 另一方面,HNPWA感觉太大了。 但是,如果基准测试涉及创建非人工应用程序,那么我相信开发过程中增加的乐趣会抵消需要付出的更大努力。
因此,对我而言,理想的基准将位于TodoMVC和HNPWA之间,但更接近HNPWA。
标准的特异性
接受标准应该有多具体?
过于具体,您可能会偏向某些解决方案。 这也将减少乐趣,因为您希望能够在实现中“打上自己的烙印”。 太宽容,您将很难比较缺少基准测试点的实现。
总的来说,我认为您应该从非常具体的事情开始,一旦人们开始抱怨某些阻止良好方法的标准,就放松他们。 随着时间的流逝,您应该达到一套良好的接受标准。
衡量实施
当涉及到一套将实现之间进行比较的标准时,我仍然是符号的认知维度(CDs)框架的拥护者 ,该框架是“一种分析信息伪像可用性的方法”。
![](https://i-blog.csdnimg.cn/blog_migrate/20ab8395008c67486b3cb0cd5d3178e6.gif)
但是,我承认其介绍是干的。 我试图使它对于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