58到家周俊鹏:webpack PK fis,实现前端工程化我更喜欢前者

责编:陈秋歌,关注前端开发领域,寻求报道或者投稿请发邮件chenqg#csdn.net。

欢迎加入“CSDN前端开发者”微信群,参与热点、难点技术交流。请加群主微信「Rachel_qg」,申请入群,务必注明「公司+职位」。另可申请加入CSDN前端开发QQ群:465281214。

2016年,SDCC(中国软件开发者大会)相继走进了上海深圳成都杭州各地。11月18日-20日将在北京完美收官。作为大会的重要分专题,前端开发专题已邀请到58到家高级前端工程师周俊鹏担任大会讲师,现场将分享《基于webpack的前端工程解决方案》的主题演讲。

周俊鹏目前主要负责前端工程、前后端分离解决方案的研究探索与开发工作,是58到家前端工程解决方案boi开发者。会前有幸采访他,采访中对比分析了几款主流前端构建工具,及借助工具构建前端工程解决方案的诸多经验心得

受访嘉宾介绍

58到家高级前端工程师周俊鹏

周俊鹏,现任58到家高级前端工程师,曾就职于携程网、优酷网,着力于Web应用层架构,前端工程化和中间层的研究,对webpack的使用拥有丰富经验。

CSDN:首先请您做下自我介绍,目前所从事的工作及主要专注哪些技术领域。

周俊鹏:大家好,我叫周俊鹏。目前就职于58到家前端团队,负责前端工程、前后端分离解决方案的研究探索与开发工作,58到家前端工程解决方案boi开发者。主要的研究方向是Web应用层架构,包括前端工程化和中间层。

CSDN:以您最近参与的一个项目为例,谈谈它的前端基础架构是怎样的?

周俊鹏:以58到家微信钱包首页为例,此项目属于重构项目,需要解决的问题包括:提高首页渲染速度,提高用户体验、解决前后端分工不明确导致的开发周期延长和上线流程繁琐等问题。

  • 基础架构:前端技术选型为Vue+CommonJS,使用boi搭建开发环境。UI的渲染由前端(Vue)实现,后端只提供数据API。CommonJS作为模块化方案。首屏以外的资源全部按需加载。用户进入页面只加载首屏的资源,首屏UI渲染完毕之后或者用户scroll到页面底部时触发次屏资源的加载和渲染,以此类推。
  • 架构亮点:从开发角度来讲,前后端分离的模式缩短了开发周期,同时分工明确也提高了Bug修复效率和维护效率。从用户角度来讲,虽然前端渲染不如后端渲染的效率高,但目前市场上的主流移动设备上这个差距并不明显。

首屏以外的所有资源按需加载,减少了页面初始资源体积,加快了首屏渲染;再加上图片资源懒加载以及客户端的缓存合理使用,使首屏能够尽快展现在用户面前。感兴趣的同学可以阅读这篇文章《前后端分离和模块化-58到家微信首页重构之路》查看更多细节。

CSDN:请简单评价下当前主流的几款前端构建工具,在您看来,webpack有哪些优势与不足?

周俊鹏:我个人认为目前市面上的前端构建工具可以与webpack在一起讲的只有fis。就当前时间节点(2016年末)的话,我个人更喜欢webpack。

其实我认为fis并不是单纯的构建工具,而是一整套前端工程化解决方案。fis的工作流程和配置非常优雅,与webpack相比更语义化,更符合前端开发者的常规认知。比如不同类型资源区分配置、资源定位等。

如果非要说fis有什么缺点的话,首先,相比webpack,fis更“大而全”,可扩展能力稍弱;其次,对项目代码有一定程度的“绑架”,比如CSS Sprite功能需要在代码书写特殊标识、HTML中需要以注释的方式声明依赖等;最后,前端技术发展是非常快的,fis对一些较新的技术和框架支持度不是很理想,比如Vue和React。但总体来说,我认为fis是一套非常优秀的前端工程解决方案。

相比fis,webpack则更专注于构建。我刚接触webpack时非常不习惯。所有资源以JS为编译入口、CSS必须使用插件导出独立文件、HTML只能反向inject静态资源等等。webpack的工作模式是对组件化和SPA的绝对推崇,所有的静态资源集成在一个组件JS文件里,我认为这确实是未来的发展方向。但就目前(2016年末)来说,起码国内的大多数Web应用还没有做到这一点。

