前端页面逻辑如何优化，请教。

分模块,组件拆分,mixin

拆组件拆函数封装，怎么也到不了 2000 行吧？

招一个专业的前端

> 项目上没有专业的前端

所以你们也是后端干前端的活儿吗？那现在前端技术栈能有啥？

表法驱动 减少 if 判断语句. 对象映射减少循环。 组件化。 重复的方法封装复用，

1 、接口层针对性提供接口。比如提供仅页面需要的 vo 对象。
2 、接口层负责业务分支判断。比如按钮是否显示，结果集排序，计算字段等。

听起来你们并没有用前端框架开发

找个压缩 js 代码的网站压缩一下代码，然后网站开启 gzip 就完事了，虽然看起来没变小多少，但是实际小了很多倍

vue 组件化开发了解下

多学点儿 自然就顺了
1024bytelab.com 来看看

用 uglify，可以把他们变成 1 行

@ETiV #11 机智 boy

剥离出非首屏的内容，懒加载这些资源

用文字重新梳理逻辑、上组件

组件化，压缩 基本就是这些了

代码多到不正常，说明两个问题，一个是你对这个项目没有太多的经验积累，第二个是对所实现的技术没有表现出太大的了解。
解决这个问题，第一步还是先梳理业务，没有完整的了解业务前尽量别对代码尽早优化，搞不好就是负优化。
假设你业务模型了解的足够了，下面开始代码结构性优化 。
1.单例模式：选择器查找后保存到变量中，主要是为了减少选择器查找的性能消耗。
2.用面向对象方式写代码，暴露接口封装细节，用参数形式与外部沟通。
2.框架设计方面：功能组件化，以 html 结构为最小单位，剥离成小插件，动态创建 script 脚本渐进式加载，在首屏可为服务器减少极大的压力。

现在的项目基本上都是前后端分离，后端只提供接口，前端单页面应用，框架就是 react 、angular 、vue 全家桶了。
服务就是 express 或 koa，可能会用 nginx 进行反向代理，不过我个人来看感觉没必要。

但是你的情况，我个人的感觉就是你们的项目就是以前 jsp 、aspx 、php 的开发方式。因为你们后端不专业的前端开发方式，把一个应用模块里所有的逻辑都写在一起，堆砌代码，导致了你们现在这样的情况。

我现在给你们的建议：
1 、使用 requirejs，对代码进行拆分，requirejs 加载通用模块、每段逻辑的执行文件。
优点：对于你们的项目的破坏性小，可以无缝升级
缺点：文件地址是相对于 html 的；需要配置； js 文件不是同步加载的

2 、使用 gulp + webpack，用 webpack 将单个页面内每段逻辑的执行文件打包到一起。
优点：使用了 es6 的模块来拆分你们的业务逻辑；可以配合 babel，让你们使用最新的 es 版本（ webpack 如果没有 style-loader 之类的来注入 css，单纯只编译 js 的话，是可以兼容 ie 的）；打包的同时，顺便压缩代码（生产环境）
缺点：项目开发时，需要安装 node，启动 gulp ；配置稍微复杂一些

整理好业务点 招一个前端重构

不要自己去解决超出能力范围的问题，招可以解决问题的人。

接手的一个 vue 商城项目，活动页代码 6000 多行，拆分了三十多个组件出去还有 2500 多行。再优化只能重写逻辑了

懒得用 react 和 vue 的话，直接上 requirejs，改动少

补充一下，前端页面非必须的话不要放太多业务逻辑，只做展示。
这部分可以丢到后台，前端就复杂渲染数据和简单一下操作。
不过目前看，找个合适的人重构一下比较靠谱

我写过 1000+行 js 的前端页面, 所以我至今没有被裁～

后端程序写尤其是后台管理系统这种，如果要做多个报表 /charts，很容易写的很大，因为很多后端老哥本身早期也写过模版拼接页面过来，那玩意就真的是拼一下数据对了能跑就行，几千行放一个文件，从前端角度这个需要设计的，譬如剥离在业务代码里面数据处理那层 dirty work，构建前端数据服务层去处理数据，尽量减少去 v 层大量判断和模板处理以及业务代码里面进行大量数据转换处理(譬如根据返回字段来判断权限或者计算金额之类的，本身就可以抽离处理，后续可以进行复用)，构建局部 /总体的数据中心，合理进行分发和传递，业务按照业务逻辑进行拆分，确定好组件间通信手段，这也是我们在改造旧代码的一些经验。