前端框架(解决方案还是膨胀的问题())

本文概述

  • 过去的前端Web开发
  • 人们为什么使用框架
  • 当框架失败时
  • Eval是邪恶的, 但是.innerHTML是Machiavellian
  • 关于无框架编码的最大神话
  • 总结
现代的前端框架要求你下载开发环境, 完整的依赖关系并编译代码, 甚至尝试在浏览器上查看它。这是一件好事吗?是我们正在建设更复杂的站点, 还是框架本身很复杂, 从而引入了不必要的复杂性?
前端框架(解决方案还是膨胀的问题())

文章图片
自90年代以来, 当今的网络开发已经发生了很大的变化。我们能够创建与任何本机应用程序都可以实现的非常接近的整体体验, 并且开发过程也已发生变化。成为前端Web开发人员的日子已经一去不复返了, 只需打开记事本, 键入几行代码, 在浏览器中检查它, 然后将其上传到FTP文件夹即可。
过去的前端Web开发 我首先要说明一个明显的事实:世界不像十年前。 (令人震惊, 我知道。)唯一保持不变的就是变化。过去, 我们的浏览器很少, 但是存在很多兼容性问题。如今, 你看不到” Chrome 43.4.1上的最佳观看效果” 之类的东西, 但是在那时, 这很普遍。现在, 我们有更多的浏览器, 但是兼容性问题更少。为什么?因为有jQuery。 jQuery满足了需要一个标准的公共库的需要, 该库允许你编写用于操作DOM的JavaScript代码, 而不必担心它如何在每个浏览器和每个版本的浏览器上运行-2000年代真是一场噩梦。
现代浏览器可以将DOM作为标准进行操作, 因此近年来对此类库的需求已大大减少。不再需要jQuery, 但是我们仍然可以找到许多依赖它的非常有用的插件。换句话说, Web框架可能不是必需的, 但是它们仍然足够有用, 可以流行和广泛使用。从React, Angular, Vue和Ember到样式和格式设置模型(如Bootstrap), 这是大多数流行的Web框架共有的特征。
人们为什么使用框架 在Web开发和生活中一样, 快速解决方案总是很方便的。你以前用JavaScript做过路由器吗?当你可以npm-install前端框架来克服此问题时, 为什么要经历痛苦的??学习过程?如果客户希望昨天完成工作, 或者你从另一个为特定框架设计的开发人员那里继承代码, 或者如果你正在与已经使用给定框架的团队进行集成, 那么时间就是一种奢侈。面对现实吧-框架确实存在是有原因的。如果对他们没有好处, 那么没人会使用它们。
那么使用Web开发框架有哪些好处和独特的属性呢?
时间就是金钱。当你开发项目时, 客户不在乎你使用哪个框架(实际上, 甚至可能都不知道你使用什么框架), 他们只在乎取得结果, 而且越快越好。建立的框架使你能够从一开始就获得即时的进步感, 这是客户从第一天开始就渴望的。此外, 开发速度越快, 你赚到的钱就越多, 因为框架释放的时间可以重定向到承担更多的工作项目。
与社区有关。在选择框架时, 这是非常重要的一点-当你遇到问题时, 谁将为你提供帮助?你和我都知道它会在某个时候发生。你将到达一个需要做一些框架不希望做的事情, 或者该框架从未被设计成可以让你访问的地方, 因此拥有一个社区来支持你至关重要。沉浸于虚拟世界中时, 开发工作(尤其是自由职业者)可能会很难, 并且如果你是团队中唯一的前端Web开发人员, 则意味着你是唯一拥有丰富经验和专业知识的人, 解。但是, 如果你使用的前端框架有可靠的支持, 那么世界另一端将面临着同样的问题, 并且可能会为你提供帮助。
标准是美丽的。你是否曾经注意到, 当你查看自己的旧代码片段时, 可以很轻松地浏览它吗?或者至少比其他人编写的一段代码更容易?你以某种方式思考, 并且拥有自己的方式来命名事物和组织代码。这是一个标准。即使他们只是为了我们自己, 我们都会跟随他们。我们倾向于在早餐时吃类似的东西, 在某个小时醒来, 然后每天将钥匙放在同一位置。确实, 如果我们每天都要改变常规, 光是从弄清楚如何做事的开销上, 生活就会变得更加艰难。是否曾经因为将钥匙放在与正常人不同的地方而丢失了钥匙?标准使生活更轻松。作为团队或开发人员社区的一部分时, 它们绝对不可或缺。
从安装框架开始, 框架就提供了标准, 可以指导你以特定的方式进行思考和编码。你无需花费时间与团队建立标准;你只需遵循框架中的工作方式即可。这样可以更轻松地一起工作。当你知道某个功能必须位于某个文件中时, 查找该功能会更容易, 因为它是为在SPA中添加路由而构建的, 并且在你的框架中, 所有路由都以该名称放置在文件中。如果你具有这种标准化水平, 那么具有不同技能水平的人们可以一起工作, 因为尽管高级编码人员知道为什么要这样做, 但即使是初级开发人员也可以遵循标准。
当框架失败时 几年前, 说出” 我不使用框架-我看不到框架有什么真正的好处” 之类的话, 就会把拿着火把和干草叉的人带到你家。但是今天, 越来越多的人问自己:” 为什么我应该完全使用框架?我真的需要它们吗?没有它们, 很难编码吗?”
我当然是其中之一-我从不喜欢任何特定框架, 并且在整个职业生涯中一直在没有它们的情况下进行编码。如果我对此有选择, 我的选择永远是” 不, 谢谢” 。多年来, 我一直在使用JavaScript和ActionScript进行开发。当大多数人已经认为它已经死了时, 我正在用Flash进行编码。 (我知道, 我知道… 但是我做了很多动画, 而纯HTML动画很困难。)因此, 如果你是从未考虑过不使用框架进行编码的众多人中的一员, 请允许我向你展示一些可能的原因, 挣扎。
“ 一个大小适合所有人” 是一个谎言。你能想象编写一款可以完成你职业生涯中所有工作的软件吗?这是网络开发框架的主要问题之一。你的项目有非常具体的需求, 我们倾向于通过添加库, 插件或附加组件来扩展框架范围来解决。没有框架可以100%满足你的需求, 也没有框架100%包含你会发现有用的内容。
如果你不使用过多的代码, 则会导致网站的加载时间延迟, 这对于每个其他用户而言都变得越来越重要。另一个问题是” 一刀切” 的思维定式导致代码效率低下。以$(‘ sku-product’ )。html(‘ SKU 909090’ ); 为例, 这是jQuery代码, 最后, 我们都知道它将被翻译成document.getElementById(‘ sku -product’ )。innerHTML =’ SKU 909090′ ; 。
在单行上的这种区别似乎并不重要, 但是更改页面特定元素的内容正是React的优点。现在, React经历了创建DOM表示的过程, 并分析了你尝试呈现的内容之间的差异。仅从一开始就定位要更改的内容会更容易吗?
你走过的那堆杂草长成荆棘。你是否曾经遇到过使用框架并尝试向其中添加库的情况, 只是为了意识到所需的库版本与所使用的框架版本不能很好地配合使用?有时, 与仅自己编写代码相比, 使两段代码一起工作需要更多的精力。而且由于你使用的框架和库通常是基于其他框架和库构建的, 这些框架和库可能具有你甚至无法预料到的隐藏不兼容性, 因此问题可能会成倍增长, 甚至达到无法管理的程度。希望该项目保持增长。
跟上琼斯的步伐是一件事情。是否曾经在AngularJS中从事过一个项目, 只是发现你需要在Angular 4发布之前才出现的东西?你甚至不知道Angular 5已发布吗?这是另一个巨大的问题。即使你只使用一个前端框架, 当发生新的主要版本时, 事情也可能发生很大变化, 以至于你努力编写的代码甚至都无法在新版本上运行。从烦人的许多文件更改需要完全重写代码, 这可能会导致任何事情。
紧跟框架的最新版本是具有挑战性的, 但是要注意的是, 当更新完全停止并且其他技术无法跟上其他框架时, 其他框架也会受到影响。 2010年, AngularJS和Backbone首次发布。如今, Angular已经是其第五个主要版本, 而Backbone则完全不在关注之列。七年似乎很长一段时间。如果你建立网站, 则它们的美观和功能可能已经完全改变。如果你要构建应用程序, 则押注在错误的框架上可能会使公司在以后需要重写的情况下处于艰难而昂贵的境地。
当你只有一把锤子时, 一切看起来都像钉子。如果你经常使用Web开发框架, 那么你可能会遇到这种情况, 其中单个代码库定义了你将来使用的代码的形状, 即使它只是外围相关的。假设你要构建一个类似YouTube的平台, 并且想要使用FrameworkX。即使在当今这个时代听起来有些荒唐, 你还是可能会决定使用Flash制作视频, 因为这就是内置在框架中。
框架有意见, 而且意见有力;例如, React会强制你以特定方式使用JSX。你可以在各处看到以这种方式使用的代码。有其他选择吗?是。但是谁使用它?这并不总是一件坏事, 但是如果你需要执行复杂的动画, 则可能只需要一个动画框架, 而不需要整个React。我见过人们在做疯狂的事情, 例如在页面上添加jQuery只是为了将一个节点附加到元素上, 这可以在普通JS中使用document.getElementById(‘ id_of_node’ )。appendChild(node); 完成。
Eval是邪恶的, 但是.innerHTML是Machiavellian 我想花时间分别探讨这一点, 因为我认为这是更多人没有框架就不进行编码的原因之一。当你尝试在DOM中添加内容时看到大多数代码的工作原理时, 你会发现.innerHTML属性注入了一堆HTML。我们大家似乎都同意eval对运行JavaScript代码不利, 但是我想在此关注.innerHTML。当你将HTML代码作为纯字符串注入时, 你将失去对你创建的任何节点的任何引用。确实可以通过使用getElementsByClassName或为其分配ID来找回它们, 但这并不实际。尝试更改其中一个节点的值时, 你会发现自己重新渲染了整个HTML。
当你开始编码时, 这很好。你无需太多经验即可轻松制作许多简单的东西。问题发生在现代网站的复杂性上, 现代网站更像是应用程序, 这意味着我们需要不断更改节点的值, 如果你要通过重新连接整个结构来进行操作, 则这是一项高成本的操作通过.innerHTML。 React通过一个影子DOM有效地解决了这个问题, 而Angular通过使用绑定(一种修改页面上显示的值的简便方法)解决了这个问题。但是, 通过跟踪创建的节点并保存将在变量中重用或更新的节点, 也可以很容易地解决该问题。通常, 还有其他一些原因请不要使用.innerHTML。
关于无框架编码的最大神话 时间就是金钱。是的, 我将这个概念带回了以前。许多人都觉得, 如果他们停止使用流行的Web框架, 我们将立即转向90年代的互联网, 当时< marquee> 是每个人的最爱标签, 在Geocities网站上旋转GIF很时髦, 而Alta Vista是进行网络搜索, 点击计数器无处不在。
使用Web框架, 你的第一行代码似乎可以节省很多时间, 但是在某些时候, 收益变成了损失。你花时间阅读有关如何使框架执行其不为之准备的工作, 如何集成库并使它们与框架配合使用的知识, 并了解遵循框架标准构建的代码并没有用完全可以工作, 现在你需要重写它。当你在没有框架的情况下工作时, 起步较慢, 但你会取得稳定的进步。最后, 这一切都与你希望轻松的部分在哪里有关。总时间不会有太大变化。
我的代码将比长城长。没有框架的写作就像买电影而不是订阅流媒体服务。你无法立即访问要观看的数百部电影, 但是你也不必花钱购买甚至从商店都不下载的其他数千部电影。你可以编写所需的内容。
中间人有用吗?当然。但这通常不是必需的。你编写的每一行代码都具有更多含义, 因为你无需适应框架的要求。感觉就像你正在用纯JavaScript编写更多代码, 因为创建DOM元素的方法需要一行代码来创建一个元素, 将其附加到DOM上, 并可能添加一个样式类, 而不是调用一行内容。 JSX中的代码。但是, 如果你使用jQuery或React之类的库比较代码, 那么香草JS的长度可能非常相似。有时更长, 但有时也更短。
无需重新发明轮子。到处都有计算机科学教授的口头禅。没错, 只是不必专门指框架。例如, 几乎每个Web应用程序都要求发送Ajax请求以加载或保存数据, 但是没有框架并不意味着你每次都需要重新编写代码。你可以创建自己的库或代码库, 也可以从其他库中提取代码。它越小, 根据需要进行修改或调整就越容易, 因此在你需要特定于项目的内容时, 它会派上用场。与浏览第三方库或框架可能包含的大量文件相比, 修改100-200行代码要容易得多。
它仅适用于小型项目。这是一个很普遍的神话, 但根本不是真的。目前, 我正在使用一个完整的系统来在一个地方在线管理公司的各个方面, 包括一个类似于Google云端硬盘的模块。无论使用框架还是不使用框架, 我都会经历非常相似的步骤并遇到非常相似的问题。差异可忽略不计。但是, 如果没有框架, 我的整个代码将更小且更易于管理。
【前端框架(解决方案还是膨胀的问题())】我想证明
好的。让我们停止谈论理论, 跳到一个真实的例子。几天前, 我需要显示商店徽标的品牌列表。最初的代码使用的是jQuery, 但存在一个问题, 即在Mozilla中加载时, 对于尚未上传徽标的品牌, 该图标会显示一个损坏的图像图标。我们不能仅仅因为X公司尚未完成工作而让商店看起来还没有完工, 但是该功能需要上线。
以下代码使用与.innerHTML等效的jQuery:
var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0; i< list_brand_names.length; i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "< a href='http://www.srcmini.com/pages/" + brandName + "'> < img src='http://www.srcmini.com/images/" + brandName + "' /> < /a> "; } jQuery("#brand-images").html(img_out);

