前端工程——基础篇 #10

Open
fouber opened this Issue Aug 26, 2015 · 475 comments

Projects

None yet
@fouber
Owner
fouber commented Aug 26, 2015 edited

喂喂喂,那个切图的,把页面写好就发给研发工程师套模板吧。

你好,切图仔。

不知道你的团队如何定义前端开发,据我所知,时至今日仍然有很多团队会把前端开发归类为产品或者设计岗位,虽然身份之争多少有些无谓,但我对这种偏见还是心存芥蒂,酝酿了许久,决定写一个系列的文章,试着从工程的角度系统的介绍一下我对前端,尤其是Web前端的理解。

只要我们还把自己的工作看作为一项软件开发活动,那么我相信读过下面的内容你也一定会有所共鸣。

前端,是一种GUI软件

现如今前端可谓包罗万象,产品形态五花八门,涉猎极广,什么高大上的基础库/框架,拽炫酷的宣传页面,还有屌炸天的小游戏……不过这些一两个文件的小项目并非是前端技术的主要应用场景,更具商业价值的则是复杂的Web应用,它们功能完善,界面繁多,为用户提供了完整的产品体验,可能是新闻聚合网站,可能是在线购物平台,可能是社交网络,可能是金融信贷应用,可能是音乐互动社区,也可能是视频上传与分享平台……

从本质上讲,所有Web应用都是一种运行在网页浏览器中的软件,这些软件的图形用户界面(Graphical User Interface,简称GUI)即为前端。

如此复杂的Web应用,动辄几十上百人共同开发维护,其前端界面通常也颇具规模,工程量不亚于一般的传统GUI软件:

尽管Web应用的复杂程度与日俱增,用户对其前端界面也提出了更高的要求,但时至今日仍然没有多少前端开发者会从软件工程的角度去思考前端开发,来助力团队的开发效率,更有甚者还对前端保留着”如玩具般简单“的刻板印象,日复一日,刀耕火种。

历史悠久的前端开发,始终像是放养的野孩子,原始如斯,不免让人慨叹!

前端工程的三个阶段

现在的前端开发倒也并非一无所有,回顾一下曾经经历过或听闻过的项目,为了提升其前端开发效率和运行性能,前端团队的工程建设大致会经历三个阶段:

第一阶段:库/框架选型

前端工程建设的第一项任务就是根据项目特征进行技术选型。

基本上现在没有人完全从0开始做网站,哪怕是政府项目用个jquery都很正常吧,React/Angularjs等框架横空出世,解放了不少生产力,合理的技术选型可以为项目节省许多工程量这点毋庸置疑。

第二阶段:简单构建优化

选型之后基本上就可以开始敲码了,不过光解决开发效率还不够,必须要兼顾运行性能。前端工程进行到第二阶段会选型一种构建工具,对代码进行压缩,校验,之后再以页面为单位进行简单的资源合并。

前端开发工程化程度之低,常常出乎我的意料,我之前在百度工作时是没有多少概念的,直到离开大公司的温室,去到业界与更多的团队交流才发现,能做到这个阶段在业界来说已然超出平均水平,属于“具备较高工程化程度”的团队了,查看网上形形色色的网页源代码,能做到最基本的JS/CSS压缩的Web应用都已跨入标准互联网公司行列,不难理解为什么很多前端团队对于前端工程构建的认知还仅停留在“压缩、校验、合并”这种程度。

第三阶段:JS/CSS模块化开发

分而治之是软件工程中的重要思想,是复杂系统开发和维护的基石,这点放在前端开发中同样适用。在解决了基本开发效率运行效率问题之后,前端团队开始思考维护效率,模块化是目前前端最流行的分治手段。

很多人觉得模块化开发的工程意义是复用,我不太认可这种看法,在我看来,模块化开发的最大价值应该是分治,是分治,分治!(重说三)。

不管你将来是否要复用某段代码,你都有充分的理由将其分治为一个模块。

JS模块化方案很多,AMD/CommonJS/UMD/ES6 Module等,对应的框架和工具也一大堆,说起来很烦,大家自行百度吧;CSS模块化开发基本都是在less、sass、stylus等预处理器的import/mixin特性支持下实现的。

虽然这些技术由来已久,在如今这个“言必及React”的时代略显落伍,但想想业界的绝大多数团队的工程化落后程度,放眼望去,毫不夸张的说,能达到第三阶段的前端团队已属于高端行列,基本具备了开发维护一般规模Web应用的能力。

然而,做到这些就够了么?Naive!

第四阶段

前端是一种技术问题较少、工程问题较多的软件开发领域。

当我们要开发一款完整的Web应用时,前端将面临更多的工程问题,比如:

  • 大体量:多功能、多页面、多状态、多系统;
  • 大规模:多人甚至多团队合作开发;
  • 高性能:CDN部署、缓存控制文件指纹、缓存复用、请求合并、按需加载、同步/异步加载、移动端首屏CSS内嵌、HTTP 2.0服务端资源推送

扩展阅读:大公司里怎样开发和部署前端代码?

这些无疑是一系列严肃的系统工程问题。

前面讲的三个阶段虽然相比曾经“茹毛饮血”的时代进步不少,但用于支撑第四阶段的多人合作开发以及精细的性能优化似乎还欠缺点什么。

到底,缺什么呢?

没有银弹

读过《人月神话》的人应该都听说过,软件工程 没有银弹。没错,前端开发同样没有银弹,可是现在是连™铅弹都没有的年月!(刚有了BB弹,摔)

前端历来以“简单”著称,在前端开发者群体中,小而美的价值观占据着主要的话语权,甚至成为了某种信仰,想与其他人交流一下工程方面的心得,得到的回应往往都是两个字:太重。

重你妹!你的脑容量只有4K吗?

工程方案其实也可以小而美!只不过它的小而美不是指代码量,而是指“规则”。找到问题的根源,用最少最简单明了的规则制定出最容易遵守最容易理解的开发规范或工具,以提升开发效率和工程质量,这同样是小而美的典范!

2011年我有幸参与到 FIS 项目中,与百度众多大中型项目的前端研发团队共同合作,不断探索实践前端开发的工程化解决方案,13年离开百度去往UC,面对完全不同的产品形态,不同的业务场景,不同的适配终端,甚至不同的网络环境,过往的方法论仍然能够快速落地,为多个团队的不同业务场景量身定制出合理的前端解决方案。

这些经历让我明悟了一个道理:

进入第四阶段,我们只需做好两件事就能大幅提升前端开发效率,并且兼顾运行性能,那就是——组件化开发与资源管理。

第一件事:组件化开发

分治的确是非常重要的工程优化手段。在我看来,前端作为一种GUI软件,光有JS/CSS的模块化还不够,对于UI组件的分治也有着同样迫切的需求:

如上图,这是我所信仰的前端组件化开发理念,简单解读一下:

  1. 页面上的每个 独立的 可视/可交互区域视为一个组件;
  2. 每个组件对应一个工程目录,组件所需的各种资源都在这个目录下就近维护
  3. 由于组件具有独立性,因此组件与组件之间可以 自由组合
  4. 页面只不过是组件的容器,负责组合组件形成功能完整的界面;
  5. 当不需要某个组件,或者想要替换组件时,可以整个目录删除/替换。

其中第二项描述的就近维护原则,是我觉得最具工程价值的地方,它为前端开发提供了很好的分治策略,每个开发者都将清楚的知道,自己所开发维护的功能单元,其代码必然存在于对应的组件目录中,在那个目录下能找到有关这个功能单元的所有内部逻辑,样式也好,JS也好,页面结构也好,都在那里。

组件化开发具有较高的通用性,无论是前端渲染的单页面应用,还是后端模板渲染的多页面应用,组件化开发的概念都能适用。组件HTML部分根据业务选型的不同,可以是静态的HTML文件,可以是前端模板,也可以是后端模板:

不同的技术选型决定了不同的组件封装和调用策略。

基于这样的工程理念,我们很容易将系统以独立的组件为单元进行分工划分:

由于系统功能被分治到独立的模块或组件中,粒度比较精细,组织形式松散,开发者之间不会产生开发时序的依赖,大幅提升并行的开发效率,理论上允许随时加入新成员认领组件开发或维护工作,也更容易支持多个团队共同维护一个大型站点的开发。

结合前面提到的模块化开发,整个前端项目可以划分为这么几种开发概念:

