前端开发的难点到底在什么地方

业务逻辑很复杂而且多变

『前端的逻辑复杂度基本不如后端』这个只是但从数据处理的角度来看的，前端对于数据处理的确是模板 + 变量一套一展示就好了，这个是挺简单的。

前端逻辑复杂度主要在于数据 + UI + 交互的实现，就比如一个简单的多 tab 页的功能，可以用 CSS 实现、用 JS 实现，JS 可以通过切换 remove DOM 或者添加 classname 隐藏，虽然效果上都可以实现，remove DOM 无法原有结构的状态，添加 classname 的 CSS 方式很难实现初始化状态。除此之外还可能需要对浏览器进行兼容性处理 + 响应式。然后突然来个业务需求说要加个 iframe 嵌入别人的页面，或者改什么效果，如果之前开发的不合理，基本上要重做了。

相比后端，只输出数据模型给前端，如果业务不需要什么字段了，甚至让前端不读取好了，改都不用改。我们几次大的业务平台重构，前端基本要重新开发一遍（效果、交互完全不同），后端模型和数据库则可以递进式的复用、扩展、升级。这也是导致前端需要堆人大力出奇迹的问题。

垂直领域解决方案很难

切页面是没什么难度的，但是在淘宝一到双十一、双十二大促根据经常多变的运营需求切几百个页面就很难了。这已经不是堆人堆外包可以解决的了，所以我们有 TMS 等各种运营系统，前端切模块，运营自己设置、文案、组装成运营页面，想改自己在后台改不用麻烦前端。这一套系统是个比较庞大的工程，从模块规范、模块开发工具链、模块发布和版本管理、在线管理、在线可视化搭建、数据填写和数据源导入、页面生成和 CDN 同步等等，都需要前端架构师设计然后开发。设计这个系统是很难的。

再比如富文本内容发布业务需求，光是一个富文本编辑器就很复杂，要实现各种功能和兼容性，更复杂的是要适应业务发展。当时刚开始交接淘宝内容业务的时候，需要重新开发编辑器等，跟后端大神们进行讨论推测未来业务可能会有大量表单而且需要完全的数据驱动，所以我们前端设计开发了 现在有个项目表单很多，用什么技术框架合适？ - 知乎 技术产品然后后端有对应的 SDK 进行解析和数据存储、表单生成服务，前端只需要开发组件，然后后端按照业务需求进行配置即可产出内容发布表单。

此外，富文本我们选用了 JSON base 的存储，对比 HTML base 的编辑器，因为淘宝内容详情页充满了各种商品、优惠券、店铺等信息，而且这些信息是需要被理解、识别而且在详情页输出前实时补全最新价格、优惠券可用状态、店铺名等信息的。用传统输出 HTML 的编辑器输出，让后端解析的话复杂度太高了，每一种素材你都需要设计、约束特定的 HTML 标记让后端进行解析。所以我们基于 跳转中 封装了一套 JSON base 的富文本编辑器，设计了完全数据驱动的插件机制，可以通过配置任意控制要提供的功能等。

         

           虽然知乎的编辑器也是基于 draft-js 开发的，但遇到的业务挑战完全不同。它不需要功能动态变化，因为所有人都一样。然后不知道是后端的数据处理逻辑的问题，它在提交和回填的时候是通过 HTML 作为媒介进行传播，将 draft-js 的 JSON 数据协议转成 HTML 提交给后端存储。所以不同业务场景、特点，需要完全不同的前端解决方案，在开发这些垂直解决方案的时候，业务分析、技术选型、架构设计、开发落地是非常难的。

前端框架越来越丰富，前后端分离已经是大多数软件团队采取的模式了。vue使用的场景也越来越多。

go本来使用template模板来进行前端的表现，现在可以用vue来分担很大一部分工作了。

通常直接使用go语言写后端，然后使用静态模板加载渲染前端，前端获取后端提供的数据是使用{{ }}符号，2个套在一起的花括号。这个也是vue使用的数据表现方式。

如果go+vue来协同工作的话，需要对vue进行一点设置。比如把{{ }}的方式改为[[ ]]的方式。

首先我们要知道，vue的使用，需要在页面中加载vuejs或vueminjs

纯静态网页使用vue是这样的（给个html例子）

然后我们实现一个go的简单web服务和模板页面

这个go服务器通过端口 1989 展示服务器页面，提供了一个静态文件路径 htmlpage，我们把vuejs和indexhtml文件都放置在htmlpage路径里。

go服务器还用模板给前台页面提供了一个News结构的数据，数据包括：Title,Content,Author的值。

在indexhtml页面中，加载vuejs的时候需要带上静态路径 htmlpage