那既然webpack这么“反三观”,为什么还觉得它好呢?我认为webpack的优点远大于它的模式带来的“不便”:

  • 虽然webpack的工作模式有点“怪异”,但它的配置功能和扩展能力非常出众,而且相比fis,webpack更专注于构建本身,开发者有很大的空间去改造和扩展;
  • 与前端的新技术高度融合,比如Vue、React、Angular(这些框架也是组件化的典范,与webpack的理念有共通点)等,并且与之对应的loader或plugin是官方或者框架作者推出的,并非“来路不明”的第三方提供;
  • 生命周期非常优雅,compiler和compilation拥有各自的生命周期,并且几乎每个阶段都暴露了钩子函数,非常利用扩展;
  • 社区力量庞大。这意味着遇到问题时,能够得到更多人的意见和帮助。这一点来讲,fis与webpack的社区力量不是一个量级的。

当然,webpack的优点远不止我所说的这些。最后不得不吐槽一下webpack的文档实在是太“抽象”了,哈哈,在开发boi的过程中,很大一部分时间是在研究webpack的源码。

CSDN:请描述一下58到家以webpack为核心搭建的前端工程解决方案。

周俊鹏: boi是一整套前端工程解决方案,构建功能以webpack为核心,同时提供脚手架、远程部署、Mock服务等。支持多页面开发,并且提供环境配置功能,开发者可以分别针对测试环境和生产环境进行独立的构建和部署。支持自定义前端缓存策略(hash/query)、自定义代码规范以及多种模块化方案(ES6 Modules/CommonJS/AMD)等。

另外,boi已经与云平台集成,配合测试沙箱,这一整套架构覆盖了项目的起始、构建、部署、测试和上线各个环节。详细的方案会在演讲中展示。

CSDN:您觉得构建前端工程解决方案的难点在哪里?58到家在构建过程中做了哪些尝试与探索。

周俊鹏:我认为前端工程解决方案的难点在于:你永远不可能收集到所有的功能需求。所以开发者往往需要很长的前期预备时间,这部分时间一是用来设计框架的基础架构,二是尽可能全面的收集需求,三是进行详细的技术选型和评估。

但是框架或者工具不可能百分百的解决业务开发中的所有需求,这就造成了团队投入了大量的时间和精力去开发框架或者工具,开发完成之后,一方面已存的项目迁移需要时间成本和风险控制,另一方面框架可能并不能解决新的需求,而且团队成员还需要一定的学习成本。也就是说,花费大量成本开发的框架在短时间内很难对团队有质的提升,加上创业型公司的业务需求量大,开发周期短,更加不允许浪费时间和精力做纯粹的技术立项。

58到家前端团队在立项boi之初便确立了这样一个原则:先解决从0到1的问题,再解决从1到100的问题。以季度为迭代周期,boi一期提供的功能都是具体项目中遇到的需求,没有任何冗余。作为boi的开发者,我个人肯定是有雄心壮志将其做大做强,但是boi是面向所有团队成员的,必须从团队的需求出发,将成本控制到最小。此外,框架对于使用者来说是一个黑盒,使用者接触的有且仅有配置API,所以不管后期迭代多频繁,必须保持已有配置API的一致。

CSDN:对于希望构建自己前端工程解决方案的企业,您有什么建议?

周俊鹏:算不上建议,就根据自身的经验说几点不成熟的观点吧。首先,在立项构建自己的前端工程解决方案之前要调研市场上已有的同类型产品是否可以解决团队需求,思考一下自己团队是不是真的需要自己构建方案。如果确定立项,在投入开发之前需要确定一下几方面:

  • 可投入的时间和人力成本;
  • 尽量全面地列出团队目前的功能需求;
  • 不要“高瞻远瞩”,第一版解决方案只针对当前需求,目的是让团队成员尽快过渡到新方案。更全面的功能在迭代中实现。

最后一个意见,也是程序员们口口相传的一句话:不要重复造轮子。如果把一整套的解决方案比作一辆车,那实现各个环节的功能模块就是一个个轮子。在保证稳定性和可用性的前提下,功能模块尽量选择稳定的已有模块。

CSDN:面对技术的快速迭代,您是如何保持自己不断成长的?您对新人有什么建议?