名称 说明 举例
JS模块 独立的算法和数据单元 浏览器环境检测(detect),网络请求(ajax),应用配置(config),DOM操作(dom),工具函数(utils),以及组件里的JS单元
CSS模块 独立的功能性样式单元 栅格系统(grid),字体图标(icon-fonts),动画样式(animate),以及组件里的CSS单元
UI组件 独立的可视/可交互功能单元 页头(header),页尾(footer),导航栏(nav),搜索框(search)
页面 前端这种GUI软件的界面状态,是UI组件的容器 首页(index),列表页(list),用户管理(user)
应用 整个项目或整个站点被称之为应用,由多个页面组成

以上5种开发概念以相对较少的规则组成了前端开发的基本工程结构,基于这些理念,我眼中的前端开发就成了这个样子:

示意图 描述
整个Web应用由页面组成
页面由组件组成
一个组件一个目录,资源就近维护
组件可组合,
组件的JS可依赖其他JS模块,
CSS可依赖其他CSS单元

综合上面的描述,对于一般中小规模的项目,大致可以规划出这样的源码目录结构:

如果项目规模较大,涉及多个团队协作,还可以将具有相关业务功能的页面组织在一起,形成一个子系统,进一步将整个站点拆分出多个子系统来分配给不同团队维护,针对这种情况后面我会单开文章详细介绍。

以上架构设计历经许多不同公司不同业务场景的前端团队验证,收获了不错的口碑,是行之有效的前端工程分治方案。

吐槽:我本人非常反对某些前端团队将前端开发划分为“JS开发”和“页面重构”两种岗位,更倾向于组件粒度的开发理念,对GUI软件开发的分工规划应该以功能为单位,而不是开发语言;对开发者的技术要求也应该是掌握完整的端内技术。

第二件事:“智能”静态资源管理

上面提到的模块化/组件化开发,仅仅描述了一种开发理念,也可以认为是一种开发规范,倘若你认可这规范,对它的分治策略产生了共鸣,那我们就可以继续聊聊它的具体实现了。

很明显,模块化/组件化开发之后,我们最终要解决的,就是模块/组件加载的技术问题。然而前端与客户端GUI软件有一个很大的不同:

前端是一种远程部署,运行时增量下载的GUI软件

前端应用没有安装过程,其所需程序资源都部署在远程服务器,用户使用浏览器访问不同的页面来加载不同的资源,随着页面访问的增加,渐进式的将整个程序下载到本地运行,“增量下载”是前端在工程上有别于客户端GUI软件的根本原因。

上图展示了一款界面繁多功能丰富的应用,如果采用Web实现,相信也是不小的体量,如果用户第一次访问页面就强制其加载全站静态资源再展示,相信会有很多用户因为失去耐心而流失。根据“增量”的原则,我们应该精心规划每个页面的资源加载策略,使得用户无论访问哪个页面都能按需加载页面所需资源,没访问过的无需加载,访问过的可以缓存复用,最终带来流畅的应用体验。

这正是Web应用“免安装”的魅力所在。

由“增量”原则引申出的前端优化技巧几乎成为了性能优化的核心,有加载相关的按需加载、延迟加载、预加载、请求合并等策略;有缓存相关的浏览器缓存利用,缓存更新、缓存共享、非覆盖式发布等方案;还有复杂的BigRender、BigPipe、Quickling、PageCache等技术。这些优化方案无不围绕着如何将增量原则做到极致而展开。

所以我觉得:

第四阶段前端开发最迫切需要做好的就是在基础架构中贯彻增量原则。

相信这种贯彻不会随着时间的推移而改变,在可预见的未来,无论在HTTP1.x还是HTTP2.0时代,无论在ES5亦或者ES6/7时代,无论是AMD/CommonJS/UMD亦或者ES6 module时代,无论端内技术如何变迁,我们都有足够充分的理由要做好前端程序资源的增量加载。

正如前面说到的,第三阶段前端工程缺少点什么呢?我觉得是在其基础架构中缺少这样一种“智能”的资源加载方案。没有这样的方案,很难将前端应用的规模发展到第四阶段,很难实现落地前面介绍的那种组件化开发方案,也很难让多方合作高效率的完成一项大型应用的开发,并保证其最终运行性能良好。在第四阶段,我们需要强大的工程化手段来管理”玩具般简单“的前端开发。

在我的印象中,Facebook是这方面探索的伟大先驱之一,早在2010年的Velocity China大会上,来自Facebook的David Wei博士就为业界展示了他们令人惊艳的静态网页资源管理和优化技术。

David Wei博士在当年的交流会上提到过一些关于Facebook的一些产品数据:

  • Facebook整站有10000+个静态资源;
  • 每个静态资源都有可能被翻译成超过100种语言版本;
  • 每种资源又会针对浏览器生成3种不同的版本;
  • 要针对不同带宽的用户做5种不同的打包方法;
  • 有3、4个不同的用户组,用于小批次体验新的产品功能;
  • 还要考虑不同的送达方法,可以直接送达,或者通过iframe的方式提升资源并行加载的速度;
  • 静态资源的压缩和非压缩状态可切换,用于调试和定位线上问题

这是一个状态爆炸的问题,将所有状态乘起来,整个网站的资源组合方式会达到几百万种之多(去重之后统计大概有300万种组合方式)。支撑这么大规模前端项目运行的底层架构正是魏博士在那次演讲中分享的Static Resource Management System(静态资源管理系统),用以解决Facebook项目中有关前端工程的3D问题(Development,Deployment,Debugging)。

那段时间 FIS 项目正好遇到瓶颈,当时的FIS还是一个用php写的task-based构建工具,那时候对于前端工程的认知度很低,觉得前端构建不就是几个压缩优化校验打包任务的组合吗,写好流程调度,就针对不同需求写插件呗,看似非常简单。但当我们支撑越来越多的业务团队,接触到各种不同的业务场景时,我们深刻的感受到task-based工具的粗糙,团队每天疲于根据各种业务场景编写各种打包插件,构建逻辑异常复杂,隐隐看到不可控的迹象。

我们很快意识到把基础架构放到构建工具中实现是一件很愚蠢的事,试图依靠构建工具实现各种优化策略使得构建变成了一个巨大的黑盒,一旦发生问题,定位起来非常困难,而且每种业务场景都有不同的优化需求,构建工具只能通过静态分析来优化加载,具有很大的局限性,单页面/多页面/PC端/移动端/前端渲染/后端渲染/多语言/多皮肤/高级优化等等资源加载问题,总不能给每个都写一套工具吧,更何况这些问题彼此之间还可以有多种组合应用,工具根本写不过来。

Facebook的做法无疑为我们亮起了一盏明灯,不过可惜它并不开源(不是技术封锁,而是这个系统依赖FB体系中的其他方面,通用性不强,开源意义不大),我们只能尝试挖掘相关信息,网上对它的完整介绍还是非常非常少,分析facebook的前端代码也没有太多收获,后来无意中发现了facebook使用的项目管理工具phabricator中的一个静态管理方案Celerity,以及相关的说明,看它的描述很像是Facebook静态资源管理系统的一个mini版!

简单看过整个系统之后发现原理并不复杂(小而美的典范),它是通过一个小工具扫描所有静态资源,生成一张资源表,然后有一个PHP实现的资源管理框架(Celerity)提供了资源加载接口,替代了传统的script/link等静态的资源加载标签,最终通过查表来加载资源。

虽然没有真正看过FB的那套系统,但眼前的这个小小的框架给了当时的我们足够多的启示:

静态资源管理系统 = 资源表 + 资源加载框架

多么优雅的实现啊!

资源表是一份数据文件(比如JSON),是项目中所有静态资源(主要是JS和CSS)的构建信息记录,通过构建工具扫描项目源码生成,是一种k-v结构的数据,以每个资源的id为key,记录了资源的类别、部署路径、依赖关系、打包合并等内容,比如:

{
    "a.js": {
        "url": "/static/js/a.5f100fa.js",
        "dep": [ "b.js", "a.css" ]
    },
    "a.css": {
        "url": "/static/css/a.63cf374.css",
        "dep": [ "button.css" ]
    },
    "b.js": {
        "url": "/static/js/b.97193bf.js"
    },
    "button.css": {
        "url": "/static/css/button.de33108.css"
    }
}

而资源加载框架则提供一些资源引用的API,让开发者根据id来引用资源,替代静态的script/link标签来收集、去重、按需加载资源。调用这些接口时,框架通过查表来查找资源的各项信息,并递归查找其依赖的资源的信息,然后我们可以在这个过程中实现各种性能优化算法来“智能”加载资源。

根据业务场景的不同,加载框架可以在浏览器中用JS实现,也可以是后端模板引擎中用服务端语言实现,甚至二者的组合,不一而足。

