正如玉伯之前说过（阿里前端的困局与突围·Issue#·lifesinger/blog）的，前端只是薄薄的一层，即便是部分业务场景很复杂，也脱离不了前端价值有限，这个我非常认同。
补充：玉伯回答说已经不再认同这个观点玉伯：前端工程师的技术进阶点在哪里?，原因我想是因为蚂蚁金服有一系列前端主导的优秀产品，这些产品更容易被前端创造和开发，有些产品的确需要很深的前端技术。虽然感觉被打脸，但还是特地补充下这个以供大家自己思考，但我的观点不变，我认为除了一些偏技术类产品，绝大部分业务下前端还是很薄的。
一个公司或者业务要盈利或者有用户量才可以存活或者称之为成功。但前端在整个链路中并不是最关键的一环。比如淘宝的最初的成功，是它的模式和货源，当它体量越来越大才会出现专门的前端团队进行用户体验的优化。对于亚马逊，网站做的视觉和效果都远不如淘宝，甚至我同学第一次看像是诈骗网站。但我仍然偶尔在上面购物，因为即便效果再差、加载再慢，它有正品和价格、物流优势，我都可以忍。
所以我个人觉得前端技术再高深，性能再快，对于高度重合的同类竞品间竞争是很有帮助，但并不是业务成功的关键。毕竟一个普通用户不会因为你网站用了React+Webpack+Immutable+Redux而别人网站用了jQuery而选择你。我之前写过的《Angular、Vue、React和前端的未来》也是这个思路。
基于上面这个我个人认为的前提，我觉得前端的技术进阶并不像Java那样，对技术本身有很深度的研究，我个人规划更倾向于选择偏业务性的突破点：
快速学习技术的能力
前端时不时出来很多新东西，然后总是先于当前实现写未来代码，快速学习新事物的能力是最基础的。出来的新东西，能不能快速了解用法、特性、适用场景和底层实现？这是后面的基础。
突破方法：
对新事物保持好奇而非恐惧和抵触，跳出舒适区掌握学习的方法论，比如先看文档、再跑Demo、提出问题、源码验证学习一些学习技巧
业务抽象能力和技术选型、设计能力
一个产品不是一夜建设出来的，但前端可以加速这个过程。使用Node.js可以写一个index.js文件执行下就跑起来一个各种功能的Web服务器，这个时间放在Java可能刚用SpringBoot创建好项目目录？
Electron（或NW.js）、ReactNative、Node.js等产品，都从各种维度为前端赋能可以快速落地业务。比如钉钉，最早桌面端是NW.js写的，如果不通过这种技术框架，客户端招人+多平台开发，成本绝对翻倍，但是调几个前端过来就快速搞完上线了。当这个业务模式得到了市场认证，团队得到扩张，为了性能和更好的体验，开始逐步开发真正Native版本。
所以思考、抽象业务模式特点，基于对已有技术的了解进行选型、组合和设计，能帮助业务快速落地试错，我认为也是工程师进阶要具备的核心能力。
大的案例钉钉上面有说，下面举个前段时间的小需求做例子。由于我目前是做淘宝内容发布器相关的，有一个内容质量打分的需求——即对用户输入内容进行计算并返回分数来给出优化建议，比如图片不要带牛皮癣等，来提升内容质量。
产品上给出的需求是要在发布器端，当用户编辑一个文本或者上传一张图片就实时的显示计算分数，并且点击发布时如果分数较低弹出提示并希望他优化内容再次发布。产品诉求看起来挺合理的，但当你做技术实现推演的时候就会出现一堆问题：
实时性做不到。质量计算算法不可能实时，但就图片而言，带有裁切功能，每次都是新图需要全新扫描而没法缓存，再加上网络请求消耗，计算一次起码是要5-10s。基于实时性的问题，用户编辑完这次可能返回的是上次的分数，而且点击发布时使用的分数可能不是最后的，会带来一系列的错乱问题。而且绝大部分的请求都是无用的，还会带来服务器消耗和性能。基于此设计的交互方案也基本不可行。
这时候如果思考抽象需求本身，以一个闭环来看，这个需求思路有点类似强迫用户按照平台规则进行内容优化和加工。这里面存在一个问题，为什么必须强迫用户提升内容质量而不是用户自己希望编写好的内容？继续挖掘，用户来淘宝写内容，目的非常简单就是赚钱。基于这个核心目的他愿意花时间注册、了解你平台规则跟你玩，那么把高质量内容跟高收益挂钩，使其确定性的正比增加就可以促使用户提升内容质量。
基于这个抽象我给出的技术实现方案：
内容展现前台和渠道等，根据内容质量分等进行流量分配，作为一种计算维度（得知已做）运营端、平台消息、发布器告知用户，这个质量分越高你收入越高（部分已做，补充需求）修改交互变成用户主动触发，而且发布时不做强提醒，减少用户操作成本，让用户意识到好处，抢着去用，而非被迫使用（新需求）
基于这个方案，有一些好处：
帮业务从不可行的开发成本，降到了可以短时间落地，毕竟发个请求展示结果一下就好了由于机器学习和算法的误识别问题，不阻塞、不强迫可以有一些样本进行分析优化，以及验证与收入的正比并做下一步精选案例的推广基于用户反馈和实际效果，做下期迭代或者去掉
这个方案前期业务数据可能并不好看，调用量可能会比较少，而且交互之前的工作要推翻重做。但是沟通了下大家认为这个综合起来还是比较好而且可行的，所以最终选择这个方案来实施。
突破方法：
了解产品设计、用户思维，对业务模式有抽象和思考，可以抓住核心链路进行全链路思考了解运营、产品、交互设计、后端等核心诉求、价值和缺陷，可以打散整体思考、重组产生最佳方案具备沟通能力，毕竟需求重改，业务数据前期不好，交互白做一遍，你要能说服他们
====
前端当然也有很多技术产品或者技术方面可以突破进阶变成技术专家的点，以上只是我个人进阶规划和思考，仅供补充和参考。
再补充下：回答这个问题我认为单纯列举技术方向和具体技术点的人会比较多，不需要太多同质化的回答，所以我从偏业务层面给出一些点作为补充，这样可能会给人比较虚的感觉，没有实质性的指导建议。但就我目前接触的一些前端朋友，做本身技术工作没问题，钻研学习技术也没问题，但是跳不开自己仅仅做『技术执行』的话，可能是阻碍进一步发展的很大障碍。
最后你可能需要足够复杂的业务才能面对这样的挑战，所以有兴趣的可以私信我内推加入我们团队，你懂的。