周俊鹏:这几年前端技术的发展速度非常惊人,夸张点说,感觉打个盹醒过来就落后了。但我个人认为,不论怎么发展,技术的根源都离不开计算机的基础知识体系。不论出什么新框架、新技术,底层的原理其实都在学校教材里黑纸白字写的明明白白。并且,前端的很多“新”的技术,很大一部分是将一些“老”概念搬到了前端,比如,从Backbone到Angular吸取了MVC的概念模型,目前火热的MVVM在WPF中早已司空见惯。上学的时候老师们经常说的一句话,万变不离其宗,基础知识才是重中之重。

所以,对于新人的建议是:不要被浮躁的环境影响,学好基础知识。

近些年,随着前端的水涨船高,出现了很多“前端框架使用工程师”,专注于一个框架是好事,但是不能局限。工作至今,我经历过很多面试,也面试过很多应聘者,遇到过面试只问框架的面试官,甚至电面的时候第一句话就问用没用过XX框架,如果回答没有就直接拒绝。但是,在面试应聘者时,除非应聘者简历明确写了“精通XX框架”,否则我是不会问框架相关的具体问题的。我始终认为,框架也好,前端也好,都只是计算机从业者的一个应用能力而已,风向随时都可能变,风来了,吹走的只是屋顶的瓦砾,而高墙屹立不倒。

CSDN:11月18日,在SDCC 2016前端开发专题上,您分享的话题是?听众将通过该演讲获得哪些收益?

周俊鹏:我的分享话题是《基于webpack的前端工程解决方案》。首先总结一下前端开发中的痛点和前端工程化要解决的问题;然后分析webpack的特点以及在前端工程化中的定位,根据webpack能够解决和难以解决的问题引出58到家在前端工程化方面的探索和实践;最后简单聊一聊我个人对于前端工程化未来发展的一点理解。

我希望大家能够从58到家前端工程化的探索和实践过程中吸取一定的经验,对打造自己的前端工程解决方案有所帮助。同时,58到家对webpack的使用经验希望能够帮助大家更大化地发掘webpack的功能和潜力。

相关文章:

Stackla前端团队Leader蒋定宇:国外前端开发者的别样人生



目前SDCC 2016前端开发专题的所有演讲嘉宾已全部确定,以下为嘉宾名单及演讲议题(排名不分先后),详情请见:SDCC 2016前端开发专题讲师、议题大揭底

  • Stackla前端团队Leader蒋定宇

    • 演讲主题:不断归零的前端人生
  • QQ音乐&全民K歌高级工程师袁聪
    • 演讲主题:全民K歌React Native最佳实践
  • 饿了么Node Team负责人黄鼎恒
    • 演讲主题:纯手工搭建一个高性能实时监控系统
  • 360奇舞团前端工程师钟恒
    • 演讲主题:使用Vue.js 2.0开发高交互Web应用
  • Ruff架构师、JavaScript专家周爱民
    • 演讲主题:有前端思想的物联网系统架构
  • 58到家高级前端工程师周俊鹏
    • 演讲主题:基于webpack的前端工程解决方案

想与这些专家现场面对面进行技术探讨吗?目前SDCC 2016大会门票8折销售中,团购更有优惠,是给辛勤工作一年的你,年终最好的礼物,或许这样,SDCC才能更真切地服务好开发者。【注册参会

时间: 2024-12-04 14:28:35

58到家周俊鹏:webpack PK fis,实现前端工程化我更喜欢前者的相关文章

高德LBS+的勾搭之下 58到家劈腿阿里?

昨日,高德与58到家宣布达成全面合作,这是既神州租车之后,高德LBS+平台引入的又一巨头明星级合作伙伴.如今看来,去年曾宣布放弃O2O的高德,实际却在变向加大对O2O市场的投入,竟能让腾讯系的58到家无视四维图新而选择投身阿里系的高德,这是有多大的吸引力? 放弃自建O2O后,高德显得对O2O更有兴趣 去年俞永福接管高德之后突然宣布放弃O2O业务时还曾引起了不小的争论,在全民皆O2O的时代,高德竟然主动放弃O2O着实有些让业界惊讶.但后来高德的实际行动却显示,其并非彻底放弃O2O,只是换个形式,放

58到家合并了嘟嘟美甲,仍需直面三大隐忧

据21世纪经济报道,58到家于2月17日合并美甲O2O平台嘟嘟美甲,虽然双方并未透露收购费用明细,但已有行业人士告知媒体本次并购价格仅花费数百万元人民币.根据媒体报道资料来看,并购后双方将对美甲业务进行整合,使得美甲师.美甲样式.美甲工具等方面进行资源和58到家原有O2O业务实现打通. 至此,这个曾获千万美元A轮融资的O2O项目正式落幕,走完了其短暂但并不锦绣的一生. 用户留存率决定O2O生存机会 从辉煌的O2O征程到低廉价格的并购结局,嘟嘟美甲和大多其他不具备长久生命力的O2O一样,依移动互联

周衍鹏个人简历

周衍鹏个人简历 个人资料 姓 名:周衍鹏                                    婚姻状况:未婚 出 生:1990/10/19                          政治面貌:团员 性 别:男                                           民族:汉 学 位:本科                                       移动电话:13635456575 专 业:机械设计制造及其自动化     电子邮

从0开始做垂直O2O个性化推荐-以58到家美甲为例

从0开始做垂直O2O个性化推荐 上次以58转转为例,介绍了如何从0开始如何做互联网推荐产品(回复"推荐"阅读),58转转的宝贝为闲置物品,品类多种多样,要做统一的宝贝画像比较难,而分类别做宝贝画像成本又非常高,所以更多的是进行用户画像.分类预测推荐.协同过滤推荐等个性化推荐. 有些同学反馈,他们的产品是垂直类的O2O产品,分类单一,可以简单的实现宝贝画像,这类垂直O2O产品怎么从零开始做个性化推荐呢?这是本文要讨论的问题 一.58到家美甲简介 58到家有三大自营业务"家政&q

58到家入驻微信钱包的技术优化

一.需求缘起 大伙打开微信钱包,会发现58到家入驻了微信钱包的一级入口(如下图),这个入口流量极大,微信要求被接入的H5必须能抗住n万的qps(58到家的系统是偏交易的系统,虽然一天100w订单其实也没多少请求),这是之前的业务系统没有遇到过的,要抗住这个n万的qps的优化思路是怎么样的呢? 这里做一个思路分享,希望能对业界同仁有启示作用. 二.业务分析 在微信钱包里,点击进入58到家,会发现其实是一个类别落地页,根据不同城市开通的服务类别,展示不同类别的入口(如下图). 很容易想到,整个架构与

[转]基于gulp和webpack的前端工程化

本文样例代码 :https://github.com/demohi/learning-gulp 本文主要简单介绍一下基于gulp和webpack的前端工程化. 技术栈 React.js reFlux Node.js 我们的需求 基于CommonJS模块化开发 基于React.js的组件化开发(JSX) 为保证组件的复用,css需要打包到js中 有国际化需求,静态文件需要部署在CDN上面 工程化工具的选择 gulp(基于stream的构建工具,与grunt相比,速度快且可编程) webpack(前

58到家数据库30条军规

军规适用场景:并发量大.数据量大的互联网业务 军规:介绍内容 解读:讲解原因,解读比军规更重要 一.基础规范 (1)必须使用InnoDB存储引擎 解读:支持事务.行级锁.并发性能更好.CPU及内存缓存页优化使得资源利用率更高 (2)必须使用UTF8字符集 解读:万国码,无需转码,无乱码风险,节省空间 和DBA负责人确认后,纠正为"新库默认使用utf8mb4字符集". 这点感谢网友的提醒,utf8mb4是utf8的超集,emoji表情以及部分不常见汉字在utf8下会表现为乱码,故需要升级

58到家数据库30条军规解读

此篇文章来源于微信公众号[架构师之路],为了帮助记忆,现在抄写与此,如有侵权,告知立刻删除,谢谢! 军规使用场景:并发量大.数据量大的互联网业务 基础规范 必须使用 InnoDB 存储引擎:支持事务.行级锁.并发性能更好.CPU及内存缓存页优化使得资源利用率更高 必须使用 UTF8 字符集:万国码.无需转码.五乱码风险,节省空间 数据表.数据字段必须加入 中文注释 :好记忆不如烂笔头 禁止 使用存储过程.视图.触发器.Event:高并发大数据的互联网业务,架构设计思路是"解放数据库CPU,将计算

<转载> 58到家数据库设计规范

原文地址: http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959906&idx=1&sn=2cbdc66cfb5b53cf4327a1e0d18d9b4a&chksm=bd2d07be8a5a8ea86dc3c04eced3f411ee5ec207f73d317245e1fefea1628feb037ad71531bc&mpshare=1&scene=23&srcid=021695B