有关加载框架的具体实现我曾写过很多文章介绍,可以扩展阅读:

这种设计很快被验证具有足够的灵活性,能够完美支撑不同团队不同技术规范下的性能优化需求,前面提到的按需加载、延迟加载、预加载、请求合并、文件指纹、CDN部署、Bigpipe、Quickling、BigRender、首屏CSS内嵌、HTTP 2.0服务端推送等等性能优化手段都可以很容易的在这种架构上实现,甚至可以根据性能日志自动进行优化(Facebook已实现)。

因为有了资源表,我们可以很方便的控制资源加载,通过各种手段在运行时计算页面的资源使用情况,从而获得最佳加载性能。无论是前端渲染的单页面应用,还是后端渲染的多页面应用,这种方法都同样适用。

此外,它还很巧妙的约束了构建工具的职责——只生成资源表。资源表是非常通用的数据结构,无论什么业务场景,其业务代码最终都可以被扫描为相同结构的表数据,并标记资源间的依赖关系,有了表之后我们只需根据不同的业务场景定制不同的资源加载框架就行了,从此彻底告别一个团队维护一套工具的时代!!!

恩,如你所见,虽然彻底告别了一个团队一套工具的时代,但似乎又进入了一个团队一套框架的时代。其实还是有差别的,因为框架具有很大的灵活性,而且不那么黑盒,采用框架实现资源管理相比构建更容易调试、定位和升级变更。

深耕静态资源加载框架可以带来许多收益,而且有足够的灵活性和健壮性面向未来的技术变革,这个我们留作后话。

总结

回顾一下前面提到过的前端工程三个阶段:

  • 第一阶段:库/框架选型
  • 第二阶段:简单构建优化
  • 第三阶段:JS/CSS模块化开发

现在补充上第四阶段:

  • 第四阶段:组件化开发与资源管理

由于先天缺陷,前端相比其他软件开发,在基础架构上更加迫切的需要组件化开发和资源管理,而解决资源管理的方法其实一点也不复杂:

一个通用的资源表生成工具 + 基于表的资源加载框架

近几年来各种你听到过的各种资源加载优化策略大部分都可以在这样一套基础上实现,而这种优化对于业务来说是完全透明的,不需要重构的性能优化——这不正是我们一直所期盼的吗?正如魏小亮博士所说:我们可以把优秀的人集中起来去优化加载。

如何选型技术、如何定制规范、如何分治系统、如何优化性能、如何加载资源,当你从切图开始转变为思考这些问题的时候,我想说:

你好,工程师!


前端工程其实是一个很大的话题,开发仅是其中的一部分。

相关文章:(注: 以下文章还在占坑中, 作者还未完成)

@woaixiangbao

赞!

@leecade
leecade commented Aug 26, 2015

火钳

@ithinco
ithinco commented Aug 26, 2015

💯

@wenyuking

非常赞!

@atian25
Collaborator
atian25 commented Aug 26, 2015

赞,想近距离聆听云龙的教导吗?前排占位招人。 阿里UC移动事业群, 广州

@denvey
denvey commented Aug 27, 2015

非常不错,哈哈,也来一个占位招人,在线旅游行业-淘在路上 放一个校招的宣传 http://tao.117go.com/hiring (手机打开),社招或内推直接发邮件dengwei#117go.com (#替换为@),期待您的到来!

@Galen-Yip

云龙兄 可以着手准备准备fis3

@hacke2
hacke2 commented Aug 27, 2015

太棒了

@zzzJH
zzzJH commented Aug 27, 2015

好棒

@daifee
daifee commented Aug 27, 2015

👍

@2betop
2betop commented Aug 27, 2015

Orz

@webjyh
webjyh commented Aug 27, 2015

赞!

@a044161
a044161 commented Aug 27, 2015

非常好!

@iskl
iskl commented Aug 27, 2015

Zan!

@chenqing

留名

@7demo
7demo commented Aug 27, 2015

@wkyseo
wkyseo commented Aug 27, 2015

膜拜大神,初级前端细细品读

@M-smilexu

mark

@wonsikin

顶礼膜拜

@xufei
xufei commented Aug 27, 2015

很多人觉得模块化开发的工程意义是复用,我不太认可这种看法,在我看来,模块化开发的最大价值应该是分治,是分治,分治!(重说三)。

这句极其赞同

@f2ebill
f2ebill commented Aug 27, 2015

看到民工评价民工

@dylan-lu

mark

@billzbc
billzbc commented Aug 27, 2015

来学习了

@kingzou
kingzou commented Aug 27, 2015

mark

@gliudong

赞!

@wykCN
wykCN commented Aug 27, 2015

MARK

@xiaojiangang

MARK~

@worry127722

受益匪浅

@luqin
luqin commented Aug 27, 2015

👍

@zack-lin

分治,分治,分治!(重说三)。

@YealZoy
YealZoy commented Aug 27, 2015

mark

@ruohuan
ruohuan commented Aug 27, 2015

总结的很赞

@zhouyupeng

棒棒哒

@stoneChen

早前一篇就看了半个多小时,这次又是半个小时,大招威力不凡
学习学习

@polandeme

赞分治的思想,细思极恐

@zhoufanqq

不知道是不是我理解错了?为什么这里面也会有各种无意思的赞,mark,如果真是这么佩服,可以给直接联系博主商量捐款事宜!

@crwinl
crwinl commented Aug 27, 2015

👍

@barretlee

资源表跟阿里的 KISSY 有些相似。不过目前又慢慢转向线下打包。

@luqin
luqin commented Aug 27, 2015

@zhoufanqq 因为都还停留在 jquery 时代

@wych1987

瓶神写的真好。。瓶神我要给你生一堆猴子

@dsxbb
dsxbb commented Aug 27, 2015

超级赞!

@fouber
Owner
fouber commented Aug 27, 2015

@barretlee

应该没有对系统进行表的分治吧,或者没有模板引擎的控制权,实现后端模板中的资源管理

@lifesinger

顶,写得真好!

@lyuehh
lyuehh commented Aug 27, 2015

@think2011

@atian25 是UC吗?

@zerosoul

分而治之~!

@liujb
liujb commented Aug 27, 2015

赞楼主,写的很棒

@itbeihe
itbeihe commented Aug 27, 2015

工程方案其实也可以小而美!只不过它的小而美不是指代码量,而是指“规则”。找到问题的根源,用最少最简单明了的规则制定出最容易遵守最容易理解的开发规范或工具,以提升开发效率和工程质量,这同样是小而美的典范!

不愿意使用一套工具、框架、方法论,就是因为规则太多,跟团队人员习惯的规则差异过大。

@vagusX
vagusX commented Aug 27, 2015

拜读下

@liyunsong

一口气看完了。看的好爽。

@q545244819

受益匪浅!太棒了!

@hupili
hupili commented Aug 27, 2015

透徹!留名!跪請前端高手加盟。 http://initiumlab.com/

@mingelz
mingelz commented Aug 27, 2015

赞!值得反复读。

@iwillwen

雲龍贊一個

@ishenli
ishenli commented Aug 27, 2015

mark

@Asher-Tan

厉害
厉害
厉害

@liaoxiaomei

厉害
厉害
厉害

@young7657

赞,非常好啊

@xiangshouding

后续 工具篇 就应该 FIS 上场了吧。

@Shaw96
Shaw96 commented Aug 27, 2015

怒赞

@sharkrice

这是进入架构师的领域……

@plusice
plusice commented Aug 27, 2015

组件化的目录,components下面把ui组件,css和js模块都放在同一目录会不会有点乱呀

@DeyuanTan

大赞!

@xiangshouding

@plusice 不会乱啊,每个都是一个组件,组件有自己的使命。比如展现的组件,其入口就是那个模板,并不会在某个地方单独调用其内的 js 或者 css。那么你的乱指的是?

@TengfeiQi

大赞!雲龍V5

@okoala
okoala commented Aug 27, 2015

赞!!分治对项目的维护和迭代有着至关重要的影响~

@atian25
Collaborator
atian25 commented Aug 27, 2015

@think2011 是的.

@plusice 是强迫症犯了了吧, 关于目录这个问题, 我也经常纠结, 目前 components目录下是:

- compoments
  - widgets
  - utils
  - pages

可以适当的分类, 但不要太多层级

@plusice
plusice commented Aug 27, 2015

@xiangshouding 我是指或许可以在components下新建两个子目录放js和css模块而已啦,哈

@atian25
Collaborator
atian25 commented Aug 27, 2015

不建议区分js模块和css模块, 按组件的方式去区分即可, 一个组件 = js + css + tpl , 可以缺失任何一个.

@jobslong

@klozelove

你好,我这边是coding.net 觉得写的挺好,正好我们的用户很多都是前端开发者,不知道可否申请在我们的公众号和blog转载?

@plusice
plusice commented Aug 27, 2015

@atian25 嗯嗯,我是指ajax这些js模块,不是组件的js和css。就跟你说的目录一样。

@luchongkang

火钳刘明

@nazhenhuiyi

没这样做过,有一个疑问,像这种用来开发可能很方便。但是,生产环境如何部署这么多零碎的文件呢

@mattlin
mattlin commented Aug 27, 2015

前端太需要这样的文章的了,赞!

@jcpplus
jcpplus commented Aug 27, 2015

方向

@WG-C
WG-C commented Aug 27, 2015

最后的资源表 具体要怎么用?

@sliwey
sliwey commented Aug 27, 2015

赞!目前正在用fis3做尝试,慢慢吸收瓶神的干货,坐等后续文章。

@Horve
Horve commented Aug 27, 2015

期待后面的系列文章

@LingYanSi

布道者

@fatefan
fatefan commented Aug 27, 2015

good!

@Genffy
Genffy commented Aug 27, 2015

文章中的画图的工具是什么,求分享。

@harole
harole commented Aug 27, 2015

深受启发,非常感谢分享

@atian25
Collaborator
atian25 commented Aug 27, 2015

@Genffy balsamiq mockups https://balsamiq.com/

@nazhenhuiyi 源码规范和部署规范是不一样的, 通过FIS这样的工具去连接和构建, 可以去看博主的其他几篇文章

@Coffcer
Coffcer commented Aug 27, 2015

写的非常棒!
把整站的组件和模块都放在components目录里,会不会造成目录爆炸呢

@fouber
Owner
fouber commented Aug 27, 2015

@klozelove 标明出处,欢迎转载

@xiangshouding

@WG-C

我来翻译一下,大概就是说你把你页面上的 link, script 替换成一些后端的接口,比如

index.php

<html>
...
<?php
F::load('a.js');
F::load('b.css');
?>
...
</html>
  • 以 PHP 为例

假设这个静态资源表叫 map.json

map.json

{
  "a.js": {
    "uri" : "/static/a.js",
    "type": "js"
  },
  "b.css": {
    "uri": "/static/b.css",
    "type: "css"
  }
}

那么当页面执行模板 index.php 时,就会执行 F::load 函数加载对应的资源,假设 F::load 函数实现如下。

<?php

class F {
  static public $static = array(
    "js" => array(),
    "css" => array()
  );

  static public function load($id) {
    if (!is_string($id)) {
      return;
    }
    $_map = json_decode(file_get_contents(__DIR__ . '/map.json'), true);
    if (isset($_map[$id])) {
      $res = $_map[$id];
      array_push(self::$static[$res['type']], $res['uri']);
    } else {
      trigger_error('not found resource ' . $id, E_USER_NOTICE);
    }
    return;
  }
}

这样在页面跑完以后就会得到页面的所有静态资源。

当页面抛出给浏览器的时候,可以把收集到的 F::$static 里面的静态资源内嵌到页面中。内嵌的时候可以遵循 js 在 body 后,css 在 head 前的优化规则,或者其他任何地方。

为了简单期间,上面未考虑有依赖的情况。以上只是有后端模板的情况下,如果是纯前端有其他更好的方法。暂时就等 @fouber 慢慢道来吧。

@2betop
2betop commented Aug 27, 2015

@Coffcer 分治还有个手段就是 子系统拆分,博主有提及,后续的文章会介绍这块。

@fouber
Owner
fouber commented Aug 27, 2015

@nazhenhuiyi 构建相关的问题我下一篇文章会介绍,其实我之前写过的文章也多多少少有说过

@klozelove

@fouber 好的,多谢。

@michealzh

感谢分享 (≧▽≦)/

@ginny315

受到很大启发,谢谢分享~

@cpsa3
cpsa3 commented Aug 27, 2015

谢谢分享

@wwsun
wwsun commented Aug 27, 2015

最近一直在做组件化,大神的话,让我对整个项目的技术选型和目前团队做的事有了一个更为深刻的认识。

@whitekyo

mark

@Joeycz
Joeycz commented Aug 27, 2015

mark

@vixony
vixony commented Aug 27, 2015

全面,有深度有高度,好文章。一个系列的。

@tuhaihe
tuhaihe commented Aug 27, 2015

赞,已分享到极客头条:http://geek.csdn.net/news/detail/38202

@simplees

目前才勉强达到第三阶段,任重而道远!

@JasinYip

👍

@keminu
keminu commented Jul 11, 2016

前端初学者,有了一些工程化的概念

@ghost
ghost commented Jul 11, 2016

学习了

@zzzzzyuzhang

牛!!!

@52cik
52cik commented Jul 20, 2016

看了两遍,受益匪浅。
其实前端开发工程化程度之低是有原因的。

现在是互联网泡沫时代,很多初创甚至A,B轮的公司都在大量圈人,是个人就10k+,不管你是不是前端,甚至美工会切图也归为前端,他们的目的只是出产品,任何维护不是他们要担心的问题,因为拿到融资才是他们的目的。

此前,很多所谓的前端,都不知道模块化为何物,更别提 gulp/grunt,webpack 之类的了。
这几年 ng 产品数量也爆发,但技术群里看到的却是项目出来了,chrome还行IE打开要5-10秒怎么优化之类的问题。

一味的追求快,完工了,客户不满意了,才想到调整/优化,,,优化你妹,代码烂的一逼,甚至再次打开后他们自己都要看半天才懂。
网上N多 ng 的优化方案,IE8 也能毫秒级运行,但是有什么用,技术实力上不去,只知道写业务实现。

现在的中小公司不敢说 90%,但至少是 60-70% 都只是 gulp/grunt 打包压缩而已,甚至有 10% 都不知道有这些东西,他们依然页面堆 js,各种功能各种jq插件。

我作为一名中小公司的前端,遇到太多这样的问题了,也想去大公司跟大神们玩玩各种工程化的东西。

@xiaoyu2er

@52cik 想玩前端 联系我吧! 坐标北京, 前端是核心业务!

@spiroo
spiroo commented Jul 21, 2016 edited

@xiaoyu2er 之前我们公司也是跟 @52cik 所说一样,根本不知道模块化为何物,js都是堆出来,但我最近一直在研究前端工程化,sea.js、fis3都用了用,但感觉力不从心,主要是我前端把页面都弄好了,给了后台开发,他们还会自己写一堆js,每天净帮他们怎么写js了,有时候还会产生一些矛盾,感觉推行前端模块化任重道远。

我也想跟大神们玩玩前端工程。

@xiaoyu2er

@spiroo 可以给我发简历哦! 在 github 主页找找, 有我司的官网和我的邮件~

@haledeng

@Thyiad 工程化优化的无非是2个方向:1. 开发效率的问题(包括sass、less等高级语言转化);2. 性能优化策略工具化(打包压缩等)。可能小公司不太重视第2点,而你又不太认同第1点,所有认为无用。

@lenbo-ma

@Thyiad@haledeng 所说,我再补充一点:模块化之后的构建发布效率。

@Thyiad
Thyiad commented Jul 22, 2016

@haledeng 唉,不是不认同,是没有机会深入接触。希望后面能深入接触

@aleen42
aleen42 commented Jul 22, 2016

@Thyiad 所以,个人建议作为一名刚进社会的人,我们应该尽量去争取进大公司接触工程化的东西。创业这事起码等我们打滚了5年 10年,有了top-down 的工程思想才去应用到小企业当中。但如今,很多公司都没有意识到这一点。甚至有的公司,技术人员都非常年轻。

@Thyiad
Thyiad commented Jul 22, 2016

@aleen42 相信也有很多一直在中小公司干的吧,其实什么都折腾挺好的,但是有的东西必须是大公司才有条件支持

@lenbo-ma

@aleen42 我认为和团队以及业务相关性比较大。比如我所在的团队是创业公司,在工程化方面做了很多工作,目前效率提升特别大。

@Jeromezp

赞,学习收藏了

@BerlinChan

我在武汉,这里做Web开发不少企业依照几乎是10年前的方式进行:操作DOM节点、纯服务器端渲染、form表单提交、表情拽拽的把AJAX挂在嘴边说……这正是我身边每天发生的,而我所在的单位推进前端工程化则遇到很多奇怪因素的阻碍。

