“为什么?”的问题在单页应用程序框架中

2020年12月30日11:21:42 发表评论 35 次浏览

本文概述

“为什么?”的问题在单页应用程序框架中1

多年来, "单页应用程序"一词既表示特定类型的网站, 也表示网站开发范例。当网站被构建为类似于桌面应用程序而不是传统的静态Web文档时, 它可以被视为单页应用程序(SPA), 它利用结构化Javascript连接到服务器端服务, 从而为你的平均水平增加了流畅性和动态性网络体验。

这意味着用户可以在其中读取和编辑内容的站点, 而内容本身无需刷新页面即可更新。考虑使用Gmail或Twitter。

这个词本身可以追溯到2002年, 当时Tibco Software的一些工程师实际上为该技术的专利申请了专利, 该技术是早期尝试在单页应用程序中使用的。大约在同一时间, Slashdotslash.com出现在现场, 这是第一个在线Web应用程序之一, 它是一个沙箱, 用于在单个HTML文档中尝试所有新Web技术, 而无需刷新页面。

“为什么?”的问题在单页应用程序框架中2

但是, SPA真正开始于2008年, 当时杰西·詹姆斯·加里特(Jesse James Garett)为AJAX命名, 该技术使开发人员无需加载新页面即可向服务器发出动态请求。

这与jQuery, Dojo和Prototype等客户端框架的兴起形成了有机的联系, 从而提高了Javascript的知名度并扩大了其局限性。

没有这两个趋势, 就不可能看到新的单页应用程序框架的出现, 该框架受jQuery之类的启发, 但经过了调整以利用AJAX。

而且, 如果你进行了足够多的搜索, 你会发现大量文章深入探讨了一个框架与另一个框架的技术考虑, 并回答了该框架如何发挥其最大作用的问题。

你看不到的是为什么

因此, 我认为看看开发人员如何在构想或开发初期描述自己的框架来尝试了解其背后的意图可能会很有趣。

将变得十分清楚的是, 每个框架都是权衡的游戏。这些框架背后的意识形态在很大程度上决定着它们的结构, 程序化API以及留下的足迹。

请记住, 这绝不是一个完整的列表, 但我认为它很好地代表了框架的轨迹。

我们为制作了一个自定义演示.
不完全是。点击这里查看.

“为什么?”的问题在单页应用程序框架中3
“为什么?”的问题在单页应用程序框架中4

Backbone.js

Backbone.js旨在为具有雄心勃勃的界面的数据丰富的Web应用程序提供一个通用的基础, 同时-故意通过做出自己有能力做的任何决定来避免使你陷入困境。 — Backbone.js文档

Backbone.js可能是有关SPA框架的任何对话都应该开始的地方。它是由杰里米·阿什肯纳斯(Jeremy Ashkenas)于2010年推出, 目的是为已变得杂乱无章的Javascript应用程序结构提供结构。

Ashkenas在现有库jQuery和Underscores的基础上构建了Backbone。这就是"共同基础"思想的来源。 Backbone的目标是统一和组织复杂的Javascript代码, 以使其在项目中可重用并且更易于理解。因此, Backbone提供的结构足以使程序员摆脱笨拙的"意大利面条式代码", 并始终如一地处理服务器上的数据, 但仍将大部分决策权掌握在单个开发人员的手中。

AngularJS

我想看看是否可以简化这一点。但是我不想为开发人员简化它, 而是想为网页设计师简化它。所以不懂程序的人而且因为人们不知道如何编程, 所以我不得不使用HTML。 — Angular创作者MiškoHevery的演讲

AngularJS与Backbone差不多在同一时间出现, 尽管在此之前它已经开发了一段时间。 Angular背后的意图非常明确。该框架的目标受众是设计人员, 或者至少是没有经验的开发人员。关于框架结构如何遵循此假设的大多数决定。

举例来说, 模板可以直接用普通的旧HTML创建, 这样Angular用户就不必学习新知识了。 Angular还附带了一些内置的便捷工具, 并鼓励采用自以为是的开发方法。所有这些使Angular的实际大小和广度比之前的框架(例如Backbone)大得多, 但也使学习曲线变了道路下。

余烬

Ember是一个JavaScript框架, 可以完成你通常需要手工完成的所有繁重工作。每个Web应用程序都有一些共同的任务。 Ember为你完成了这些任务, 因此你可以专注于构建杀手级功能和UI。 —原始的Ember自述文件

Ember实际上是对Web框架SproutCore的重写而开始的, 该框架在Backbone和Angular时代就很流行, 并且被Apple用于许多Web项目。但是SproutCore在2012年之后停滞不前, 许多开发人员意识到现在是时候改变了。所以开发者耶胡达·卡兹(Yehuda Katz)和汤姆·戴尔开始致力于SproutCore 2.0(后来成为Amber.js)和Ember。

Katz和Dale在Ruby on Rails社区中有很多经验。对于那些不熟悉的人, Rails是一个服务器端框架, 它更喜欢"常规而不是配置"。这基本上意味着, 许多关于如何开发应用程序的决定已经由开发人员做出。构架为个体开发人员提供了良好的开端。