在 new 一个 vue 变量的时候，必须有一句来设置包裹数据的符号，我们这里设置这个符号为[[ ]]

同时，所有需要由 vue 渲染的数据，都写成类似这样的样子

在 go + vue 方式下的完整模板文件 indexhtml

此页面中{{ }}包裹的数据是由go从后端提供的数据（ 例如：{{Title}}），而[[ ]]包裹的数据，是vue渲染的数据。

只是把 Vue里的数据，改为由go后端提供即可。

好吧，作者已经在向月亮示爱了。呵呵 _

运行一下程序，看修改模板后的效果。

我们知道，一款互联网应用从分工上可以分为前端和后端。前端主要负责数据的调用及页面显示渲染，后端主要负责数据的加工处理。

在这里可能有不少人觉得做前端就比做后端要简单轻松，其实不是这样的。说到前端，以前的确是只负责界面渲染（说得通俗点就是“切图师”）和一些JS验证及效果的实现，但是随着这几年技术的发展，前端也有了翻天覆地的变化。最明显的变化就是“大前端”概念的兴起。

什么是“大前端”呢？大前端是基于传统前端的，且是针对后端而言的，大前端可以理解为是前端领域的升级扩展。在以前，前端排好页面后要交给后端进行模板填充，那时的“前后端分离”分离得并不彻底。而“大前端”模式下，前后端的分离是比较彻底的。大前端的特性主要有：

终端的多样式：除了传统的WEB、WAP端外，还新增了：iOS、Android、H5、小程序及公众号等端。因为终端众多，如果还是交集式开发，效率太低。“大前端”概念提出后，我们通过RESTfulAPI可实现同个数据源多种展示风格，极大的提升了开发效率；

大前端概念的提出是前后端分离模式下进化而来的（前端独立于后端开发），此时的前端不光光要处理界面上的显示，还要处理数据调取，所以大前端是需要数据来配合的；

大前端对前端人员的要求更高，要求掌握的技能越来越多，意味着前端人员的工作范围的扩伸。大前端没有固定的实施模式，每家公司都可以基于自家实际情况来考虑大前端的技术模式；

上面我们讲到了，现在的“大前端”是需要数据层面的支持的，主要模式就是后端提供RESTfulAPI供前端调取。不是说前端需要什么样的模式就得由后端来提供，而是在开发时，前后端一起制定数据返回格式，前端开发时通过Mock数据来填充数据。

综上，当下的前后端较之前分离得越来越彻底，两端只是在数据上存在着交集，由后端提供数据，前端调取数据来完成整个产品的业务实现。

简单的业务逻辑，两边都不难，甚至后端比前端更轻松。

记住不是后端简单，是前端现在的生态链远远比不上后端，就一个编译器完全是后端碾压前端，包括各种设计模式，用起来非常顺手。一般来说就普通的企业应用，比如类似于后台管理这种。那么两边都不难，而后端代码量更少，前端更_嗦，不是难，是_嗦，要交互代码量翻倍上升。

对于那种非常侧重交互的时候。比如游戏。3D那些、特效、那么前端也非常难。后端的领域非常广，你学的不仅仅是这门语言上的东西，你还要学习语言外的东西。甚至你要是半个运维。

比如来说后端就高级语言来说。C#、JAVA、PHP这些，你不仅仅要学会语言生态里面的各种库，你还要学它的几大框架，比如BS跟CS框架。除了这个外，你还要学习数据库，关系型跟键值对，如MSSQL、MYSQL、Oracle、Redis等等它们大致语言相通，但是函数触发器游标那些又不太相同。运维你要熟悉WIN跟LINUX基本常识跟安全 *** 作以及部署。这个是一个后端最基本要掌握的知识，然后就是大数据量，高并发。数据一致性的问题，这是一个非常难的问题，别以为去套几个开源的项目你就解决了问题。这个没有实际解决过，都是纸上谈兵。分布式拆开项目就一个业务如何划分都非常难。

返回的具体数据。

在前端发送异步请求获取后端数据时，常常会使用到类似于XML>

​ 在使用RestfulAPI方式进行项目开发的初期，通常由后端同学事先设计出API接口文档。而在开发阶段，往往前后端的开发是并行的，意味着在前端开发过程中，后端并不能提供相应API接口的server。在这种情况下，我们可以自行mock一个server来辅助我们的前端开发。

​ 一个完美的本地模拟后端接口应该满足以下几个方面（暂时只想到这些）：

​ json-server的官方是这样介绍项目的：

​ 假设想要请求 >

以上就是关于前端开发的难点到底在什么地方全部的内容，包括:前端开发的难点到底在什么地方、81.go + vue实现web应用程序、前端处理数据还是后端处理数据等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！