我最近待的2家企业,一个做自有电商平台,在使用react+redux+webpack短短一个季度后,退回了jQuery+纯服务器端模板引擎时代,原因有两个:新上任领导不会、员工培训跟不上(这两个原因好像是同一个事)。

另外一家单位外包做电商平台二次开发,据称为国内电商系统市场占有率第一,搞了近半年后我已经失望的提辞职。这一回的原因除了前家企业相同的两个原因外,还有个更有意思的:服务器端开发人员怕前端抢了他们的地盘。我最终选择离开是不愿再同整个团队通宵鏖战处理那些静态资源依赖关系,反复迭代内联样式直到! important都用上,最后将糟糕的产品连骗带哄交给客户。

有天周一旁边同事抱怨修改别人的样式和模板好难受,第二天我问他有没有想过如何改变这个问题,他沉默了。

这些事情每天在我眼前重复发生,实在忍受不了,心痛又无语的曾提交一个commit:

d8e4109 Berlin Chan on 16/5/24 at 下午6:07
我已经经过了绝望而变的无可奈何,想要呐喊却又无言。大家都很努力依次处理bug,就像对待每件日常平凡无奇的工作,他们并不着急避免这种事,而是冷静在处理问题中留下更多问题,这种冷静让我感到绝望。
In 5 branches: HEAD, master, develop, origin/master, origin/develop

阮一峰博客里面看到一句话,类似是这样:

在中国你不想骗人不想做坏事,那你就只能去编码了
我是从传统媒体转行做前端开发,之所以转行正是对这句话的充分实践。可是没想到在我这个Web开发圈子的人,让我再同样的失望一回。

近期参加的一些面试,偶尔会碰到有的企业意识到要做前后端分离与前端工程化,而已经深入实践的多为小型创业团队。曾经面试一创业公司,对方问我有没有写过“单元测试”“自动化测试”。后来我没去这家企业,现在想来很后悔。因为如果一个团队会用上这些工具,可见他们对代码质量(至少已经意识到)是如何的重视。

《黑客与画家》前言里面的一个例子:旅游网站Orbitz成功打入竞争激烈的网络订票市场,主要原因就是使用了更好的编程语言。引用这个例子不为说明语言的孰优孰虐,而是说技术选型的结果会直接影响一家企业的兴衰。

小型创业团队要在同一市场与人力财力更强大的企业竞争,技术方案是少有的可以成为优势的因素,当然何其珍贵了!

刚才我的愚蠢而善良的领导召集前后端开发人员开会,总结上一个项目的得出以下经验:

  1. PHP模版中的<{header}>中的内容一定是要公用的静态资源才能放进去
  2. 切图定义样式类只用class属性,后台开发人员只用id属性
  3. JS脚本资源引用,要按照切图静态页的顺序放进去
  4. 表单提交不要用button标签,以防有的服务器端开发人员不知道如何屏蔽submit事件
  5. 所有的JS交互直接写在HTML页中,方便服务器端开发人员定位交互代码

然后演示了服务器端开发人员,将我已经用vue写好前端渲染的页面,重新用JS渲染出来的页面后,获得了在座一致认同——下面就这么搞!服务器端开发人员玩转前端的自豪感难以掩藏挂在脸上(包括我那愚善的领导),殊不知将整个团队拖入泥潭。而我这个习得性无助的人只能淡然视之。在一个封闭的圈子里面,经验和知识是如此的难以取得。若我们失败了,一定是败给了人性的弱点。

若武汉是个稍微封闭地方,但从我面试过一些求职者来看,也许这个范围更为广泛(或是我单位很容易吸引初级开发者)。有2位从北京、上海回来的前端开发,从业4年有余,从交流中得知他们依然看到前端是做一些切图的工作。后来我跟一位优秀的实习生讨论,觉得这是一件多么可怕的事情:呆在一个地方,被蒙蔽了视野。做一个岗位,应当与整个行业同步,而不仅限于跟圈子站在一起。

互联网是如此开放的环境,又有那么多优秀而慷慨的乐于人分享他们的智慧。这是我最喜欢互联网的原因之一,这让“身在小镇,胸怀世界”成为可能,并且能始终与“巨人”们站在一起。做互联网的人是最有资源利用好这一点的人群。

我专职做前端开发的时间不长,短短1年,但从2000年初的个人站长热就开始接触网页三剑客,持续关注Web开发也有十余年时间。当我在报社、门户网站做过记者、摄影师、编辑后,又回到了Web开发领域,看到网页三剑客已衰落至死;看到ES6标准使Javascript拥有更多高级语言的特性;看到NodeJS拓展Javascript程序员的空间;看到npm成为前端开发的大宝库;看到React、Angular这些优秀的JS框架;看到Sass将老旧的CSS焕发新生;看到webpack将Web应用打包的干净优雅……最初看到这些事物的时候,每天都有新东西思考、探索和研究,就如同看到“一个全新的世界”,这也是为什么我喜欢前端开发。

而此时当我还看到有人在操作DOM节点,找“父亲的兄弟的儿子”时,心中着急如猫抓。

上个月我在infoQ的微信公众号看到一篇文章ThoughtWorks前端架构师为AngularJS2布道的文章,还听说他们参与举办了一次武汉前端开发交流会,为武汉Web前端开发圈技术革新的推广付出努力,在武汉真是难能可贵。

希望武汉的Web前端开发圈能够更好,下一份工作我能更优雅的编码。

@myqianlan

@BerlinChan 确实,引导一个团队发展不容易,深有感触

@Ryan724
Ryan724 commented Jul 23, 2016

@BerlinChan 能感受到一些无力感;这也是我恐惧回老家找工作的一个原因~

@ghost
ghost commented Jul 23, 2016

对于还在学校的学生, 有什么好的建议?

@kursk-ye

berlinchan 我也是武汉的,很有同感。但我对现在前端的发展有些疑问,有没有机会当面请教一下。这是我的邮箱,可以联系到我

2016年7月22日 下午4:46,"BerlinChan" notifications@github.com写道:

我在武汉,这里做Web开发不少企业依照几乎是10年前的方式进行:操作DOM节点、纯服务器端渲染、form表单提交、表情拽拽的把AJAX挂在嘴边说……这正是我身边每天发生的,而我所在的单位推进前端工程化则遇到很多奇怪因素的阻碍。

我最近待的2家企业,一个做自有电商平台,在使用react+redux+webpack短短一个季度后,退回了jQuery+纯服务器端模板引擎时代,原因有两个:新上任领导不会、员工培训跟不上(这两个原因好像是同一个事)。

另外一家单位外包做电商平台二次开发,据称为国内电商系统市场占有率第一,搞了近半年后我已经失望的提辞职。这一回的原因除了前家企业相同的两个原因外,还有个更有意思的:服务器端开发人员怕前端抢了他们的地盘。我最终选择离开是不愿再同整个团队通宵鏖战处理那些静态资源依赖关系,反复迭代内联样式直到!
important都用上,最后将糟糕的产品连骗带哄交给客户。

有天周一旁边同事抱怨修改别人的样式和模板好难受,第二天我问他有没有想过如何改变这个问题,他沉默了。

这些事情每天在我眼前重复发生,实在忍受不了,心痛又无语的曾提交一个commit:

d8e4109 Berlin Chan on 16/5/24 at 下午6:07
我已经经过了绝望而变的无可奈何,想要呐喊却又无言。大家都很努力依次处理bug,就像对待每件日常平凡无奇的工作,他们并不着急避免这种事,而是冷静在处理问题中留下更多问题,这种冷静让我感到绝望。
In 5 branches: HEAD, master, develop, origin/master, origin/develop

阮一峰博客里面看到一句话,类似是这样:

在中国你不想骗人不想做坏事,那你就只能去编码了
我是从传统媒体转行做前端开发,之所以转行正是对这句话的充分实践。可是没想到在我这个Web开发圈子的人,让我再同样的失望一回。

近期参加的一些面试,偶尔会碰到有的企业意识到要做前后端分离与前端工程化,而已经深入实践的多为小型创业团队。曾经面试一创业公司,对方问我有没有写过“单元测试”“自动化测试”。后来我没去这家企业,现在想来很后悔。因为如果一个团队会用上这些工具,可见他们对代码质量(至少已经意识到)是如何的重视。

《黑客与画家》前言里面的一个例子:旅游网站Orbitz成功打入竞争激烈的网络订票市场,主要原因就是使用了更好的编程语言。引用这个例子不为说明语言的孰优孰虐,而是说技术选型的结果会直接影响一家企业的兴衰。