这种精神告诉了安伯采取的方法。 Ember的创建者认为, 有很多样板代码(从服务器获取数据, 将路由连接到模板, 将内容分解为多个部分等), 开发人员需要为每个项目一遍又一遍地编写。因此, 它就直接进行了这项工作, 并对代码的工作方式做出了许多假设, 并将其抽象化。

只要你坚持使用Ember规定的方法, 就可以在编写一行代码之前为你完成很多工作。卡茨甚至吹嘘说:"如果你是骨干网迷, 我想你会喜欢用Amber编写的代码很少。"

React

React是用于构建可组合用户界面的库。它鼓励创建可重用的UI组件, 这些组件提供随时间变化的数据。

当React首次启动时, 开发人员就是这样描述它的。但是他们真的这样总结:

当你的数据随时间变化时, React确实很出色。

– Pete Hunt, "我们为什么要建立React"

React是在Facebook上创建的, 旨在解决一个非常具体的问题。当页面上的数据不断变化和更新时(例如实时更新流进来), 事情往往会变慢。因此, 他们隔离了导致此问题的层(通常称为视图层)并开始工作。

所以对于React为什么很简单。速度。

毫不奇怪, React是一个框架, 所有数据都来自其中。当数据改变时, 事情就会响应。

很快。

有各种各样的算法(虚拟dom吗?), 甚至是一种名为JSX的新标记语言都可以为这项工作提供支持, 但从根本上讲, 数据是一流的公民。事实证明, 速度不仅为React开发人员提供了明确的目标, 而且为基准提供了基准。

Vue

Vue.js是用于构建Web界面的库。尽管它更像是一组可以很好地协同工作的可选工具, 但你也可以将其与其他一些工具一起称为"框架"。 — Evan You, " Vue.js :(重新)介绍"

Vue从许多方面开始, 都是对React的一种反应(原谅双关语)。创作者埃文·尤认识到React所能取得的进步, 但与此同时, 社区却破裂了, 而且不断变化(我保证, 最后一个)。

你最初拒绝使用"框架"这个名称, 因为他希望Vue成为仅提供最低限度要求的东西。但是, 为了限制Vue社区的分裂, 你在主要Vue代码库的模块化第一方附件中付出了很多努力。它将Angular等框架的更具说明性的方法与React等库的灵活性相结合, 以创建一组完全可以很好地协同工作的不同工具。

事前

对我来说, 我想要[React]的开发人员经验, 我只是不想为此付出代价。所以这让我开始思考。– Jason Miller, 把" P"放在Preact中

实际上, Preact早在2015年就以Codepen的方式开始, 杰森·米勒(Jason Miller)实验一下React的一些渲染限制。但是直到网络上发布了一些性能基准来证明React在移动设备上的呆滞时, 它才真正成为焦点, 米勒的快速而肮脏的实验大大改善了这些基准。因此, 他将代码发布为开源库Preact。

Preact的既定目标始终高于– React使用React的所有好处, 而且降低了性能成本(因此P反应)。从那时起, 该库已经不止一次进行了更新和重新配置, 但是它始终将这一目的放在首位, 利用React的API, 同时更改其在幕后的工作方式。

超级应用程式

Hyperapp是一个现代JavaScript库, 用于在浏览器中构建快速且功能丰富的应用程序。它是那里最小的(1.4 kB), 使用简单, 有趣。 — Jorge Bucaran, Hyperapp 1.0简介

"小"无疑是Hyperapp(最初称为跳蚤)的代名词。最初的代码库大约为4KB, 但是到1.0版本发布时, 这个数字下降了更多。 Hyperapp仅向你提供基础知识, 一种管理代码中的状态和模板的方法, 但它的目标是主要提供一些工具并摆脱困境。从一开始, Bucaran一直强调Hyperapp的足迹和实用方法作为其基本原则。

总结

如果这里有一个教训, 那就是框架的观点。从这个角度出发, 它的设计, 体系结构, 甚至它试图解决的问题都定了基调。从那里开始, 一个社区聚集在这个观点周围, 并促进其努力, 不久之后, 一个新的框架诞生了。

全面了解生产React应用

调试React应用程序可能很困难, 尤其是当用户遇到难以重现的问题时。如果你有兴趣监视和跟踪Redux状态, 自动显示JavaScript错误以及跟踪缓慢的网络请求和组件加载时间,

尝试notlogy

.

“为什么?”的问题在单页应用程序框架中5
LogRocket仪表板免费试用横幅

日志火箭就像Web应用程序的DVR, 实际上记录了React应用程序中发生的一切。你可以汇总并报告问题发生时应用程序所处的状态, 而不用猜测为什么会发生问题。 notlogy还监视你的应用程序的性能, 并使用客户端CPU负载, 客户端内存使用情况等指标进行报告。

notlogy Redux中间件软件包在你的用户会话中增加了一层可见性。 notlogy记录Redux存储中的所有操作和状态。

现代化如何调试React应用程序-免费开始监控.


一盏木

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: