【前端开发】前端架构与具体的应用的矛盾,最终的简单才是王道。

简介: 写在前面   年关将近,这年味愈加的浓烈了哈,似乎无心工作,似乎家乡的叨念从远远的方向传进了你的心里,坚持住哈,马上,就回家了。        进入正题,首先,我需要先解释下这个标题所表达的意思,以及它背后引出的具体的问题,前端架构与具体的应用的矛盾 这句话为什么要这么说,相信大部分公司,不论你...

写在前面

  年关将近,这年味愈加的浓烈了哈,似乎无心工作,似乎家乡的叨念从远远的方向传进了你的心里,坚持住哈,马上,就回家了。

       进入正题,首先,我需要先解释下这个标题所表达的意思,以及它背后引出的具体的问题,前端架构与具体的应用的矛盾 这句话为什么要这么说,相信大部分公司,不论你是创业型公司、外包公司或者是大一点儿的,上市的,在你们的前端技术栈中,react出现的频率应该不低,vue是更甚者吧,基于webpack、glub构建的应用应该很多了,甚至可以说,这些技术已经占领了前端的半个天下,但是笔者在这里呀,不禁要提出一个问题,那就是,你们的技术栈真的带给前端更简单的内容了吗? 使用这些技术栈的时候,你们的应用是否会变得学习成本高昂、扩展能力差、依赖高阶程序员、文档不齐全、有没有测试用例?

架构的本质

  我认为架构的本质应该是什么? 它应该是基于可能面临的风险构建的一套能够适应当前业务、扩展未来业务、行为可预测的、高可用性的。在能解决这些问题的前提下,架构应该是高度抽象的吧,一个优秀的架构,它一定要足够简单,基于一个或多个抽象的理解上构建出来的。

  简单才是本质,spring为什么那么火,它足够简单。一旦你了解了它的抽象思维方式,整个开发极易上手,这就是一个优秀的架构应该有的表现力。如果你正在设计前端架构,我的忠告是,最好结合你的业务实际去实现它而不是去考虑最新的技术栈,盲目的追求渲染速度、组件式等。 

  前端一定要与业务接轨,一个管理系统,你跟我谈什么渲染速度?一个正常的管理系统前端,它甚至都不需要webpack这样的工具构建,只需要一个裸的vue加上jquery就可以完成,这样的结构要优于大部分。为什么? 贴合实际嘛!  后台系统你一个前端能维护多久呢?大部分时间,后台er在维护这个界面,如果你使用的技术太过复杂,增加了学习成本,还更容易使整个架构逆向发展。

  再例如,企业官方网站,企业商城,大型公司的门户,宣传网页,这些东西完全不需要用到打包、甚至vue你都要少用, 为什么?最重要的是它们不利于SEO,然后是不利于快速迭代,设计的再复杂些,vue技术栈全部捅上去,那有什么用嘞?除了给你自己的职业生涯添加一笔,对公司来说这就是技术的债务,公司需要招比你更厉害的人才能理解你写的这些高级的代码,而这些代码一旦在无数个迭代中膨胀,最后的选择只有推倒重来,改都没的改。

 

结合业务再谈技术

  什么前端路由系统,SPA 框架,你都要结合业务,后台系统使用SPA就是耍流氓。陡然增加前端的复杂性,让前端变成了一个比后台系统还复杂的系统。这很得不偿失。仅仅是为了前端开发的便利性,忽略的整个系统的复杂度,这样的架构怎么看都是不可取的。 

  什么时候能够使用这些技术栈? 当然是业务允许、风险可以控制的情况下。  例如多终端,移动端,在移动端使用打包工具,SPA框架开发是很明智的,它们带来的优势,在渲染速度上,在使用性上,都是一流的。而且真正的实操中,这样的项目一般是重点维护的。

  要结合业务的实际选择技术,大部分时候,开发时间是有限的,实现的功能很多,盲目追求技术的新、快、是没有根据的。

  

一些看法

  推荐一些我个人开发时常用的几项前端架构,它们是我结合平时的开发实际,业务适应程度做出的技术栈调整。

  首先,如果项目大小一般,时间很紧急,我会毫不犹豫选择裸vue+jquery+bootstrap,快速开发完毕。

  如果项目中等的话,时间不多不少,我会看团队中,开发人员的比例,比如这个开发团队只有一两个前端,那么我会选择 require管理我的js模块,使用sass管理我的css模块,足够模块化,也有组件,同时开发速度够快,团队中的其他人理解起来也很快,在项目很赶的时候后台也可以帮一些忙,也不会担心他们破坏架构。具体到业务逻辑,首先了解业务的流程,例如我这个应用,面向的是企业管理人员,可能需要一些大数据展示,一些图形化界面。那么我很可能选择react+react-router+redux。

  大型项目需要依靠具体面临的可能风险,你需要调研清楚目标人群,宣传方式,例如使用SEO做搜索宣传,就不能选择打包技术,微信wap,选择vue技术栈是明智的选择等等。

  需要注意的是,最终的简单才是王道

  

写在最后

  希望大家一起探讨这方面的话题,我的观点也许是错误的,或者是有问题的,讨论一下,大家一起提升。

 

======================================================== 转载请注明出处。
目录
相关文章
|
1天前
|
前端开发 JavaScript 开发者
“揭秘React Hooks的神秘面纱:如何掌握这些改变游戏规则的超能力以打造无敌前端应用”
【10月更文挑战第25天】React Hooks 自 2018 年推出以来,已成为 React 功能组件的重要组成部分。本文全面解析了 React Hooks 的核心概念,包括 `useState` 和 `useEffect` 的使用方法,并提供了最佳实践,如避免过度使用 Hooks、保持 Hooks 调用顺序一致、使用 `useReducer` 管理复杂状态逻辑、自定义 Hooks 封装复用逻辑等,帮助开发者更高效地使用 Hooks,构建健壮且易于维护的 React 应用。
7 2
|
6天前
|
JavaScript 前端开发 测试技术
前端全栈之路Deno篇(五):如何快速创建 WebSocket 服务端应用 + 客户端应用 - 可能是2025最佳的Websocket全栈实时应用框架
本文介绍了如何使用Deno 2.0快速构建WebSocket全栈应用,包括服务端和客户端的创建。通过一个简单的代码示例,展示了Deno在WebSocket实现中的便捷与强大,无需额外依赖,即可轻松搭建具备基本功能的WebSocket应用。Deno 2.0被认为是最佳的WebSocket全栈应用JS运行时,适合全栈开发者学习和使用。
|
1天前
|
前端开发 API UED
深入理解微前端架构:构建灵活、高效的前端应用
【10月更文挑战第23天】微前端架构是一种将前端应用分解为多个小型、独立、可复用的服务的方法。每个服务独立开发和部署,但共同提供一致的用户体验。本文探讨了微前端架构的核心概念、优势及实施方法,包括定义服务边界、建立通信机制、共享UI组件库和版本控制等。通过实际案例和职业心得,帮助读者更好地理解和应用微前端架构。
|
3天前
|
运维 监控 Serverless
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
11 1
|
7天前
|
缓存 前端开发 JavaScript
前端的全栈之路Meteor篇(二):容器化开发环境下的meteor工程架构解析
本文详细介绍了使用Docker创建Meteor项目的准备工作与步骤,解析了容器化Meteor项目的目录结构,包括工程准备、环境配置、容器启动及项目架构分析。提供了最佳实践建议,适合初学者参考学习。项目代码已托管至GitCode,方便读者实践与交流。
|
6天前
|
人工智能 资源调度 数据可视化
【AI应用落地实战】智能文档处理本地部署——可视化文档解析前端TextIn ParseX实践
2024长沙·中国1024程序员节以“智能应用新生态”为主题,吸引了众多技术大咖。合合信息展示了“智能文档处理百宝箱”的三大工具:可视化文档解析前端TextIn ParseX、向量化acge-embedding模型和文档解析测评工具markdown_tester,助力智能文档处理与知识管理。
|
7天前
|
前端开发 API UED
拥抱微前端架构:构建灵活、高效的前端应用
【10月更文挑战第17天】微前端架构是一种将前端应用拆分为多个小型、独立、可复用的服务的方法,每个服务可以独立开发、部署和维护。本文介绍了微前端架构的核心概念、优势及实施步骤,并分享了业界应用案例和职业心得,帮助读者理解和应用这一新兴架构模式。
|
7天前
|
Web App开发 缓存 前端开发
拿下奇怪的前端报错(六):多摄手机webrtc拉取视频流会导致应用崩溃,从而无法进行人像扫描
本文介绍了一种解决手机摄像头切换导致应用崩溃的问题的方法。针对不支持facingMode配置的四摄手机,通过缓存和序号切换的方式,确保应用在特定设备上不会频繁崩溃,提升用户体验。
|
21天前
|
缓存 监控 API
探索微服务架构中的API网关模式
【10月更文挑战第5天】随着微服务架构的兴起,企业纷纷采用这一模式构建复杂应用。在这种架构下,应用被拆分成若干小型、独立的服务,每个服务围绕特定业务功能构建并通过HTTP协议协作。随着服务数量增加,统一管理这些服务间的交互变得至关重要。API网关作为微服务架构的关键组件,承担起路由请求、聚合数据、处理认证与授权等功能。本文通过一个在线零售平台的具体案例,探讨API网关的优势及其实现细节,展示其在简化客户端集成、提升安全性和性能方面的关键作用。
62 2
|
25天前
|
存储 缓存 监控
探索微服务架构中的API网关模式
【10月更文挑战第1天】探索微服务架构中的API网关模式
76 2