小型创业团队要在同一市场与人力财力更强大的企业竞争,技术方案是少有的可以成为优势的因素,当然何其珍贵了!

刚才我的愚蠢而善良的领导召集前后端开发人员开会,总结上一个项目的得出以下经验:

  1. PHP模版中的<{header}>中的内容一定是要公用的静态资源才能放进去
  2. 切图定义样式类只用class属性,后台开发人员只用id属性
  3. JS脚本资源引用,要按照切图静态页的顺序放进去
  4. 表单提交不要用button标签,以防有的服务器端开发人员不知道如何屏蔽submit事件
  5. 所有的JS交互直接写在HTML页中,方便服务器端开发人员定位交互代码

然后演示了服务器端开发人员,将我已经用vue写好前端渲染的页面,重新用JS渲染出来的页面后,获得了在座一致认同——下面就这么搞!服务器端开发人员玩转前端的自豪感难以掩藏挂在脸上(包括我那愚善的领导),殊不知将整个团队拖入泥潭。而我这个习得性无助的人只能淡然视之。在一个封闭的圈子里面,经验和知识是如此的难以取得。若我们失败了,一定是败给了人性的弱点。

若武汉是个稍微封闭地方,但从我面试过一些求职者来看,也许这个范围更为广泛(或是我单位很容易吸引初级开发者)。有2位从北京、上海回来的前端开发,从业4年有余,从交流中得知他们依然看到前端是做一些切图的工作。后来我跟一位优秀的实习生讨论,觉得这是一件多么可怕的事情:呆在一个地方,被蒙蔽了视野。做一个岗位,应当与整个行业同步,而不仅限于跟圈子站在一起。

互联网是如此开放的环境,又有那么多优秀而慷慨的乐于人分享他们的智慧。这是我最喜欢互联网的原因之一,这让“身在小镇,胸怀世界”成为可能,并且能始终与“巨人”们站在一起。做互联网的人是最有资源利用好这一点的人群。

我专职做前端开发的时间不长,短短1年,但从2000年初的个人站长热就开始接触网页三剑客,持续关注Web开发也有十余年时间。当我在报社、门户网站做过记者、摄影师、编辑后,又回到了Web开发领域,看到网页三剑客已衰落至死;看到ES6标准使Javascript拥有更多高级语言的特性;看到NodeJS拓展Javascript程序员的空间;看到npm成为前端开发的大宝库;看到React、Angular这些优秀的JS框架;看到Sass将老旧的CSS焕发新生;看到webpack将Web应用打包的干净优雅……最初看到这些事物的时候,每天都有新东西思考、探索和研究,就如同看到“一个全新的世界”,这也是为什么我喜欢前端开发。

而此时当我还看到有人在操作DOM节点,找“父亲的兄弟的儿子”时,心中着急如猫抓。

上个月我在infoQ的微信公众号看到一篇文章ThoughtWorks前端架构师为AngularJS2布道的文章,还听说他们参与举办了一次武汉前端开发交流会,为武汉Web前端开发圈技术革新的推广付出努力,在武汉真是难能可贵。

希望武汉的Web前端开发圈能够更好,下一份工作我能更优雅的编码。


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#10 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEfjgQg8yz8dx-bENkZc7ZQIMaVLhzoKks5qYINggaJpZM4Fytyr
.

@haledeng

@BerlinChan @kursk-ye 2位,我在武汉,偶尔也同业内的朋友会有线下的meetup,欢迎交流

@kursk-ye

18627100766 这是我的电话,也是我的微信号,能加下我的微信么

我感觉,武汉的技术圈相对比较闭塞,真希望很大家多交流一下。

On Mon, Jul 25, 2016 at 9:16 AM, helondeng notifications@github.com wrote:

@BerlinChan https://github.com/BerlinChan @kursk-ye
https://github.com/kursk-ye 2位,我在武汉,偶尔也同业内的朋友会有线下的meetup,欢迎交流


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEfjgZSz3GT-Iq7x3HyHsyHQhR6QwALLks5qZA5ngaJpZM4Fytyr
.

  此致

敬礼

@dereknex

@kursk-ye 电话就这么发出来真的好吗?注意保护下自已的隐私。

@xjiaoi
xjiaoi commented Jul 25, 2016

手机万年不响了, 求骚扰

在 2016年7月25日,12:06,Derek Chen <notifications@github.commailto:notifications@github.com> 写道:

@kursk-yehttps://github.com/kursk-ye 电话就这么发出来真的好吗?注意保护下自已的隐私。


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/fouber/blog/issues/10#issuecomment-234831740, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APHnOzKo_XeLAuSljEm5eg8m2g92B0xTks5qZDYrgaJpZM4Fytyr.

@kursk-ye

我一直有些关于前端的疑问,发出来望大家不吝赐教

1、node.js让前端工程师的能力扩展到后端,但是J2EE已经发展成熟,SSH框架也深入人心,招聘一个懂SSH的JAVA程序员并不比招一个懂js的程序员更难,甚至更容易——好些声称懂前端甚至号称“full
stack”的前端程序员其实根本就没有掌握前端的一些基本概念和技能,这种情况下,node.js
被广泛宣传和学习,除去IT界喜欢炒作和追求时髦(实际上node也已经不时髦了,最近不又开始鼓吹AngularJS
2么)外,企业这么做的真正需求是什么?node.js相比J2EE的优势是什么?有何必要性用弱类型的JS取代强类型的J2EE功能,还在业务复杂的应用层?

2、最近几年看到很多前端工程师因受到传统J2EE开发模式下后端压榨而奋奋不平,除了后端害怕被前端“抢饭碗”的忧虑,后端和前端冲突的根源在哪里?用fis这种工具,实现了前端工程中性能优化、资源加载(异步、同步、按需、预加载、依赖管理、合并、内嵌)、模块化开发、自动化工具、开发规范、代码部署,是不是就可以完美地解决前端和后端的冲突,使双方从此和睦相处?

3、以一个专业前端的眼光看,传统的J2EE\SSH开发模式或框架会被取代吗,或者说会被前端夺去多少空间?如果前端发展到你所设想的理想状态下,后端J2EE应该如何配置前端,开发模式应该是怎么样的?

On Mon, Jul 25, 2016 at 12:58 PM, xjiaoi notifications@github.com wrote:

手机万年不响了, 求骚扰

在 2016年7月25日,12:06,Derek Chen <notifications@github.com<mailto:
notifications@github.com>> 写道:

@kursk-yehttps://github.com/kursk-ye 电话就这么发出来真的好吗?注意保护下自已的隐私。


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<
https://github.com/fouber/blog/issues/10#issuecomment-234831740>, or mute
the thread<
https://github.com/notifications/unsubscribe-auth/APHnOzKo_XeLAuSljEm5eg8m2g92B0xTks5qZDYrgaJpZM4Fytyr>.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEfjgUSqtXvzO--SyMJq-0GMBtWzyVL6ks5qZEJngaJpZM4Fytyr
.

  此致

敬礼

@ghost
ghost commented Jul 25, 2016

@kursk-ye 无论前端如何发展, 也不能取代后端的吧

@myqianlan

@kursk-ye
简单就你的几个问题说一下我自己的浅薄看法。

1.何为全栈?并不是我说自己是全栈我就是全栈,就好比我说我是周总理你们不信一样,总不能换个说法就信了吧。前端工程师的能力扩展到后端,这并不是一个坏事,放眼全局,才能走好当下,这也会为前后端协作带来益处。nodejs被广泛宣传和学习,一方面肯定是团队宣传做得好,另一方面是nodejs确实为某些场景业务及前端工程化打开了一扇大门。

2.这个问题不是很好作答。因为前端本来就是真正出现不久,并没有一种事实性的标准来界定前端的范围。而是否可以与后端和睦相处,我们留到最后来回答。

3.不会被取代,各有自己的应用场景,或者说能够和谐相处。我所设想的前后端开发模式是,前端能够在绝大程度上掌控视图层,而开发语言并不作限制,比如说JAVA语言的视图层前端也会介入。

总结:前端、后端及其他,本质目标都是为了解决一个事情,而逐步分工出来的,所以不会出现事实性的界定标准。而做这些事情的,都是人,所以关键在人。

@Saviio
Saviio commented Jul 26, 2016

我觉得这里有个歧义点。

一个真正优秀后端会出于什么样的原因会害怕被前端抢饭碗。

工种的区分可不是职业的护城河吧。