在不深入研究jQuery的优点和缺点的情况下, 这里的问题是我们对所创建的图像没有任何引用。尽管有些解决方案不涉及更改代码, 但让我们利用这个机会来了解如何完全不用任何库来完成:
var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "http://www.srcmini.com/images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

原始的jQuery代码长六行, 而原始的JS解决方案花了十二行。为解决此问题, 隐藏每张图像直到加载完毕, 编码时间是原来的两倍。因此, 让我们看看替代方案。可以在jQuery中解决吗?看看这个:
img_out += "< a href='http://www.srcmini.com/pages/" + brandName + "' style="display:none"> < img src='http://www.srcmini.com/images/" + brandName + "' onload="showImage(this)"/> < /a> "; function showImage(image){ image.parentNode.style.display = ""; }

通过添加几行代码, jQuery和香草之间只有三行的区别, 但是在jQuery上, 你可以看到img_out行迅速变得非常复杂, 以至于需要暂停并仔细考虑你在做什么。通过使用节点函数添加属性, 函数等直接对DOM进行编码可能会比较冗长, 但是每行都有更清晰, 更精确的含义, 从而使以后的读取和维护变得更加容易。
让我们看一下React:
function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (< a href="http://www.srcmini.com/{props.brand}"> < img src=http://www.srcmini.com/{url}/> < /a> ); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (< BrandLink brand={step} key={step}/> ); }); return (< div className="brands"> {links}< /div> ); } } ReactDOM.render(< Brands /> , document.getElementById("root"));

这个版本显然不是最佳的。代码不比原始代码短, 而且我们甚至还没有解决问题并隐藏链接, 直到加载其中的图像为止。
对于每个示例, 结果将有所不同。有时, jQuery会更短。有时候, React会赢。有时, 香草JS可能比两者都短。无论如何, 这里的目的不是要证明一个在本质上优于另一个, 而是要证明使用香草JS和使用框架在代码长度方面没有显着差异。
总结 就像任何现实生活中的问题一样, 没有什么是黑人或白人。没有Web开发框架的编码可能是某些项目的最佳解决方案, 而另一些项目则是噩梦。与所有工具一样, 关键不仅在于学习如何使用它, 还在于学习何时使用它以及其优缺点是什么。使用纯JavaScript进行编码就像使用任何框架一样-掌握它需要花费一些时间, 你才可以轻松使用它。
但是, 至少对我而言, 关键区别在于框架的存在和发展, 即使框架长期流行, 它也可以从一个版本急剧变化到另一个版本。纯JavaScript将是一个更长的选择, 直到它不再完全相关并且出现其他一些语言为止。即便如此, 与将给定框架迁移到另一种语言相比, 你可以将更多的概念和策略直接从一种语言迁移到另一种语言。就单个项目而言, 时间和工作量大致相等, 知识折旧的减少以及你可以带走的下一个挑战的课程是需要考虑的非常重要的因素。
相关:微型前端的优势和好处

    推荐阅读