@spiroo
spiroo commented Jul 27, 2016

@fouber 有个问题,想请教一下。
比如我有个 导航菜单 组件,其中有3个菜单a,b,c,当在A页面时,菜单a置成选中状态,当在B页面时,菜单B置成选中状态,这种效果用纯前端的方式怎么实现?
谢谢。

@aleen42
aleen42 commented Jul 27, 2016

@spiroo 若是我的话,我首先会想到用 url 传参。也可以尝试一下用History来添加状态,从而实现(虽然我没试过)。

@liushuaicheng

我在思考你怎么可以把文章写的这么好~宝典

@lpreterite

@spiroo 我尝试过解析路由(location.href)来进行处理,实现方法貌似有很多种!

@shisongsong

这个纯前端?是指也不包括js吗

在 2016年7月27日,上午9:22,锦绣未央 notifications@github.com 写道:

@fouber https://github.com/fouber 有个问题,想请教一下。
比如我有个 导航菜单 组件,其中有3个菜单a,b,c,当在A页面时,菜单a置成选中状态,当在B页面时,菜单B置成选中状态,这种效果用纯前端的方式怎么实现?
谢谢。


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #10 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ATd0bKVs5RocrdzcH9uClnApfVdrfl_wks5qZrK6gaJpZM4Fytyr.

@gaokun
gaokun commented Aug 2, 2016

@fouber 你好
文章最后的[相关文章] 链接都指向的本文.

十分感谢这些blog, 受益匪浅!

@twohappy
twohappy commented Aug 2, 2016

不包括js就只能手写了么,A页面给a菜单写一个focus,B页面给b菜单写一个focus

在 2016年8月2日,下午11:27,shisongsong notifications@github.com 写道:

这个纯前端?是指也不包括js吗

在 2016年7月27日,上午9:22,锦绣未央 notifications@github.com 写道:

@fouber https://github.com/fouber 有个问题,想请教一下。
比如我有个 导航菜单 组件,其中有3个菜单a,b,c,当在A页面时,菜单a置成选中状态,当在B页面时,菜单B置成选中状态,这种效果用纯前端的方式怎么实现?
谢谢。


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #10 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ATd0bKVs5RocrdzcH9uClnApfVdrfl_wks5qZrK6gaJpZM4Fytyr.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #10 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AOL3T6c0QamVjZYAOUYq4uG-cn4uRcRPks5qb2H0gaJpZM4Fytyr.

@wy-ang
wy-ang commented Aug 3, 2016

@shisongsong 我很想知道你这样的理解能力,能看懂博主的博文么?人家说的纯前端指的是使用纯前端的技术,不借助后端技术来实现功能。@twohappy 人家都说是导航组件了。你还一个页面一个focus。

@spiroo
spiroo commented Aug 3, 2016

我已经通过给链接中加参数的形式实现了,只是不知道有没有其他的方法,谢谢大家!

@ghost
ghost commented Aug 3, 2016

@spiroo 还可以使用本地存储

@shisongsong

这样啊,不好意思啊,我现在刚开始学,好多概念还不太熟悉

在 2016年8月3日,上午8:20,wyang <notifications@github.com mailto:notifications@github.com> 写道:

@shisongsong https://github.com/shisongsong 我很想知道你这样的理解能力,能看懂博主的博文么?人家说的纯前端指的是使用纯前端的技术,不借助后端技术来实现功能。@twohappy https://github.com/twohappy 人家都说是导航组件了。你还一个页面一个focus。


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #10 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ATd0bNWoQ8Ctfo3ySfOfqYkbIvmBCCaSks5qb97VgaJpZM4Fytyr.

@aleen42
aleen42 commented Aug 4, 2016

@manielng 使用 History.js 中的状态机制去实现,算不算是一种本地存储。可以设计一个状态机,把当前状态及可跳转状态还存在在本地存储中。

@zsjun
zsjun commented Aug 15, 2016

为什么下面的工具,架构,测试,点开都是一样的链接

@Placemaker

很有工程控制论的感觉

@sxgc
sxgc commented Aug 19, 2016

每日一读

@aleen42
aleen42 commented Aug 19, 2016

话说,你们会用GitBook建Blog吗?

@dereksunok

受益匪浅!

@yzxFox
yzxFox commented Aug 23, 2016

前端组件化 这种目录结构。。
对后端语言来说 设置静态资源访问路径是不是一个负担?

@jianghaoran116

我想哭

@kissdook

你好,工程师!

@withJackson

写的特别好

@MrZhang123

非常好的文章,最近在看前端工程化,文章值得细细品读

@keminu
keminu commented Aug 31, 2016

我在广州,也深有同感,很多都是半吊子的前端,然后转后端,以为熟知了前端的一切

在 2016年7月22日 下午4:47,BerlinChan notifications@github.com写道:

我在武汉,这里做Web开发不少企业依照几乎是10年前的方式进行:操作DOM节点、纯服务器端渲染、form表单提交、
表情拽拽的把AJAX挂在嘴边说……这正是我身边每天发生的,而我所在的单位推进前端工程化则遇到很多奇怪因素的阻碍。

我最近待的2家企业,一个做自有电商平台,在使用react+redux+webpack短短一个季度后,
退回了jQuery+纯服务器端模板引擎时代,原因有两个:新上任领导不会、员工培训跟不上(这两个原因好像是同一个事)。

另外一家单位外包做电商平台二次开发,据称为国内电商系统市场占有率第一,搞了近半年后我已经失望的提辞职。
这一回的原因除了前家企业相同的两个原因外,还有个更有意思的:服务器端开发人员怕前端抢了他们的地盘。
我最终选择离开是不愿再同整个团队通宵鏖战处理那些静态资源依赖关系,反复迭代内联样式直到!
important都用上,最后将糟糕的产品连骗带哄交给客户。

有天周一旁边同事抱怨修改别人的样式和模板好难受,第二天我问他有没有想过如何改变这个问题,他沉默了。

这些事情每天在我眼前重复发生,实在忍受不了,心痛又无语的曾提交一个commit:

d8e4109 Berlin Chan on 16/5/24 at 下午6:07
我已经经过了绝望而变的无可奈何,想要呐喊却又无言。大家都很努力依次处理bug,就像对待每件日常平凡无奇的工作,
他们并不着急避免这种事,而是冷静在处理问题中留下更多问题,这种冷静让我感到绝望。
In 5 branches: HEAD, master, develop, origin/master, origin/develop

阮一峰博客里面看到一句话,类似是这样:

在中国你不想骗人不想做坏事,那你就只能去编码了
我是从传统媒体转行做前端开发,之所以转行正是对这句话的充分实践。可是没想到在我这个Web开发圈子的人,让我再同样的失望一回。

近期参加的一些面试,偶尔会碰到有的企业意识到要做前后端分离与前端工程化,而已经深入实践的多为小型创业团队。曾经面试一创业公司,
对方问我有没有写过“单元测试”“自动化测试”。后来我没去这家企业,现在想来很后悔。因为如果一个团队会用上这些工具,可见他们对代码质量(
至少已经意识到)是如何的重视。

《黑客与画家》前言里面的一个例子:旅游网站Orbitz成功打入竞争激烈的网络订票市场,主要原因就是使用了更好的编程语言。
引用这个例子不为说明语言的孰优孰虐,而是说技术选型的结果会直接影响一家企业的兴衰。

小型创业团队要在同一市场与人力财力更强大的企业竞争,技术方案是少有的可以成为优势的因素,当然何其珍贵了!

刚才我的愚蠢而善良的领导召集前后端开发人员开会,总结上一个项目的得出以下经验:

  1. PHP模版中的<{header}>中的内容一定是要公用的静态资源才能放进去
  2. 切图定义样式类只用class属性,后台开发人员只用id属性
  3. JS脚本资源引用,要按照切图静态页的顺序放进去
  4. 表单提交不要用button标签,以防有的服务器端开发人员不知道如何屏蔽submit事件
  5. 所有的JS交互直接写在HTML页中,方便服务器端开发人员定位交互代码

然后演示了服务器端开发人员,将我已经用vue写好前端渲染的页面,重新用JS渲染出来的页面后,获得了在座一致认同——下面就这么搞!
服务器端开发人员玩转前端的自豪感难以掩藏挂在脸上(包括我那愚善的领导),殊不知将整个团队拖入泥潭。
而我这个习得性无助的人只能淡然视之。在一个封闭的圈子里面,经验和知识是如此的难以取得。若我们失败了,一定是败给了人性的弱点。

若武汉是个稍微封闭地方,但从我面试过一些求职者来看,也许这个范围更为广泛(或是我单位很容易吸引初级开发者)。
有2位从北京、上海回来的前端开发,从业4年有余,从交流中得知他们依然看到前端是做一些切图的工作。
后来我跟一位优秀的实习生讨论,觉得这是一件多么可怕的事情:呆在一个地方,被蒙蔽了视野。做一个岗位,应当与整个行业同步,而不仅限于跟圈子站在一起。

互联网是如此开放的环境,又有那么多优秀而慷慨的乐于人分享他们的智慧。这是我最喜欢互联网的原因之一,这让“身在小镇,胸怀世界”
成为可能,并且能始终与“巨人”们站在一起。做互联网的人是最有资源利用好这一点的人群。

我专职做前端开发的时间不长,短短1年,但从2000年初的个人站长热就开始接触网页三剑客,持续关注Web开发也有十余年时间。当我在报社、
门户网站做过记者、摄影师、编辑后,又回到了Web开发领域,看到网页三剑客已衰落至死;看到ES6标准使Javascript拥有更多高级语言的特性;
看到NodeJS拓展Javascript程序员的空间;看到npm成为前端开发的大宝库;看到React、Angular这些优秀的JS框架;
看到Sass将老旧的CSS焕发新生;看到webpack将Web应用打包的干净优雅……最初看到这些事物的时候,每天都有新东西思考、探索和研究,
就如同看到“一个全新的世界”,这也是为什么我喜欢前端开发。

而此时当我还看到有人在操作DOM节点,找“父亲的兄弟的儿子”时,心中着急如猫抓。

上个月我在infoQ的微信公众号看到一篇文章ThoughtWorks前端架构师为AngularJS2布道的文章,
还听说他们参与举办了一次武汉前端开发交流会,为武汉Web前端开发圈技术革新的推广付出努力,在武汉真是难能可贵。

希望武汉的Web前端开发圈能够更好,下一份工作我能更优雅的编码。


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFi3WPdmYvIzllbq0OU_H4it6aWt2iboks5qYIO3gaJpZM4Fytyr
.

@keminu
keminu commented Aug 31, 2016

电话都发出来,小心爆掉

2016-07-25 11:44 GMT+08:00 kursk notifications@github.com:

18627100766 这是我的电话,也是我的微信号,能加下我的微信么

我感觉,武汉的技术圈相对比较闭塞,真希望很大家多交流一下。

On Mon, Jul 25, 2016 at 9:16 AM, helondeng notifications@github.com
wrote:

@BerlinChan https://github.com/BerlinChan @kursk-ye
https://github.com/kursk-ye 2位,我在武汉,偶尔也同业内的朋友会有线下的meetup,欢迎交流


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment), or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEfjgZSz3GT-
Iq7x3HyHsyHQhR6QwALLks5qZA5ngaJpZM4Fytyr>
.

此致
敬礼


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFi3WCGiX_fdwJMrikNfqIU4zaHKvivuks5qZDE1gaJpZM4Fytyr
.

@kursk-ye

谢谢关心,到目前为止不仅没有爆,还交了很多朋友,我自有防护机制

2016年8月31日 下午1:31,"keminu" notifications@github.com写道:

电话都发出来,小心爆掉

2016-07-25 11:44 GMT+08:00 kursk notifications@github.com:

18627100766 这是我的电话,也是我的微信号,能加下我的微信么

我感觉,武汉的技术圈相对比较闭塞,真希望很大家多交流一下。

On Mon, Jul 25, 2016 at 9:16 AM, helondeng notifications@github.com
wrote:

@BerlinChan https://github.com/BerlinChan @kursk-ye
https://github.com/kursk-ye 2位,我在武汉,偶尔也同业内的朋友会有线下的meetup,欢迎交流


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment), or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEfjgZSz3GT-
Iq7x3HyHsyHQhR6QwALLks5qZA5ngaJpZM4Fytyr>
.

此致
敬礼


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10 (comment), or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFi3WCGiX_
fdwJMrikNfqIU4zaHKvivuks5qZDE1gaJpZM4Fytyr>
.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEfjgVPXvmtYU-IyHbN3OKLYMhFbi8Ykks5qlRG4gaJpZM4Fytyr
.

@lpreterite

@keminu 同在广州,这边就职的前端新手还比较多,感觉交流场所比较呢,你有什么推荐?

@chengkj99
chengkj99 commented Sep 12, 2016 edited

前端很多工程实践是由复杂的需求场景倒逼去思考进而实践的,如果没有复杂的业务场景的支撑下,想学习前端工程化实践有什么好的建议吗?

@zunshao
zunshao commented Sep 12, 2016

由徐飞那里跳到这里,受教,十分感谢作者的提点!

@yuanwen0327

受教了!

@wuhao5436

受益良多,感谢!!!

@xujiuhua

受益良多,尝试使用!

@junneyang

分治,分治,分治!(重说三)。

@baipgydx729

mark 学习了

@liuxq liuxq referenced this issue in liuxq/blog Oct 29, 2016
Open

c++小记录 #1

@wxx2258
wxx2258 commented Nov 3, 2016

后面相关文章的链接是失效了吗?

@xiangshouding

@wxx2258

后面文章小编正在酝酿中,敬请期待。

@leofee
leofee commented Nov 4, 2016

受益良多,多谢分享坐等后面更新

@aaawhz
aaawhz commented Nov 7, 2016

好像就是fis3那套思想, 但怎么解决fis3 和 npm规范不是很好兼容问题

@junhey junhey referenced this issue in junhey/studyNotes Nov 10, 2016
Open

前端资料 #7

@zxbetter

请问,文章中黑色风格的配图用什么软件做的呀

@kfny9199

请问你是指的那个?

2016-11-17 14:48 GMT+08:00 devin notifications@github.com:

请问,文章中黑色风格的配图用什么软件做的呀


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#10 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AWIcmWwLY0XC7PlOP0eJtytM317rYOCBks5q-_jIgaJpZM4Fytyr
.

@atian25
Collaborator
atian25 commented Nov 17, 2016

动画的那个是瓶子网上找的, 其他的那些线框图, 都是用 balsamiq mockups

@WEBSFAN
WEBSFAN commented Nov 28, 2016

其他篇幅,怎么是空链接。。。
前端工程——工具篇
前端工程——框架篇
前端工程——架构篇
前端工程——流程篇
前端工程——监控篇
前端工程——测试篇

@muyudou
muyudou commented Dec 17, 2016

膜拜~

@ibegyourpardon

即便是基础教程,隔段时间读一次,也受益良多。

@yhhwpp
yhhwpp commented Dec 18, 2016

赞一个

@Bboy-AJ
Bboy-AJ commented Dec 19, 2016

收获很大,前端工程化有了个基本的认识。

@wupengju

@spiroo 我实现这个是采用的给页面的标签加上特定的页面class或者id来设置指定的初始样式~ 导航会跳转页面 这样就保证页面初始化导航菜单样式了~

@cuikangjie

膜拜 很好的文章

@snailTJ snailTJ referenced this issue in snailTJ/Blog Dec 28, 2016
Open

前端资源大全 #4

@linghuam

搞前端一年多了,正在探索前端模块化工程化知识,无意中发现了这个博客,感觉发现了新大陆,读了几篇文章,让我对前端有了全新的认识。感谢作者写出这么好的文章,他将带领对前端感兴趣的人走上巅峰。

@binnear
binnear commented Jan 2, 2017

受教了~

@52admln
52admln commented Jan 2, 2017

不错,学习了!

@shencyber

最下面那6篇 怎么指向的是 同一篇文章啊

@iwzh
iwzh commented Jan 3, 2017

💯 非常棒

@niugm
niugm commented Jan 6, 2017

大赞,理清了不少思路

@elegantspirit

好文章,受益匪浅~

@AsceticBoy

深度好文!!

@lowguy
lowguy commented Jan 14, 2017

看的我脸都红了,惭愧至极

@hemingming

分析的很好,没有具体实现?

@smallBacteria

学习了

@yeslow yeslow referenced this issue in yeslow/blog Jan 22, 2017
Open

js好文收集 #11

@liruifengv

star,让我对前端有了更全面的认识,任重而道远,努力!

@CapDuan
CapDuan commented Feb 8, 2017

受教了!

@Hancoson

虽然是两年前的文章了,但是现在来看还是非常棒

@wujinsheng

收下我的膝盖!

@lpreterite

最近把es6,和vue相关的支持都用fis3打包到一起了,欢迎围观vfis

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment