大前端工程师进阶之路,Node 全栈为前端带来更多可能

简介: 对那些刚入门前端的开发者来说,前端是一个“令人畏惧”的领域,尤其是在你看到前端的技能图谱时,你会发出这样的感叹,前端怎么有那么多的东西要学?我应该从何处学起?我又该如何应对千变万化的前端技术?

导读:对那些刚入门前端的开发者来说,前端是一个“令人畏惧”的领域,尤其是在你看到前端的技能图谱时,你会发出这样的感叹,前端怎么有那么多的东西要学?我应该从何处学起?我又该如何应对千变万化的前端技术?


如何选择?


俗话说,“男怕入错行,女怕嫁错郎”。其实前端开发也一样,从开发工具到前端框架,开发者都面临着选择,选对了技术方向,对个人的职业发展有着举足轻重的作用。由于每个公司在一段时间内可能会固定选用某个框架,如果你刚好没有那个框架的实践经验或学习经历,就会失去一个进阶机会。 再者,不管是在 GitHub、Medium 还是在知乎、掘金上,我们对一个技术或项 目的判断会被点赞数或评论影响,很容易让开发者随波逐流,选择一些跟自己无关或者没用的技术。 因此,开发者在选择框架时,应该从企业需求和个人的爱好找准自己的目标,而不是人云亦云,尽可能选用能提供大面积功能、不需要很多插件来提高生产力的框架来开始你的项目,并根据开发环境的变化,随机应变,而不是广撒网盲目去学。确定学习的目标之后,就开始学习了,你可能在网上看了很多“名人”写的博客,买了很多书,也看了很多教程,在这个过程中,你觉得很充实,但你只是为了学习而学习,你学了,似乎看懂了,但没有真正地记住和消化,但如果你是因为在项目中遇到了问题,然后再去读那些教程,你会比想象中得到的更多。


关于变化


前些天,Node 之父 ry 发布新项目 deno 时,很多开发者都在抱怨——求别再更新了,学不动了。众所周知,历史本来就是不断地以优胜劣汰的方式向前发展,地球也不会因为任何人的不满而停止转动。虽然 Node 很优秀,但我们要明白,一山更比一山高的道理,新技术的出现并不代表旧技术“无能”,而是新技术更能适应生态圈的发展环境,提高开发效率。如果我们一直沉浸在过去取得的成就而停滞不前的话,那么人类就永远不会进步了。 对开发者来说,逆水行舟,不进则退,与其去埋怨别人进步得太快,不如去反省一下是不是自己走得太慢了。最后,祝愿开发者们都找到一条适合自己的路去实现自我价值,甚至改变世界。


前端工程师如何抉择


不想成为全栈的前端不是好程序员。数年以前,全栈工程师的理念忽然风靡墙内外,成为开发者们津津乐道的话题。数年过去,关于全栈工程师的争议不多了,教你速成全栈工程师的视频课程多 了起来,说明大家对于这个理念慢慢接受了。但我发现,鼓吹前端往全栈转型做的有点走火入魔,有的说前端应该成为 K 型人才,甚至部分招聘前端工程师的要求都 写着:熟悉后端至少一门语言和框架,熟悉数据库。过分了啊。 诚然,有了 Node,再加上 JavaScript 大杀四方,前端转型全栈的确是非常顺理成章,但各个语言在各自领域耕耘多年,别说取代,就连取得一席之地都非常难。如果不靠一门语言通打天下,去学习其它领域知识、熟悉领域整个技术生态依然是艰难而缓慢的过程,这难度不亚于转职为其它领域的程序员了。 所以,全栈虽好,也不能贪心啊。


全栈工程师很吊?


对于全栈工程师,社会上的要求真的不高。就像某些人调侃的那样:会一门前端和一门后端就自称是全程工程师了。没错,真的可以。 为什么呢?随着现代大型互联网应用架构越趋复杂,一个人是很难同时精通很多领域的,但如果只是开发小型应用,应对不多的流量,借助开源软件和工具, 一个人也可以办到,这是导致全栈工程师出现的根本原因。 全栈工程师从最开始就是为小型应用而诞生的,想让它解决一切只不过是幻想。


说一说 node 全栈?


Node 现在真的什么都能干,从服务端开发到人工智能、区块链,到处都可以见到 Node 和 JavaScript 的身影。只靠 Node,你似乎都能完成全栈开发了,事实上有些全栈招聘的后端技能就是 Node。但这只是表面现象。 就像上面我说过,各种语言都有他们适合的场景,在追求性能的服务端基础组件、追求高并发高可用的大型系统开发上,Node 还非常稚嫩。比如,最近 OpenResty 的创始人就在微博上对 Node 启动之慢表示惊讶,而这是因为 Node 启动时要加载很多 JS 代码造成的,算是先天缺陷,难以克服。 所以,要想真正开发靠谱的大型系统,Node 还得靠边站。但是,靠着前端的飞速发展,Node 在这种大型系统中也取得了一席之地。 其中,SSR 和 BFF 都需要在后端开发一个中间层,而且这个中间层多半由前端开发和维护,于是使用 Node 成为顺理成章的选择。 其次,在现代的微服务架构中,Node 可以用来开发部分服务,利用在异步 IO 上的优势,在性能上可以满足需求。 除此之外,桌面应用开发上基于 Node 的跨平台方案渐成主流,一些新兴领域也都等待探索,Node 的应用场景还是很丰富的。 所以,我认为的 Node 全栈,是部分优势领域的开发+新兴领域探索,Node 本身并不是一个完整的全栈方案。


K 型人才?


前美团点评的刘平川老师曾写过一篇文章,说前端开发可以一专多能,又叫 T 型人才,这个词其实在职场提的挺多,大家都比较认同。放到前端领域来说, 就是在不同的侧重点、不同的平台上都有开发能力,但同时对某个子领域扎的很深,他们欢迎这样的人才。 然而,前段时间看到这样一段话: ……到了今年,企业开始更注重前端工程师的技术广度。一个优秀的前端,要做到的不仅仅是「T 字型」,而应该努力成为精通前后端至少两门语言的「K 字型」人才。


在大厂,前端晋升靠啥?


在大厂里,工作高度分工,工程师的全栈其实很少有用武之地,晋升要看他们的工作对业务的帮助。 是的,公司要的是业绩,技术的最终价值就应该体现在提升业绩上,这其实是放在任何职业都适合的说辞,只是我们很多时候都忘了。 在对新技术的追逐上,在对采用何种技术的选型上,很多时候我们为了技术而技术,为了让自己不落伍而学习使用新技术,而并没有从是否适合公司业务的角度去考虑。举个例子,去年以来,前后端分离非常火,很多前端打着首屏直出或者 SSR 的理由要做前后端分离。但是你想过吗?增加一个中间层,必然会让响应时间增加,即使需要渲染的页面简单,最少也要增加几十毫秒。另外,如果不能保证中间层的可用性,就变相的增加了系统挂掉的风险。所以,不能盲目的采用新技术。 还有人说,前端离业务太远,根本联系不起来。有的公司可能是这样,前端接触不到业务数据,不知道自己所做的工作给业务带来的影响,更不知道如何去衡量。但前端是数据采集端,其实离数据很近,PV/UV、应用性能数据等至少是可以接触到的吧,通过这些数据,也可以衡量工作的效果。 另外,提升工程效率,制定规范,打造持续集成工作流,也都是能帮助业务的地方。 从提升业务数据的角度去看新技术,才能既让工作获得肯定,也能保持技术上的成长。 当然,这里的新技术要在你负责的岗位职责之内,逾越本分,抢别人的活干,干好了别人不会感激你,活儿干差了则是铁定背锅。


大前端的边界到底在哪里?


端上的开发,Web、移动端、PC 端,这些平台上的开发现在大家基本都认同是大前端的职责了,虽然在具体的工作中会按平台来划分。 工程化,提升工程效能,现在都 DevOps 一体了,其中端上的工作也被认为是大前端的事情。 服务端的开发,Node 全栈,有人认为也是大前端,因为都是用的 JS 嘛。但我 认为不是。因为这样的话,前后端的划分就没有意义了,全栈是全栈,前端是前端。那么,在服务端上,大前端可以做什么? 我认为这要看具体的系统架构,拿现在越来越流行的微服务架构来说,API 网关看似和前端有关,API 的内容是由前端的需求驱动而来,但分析网关需要做的事情,流控、鉴权、熔断、报文转换等等,完全是后端的职责。 但在 API 网关之外,Sound Cloud 的 Phil Calçado 提出的 BFF 架构,其实是可以由前端来负责的,而且也刚好和平台、岗位对应起来,可以当做前端的自留地。在上面 SSR,或者像是由手 Q 开源的 Vas Sonic 框架里的代码 buffer 化这样的骚操作都可以实现。当然,这里一定会遇到高并发、高可用、性能的问题,是需要前端去拓展自己的地方。

目录
相关文章
|
19天前
|
Cloud Native 前端开发 JavaScript
前端开发者必看:不懂云原生你就OUT了!揭秘如何用云原生技术提升项目部署与全栈能力
【10月更文挑战第23天】随着云计算的发展,云原生逐渐成为技术热点。前端开发者了解云原生有助于提升部署与运维效率、实现微服务化、掌握全栈开发能力和利用丰富技术生态。本文通过示例代码介绍云原生在前端项目中的应用,帮助开发者更好地理解其重要性。
52 0
|
23天前
|
JavaScript 前端开发 Docker
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
在使用 Deno 构建项目时,生成的可执行文件体积较大,通常接近 100 MB,而 Node.js 构建的项目体积则要小得多。这是由于 Deno 包含了完整的 V8 引擎和运行时,使其能够在目标设备上独立运行,无需额外安装依赖。尽管体积较大,但 Deno 提供了更好的安全性和部署便利性。通过裁剪功能、使用压缩工具等方法,可以优化可执行文件的体积。
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
|
22天前
|
JavaScript 前端开发 测试技术
前端全栈之路Deno篇(五):如何快速创建 WebSocket 服务端应用 + 客户端应用 - 可能是2025最佳的Websocket全栈实时应用框架
本文介绍了如何使用Deno 2.0快速构建WebSocket全栈应用,包括服务端和客户端的创建。通过一个简单的代码示例,展示了Deno在WebSocket实现中的便捷与强大,无需额外依赖,即可轻松搭建具备基本功能的WebSocket应用。Deno 2.0被认为是最佳的WebSocket全栈应用JS运行时,适合全栈开发者学习和使用。
|
23天前
|
存储 前端开发 JavaScript
前端的全栈之路Meteor篇(四):RPC方法注册及调用-更轻量的服务接口提供方式
RPC机制通过前后端的`callAsync`方法实现了高效的数据交互。后端通过`Meteor.methods()`注册方法,支持异步操作;前端使用`callAsync`调用后端方法,代码更简洁、易读。本文详细介绍了Methods注册机制、异步支持及最佳实践。
|
23天前
|
前端开发 JavaScript 中间件
前端全栈之路Deno篇(四):Deno2.0如何快速创建http一个 restfulapi/静态文件托管应用及oak框架介绍
Deno 是由 Node.js 创始人 Ryan Dahl 开发的新一代 JavaScript 和 TypeScript 运行时,旨在解决 Node.js 的设计缺陷,具备更强的安全性和内置的 TypeScript 支持。本文介绍了如何使用 Deno 内置的 `Deno.serve` 快速创建 HTTP 服务,并详细讲解了 Oak 框架的安装和使用方法,包括中间件、路由和静态文件服务等功能。Deno 和 Oak 的结合使得创建 RESTful API 变得高效且简便,非常适合快速开发和部署现代 Web 应用程序。
|
23天前
|
JSON 分布式计算 前端开发
前端的全栈之路Meteor篇(七):轻量的NoSql分布式数据协议同步协议DDP深度剖析
本文深入探讨了DDP(Distributed Data Protocol)协议,这是一种在Meteor框架中广泛使用的发布/订阅协议,支持实时数据同步。文章详细介绍了DDP的主要特点、消息类型、协议流程及其在Meteor中的应用,包括实时数据同步、用户界面响应、分布式计算、多客户端协作和离线支持等。通过学习DDP,开发者可以构建响应迅速、适应性强的现代Web应用。
|
23天前
|
JavaScript 前端开发 Serverless
前端全栈之路Deno篇:Deno2.0与Bun对比,谁更胜一筹?可能Deno目前更适合serverless业务
在前端全栈开发中,Deno 2.0 和 Bun 作为新兴的 JavaScript 运行时,各自展现了不同的优势。Deno 2.0 重视安全性和多平台兼容性,尤其是对 Windows 的良好支持和原生 TypeScript 支持;而 Bun 则以卓越的性能和简便的开发体验著称,适合快速迭代的小型项目。两者在不同场景下各具特色,Deno 更适合企业级应用和serverless,Bun 则适用于追求速度的项目。
100 1
|
23天前
|
JSON 前端开发 数据格式
前端的全栈之路Meteor篇(五):自定义对象序列化的EJSON介绍 - 跨设备的对象传输
EJSON是Meteor框架中扩展了标准JSON的库,支持更多数据类型如`Date`、`Binary`等。它提供了序列化和反序列化功能,使客户端和服务器之间的复杂数据传输更加便捷高效。EJSON还支持自定义对象的定义和传输,通过`EJSON.addType`注册自定义类型,确保数据在两端无缝传递。
|
23天前
|
前端开发 安全 API
前端全栈之路Deno篇(三):一次性搞懂和学会用Deno 2.0 的权限系统详解和多种权限配置权限声明方式
本文深入解析了 Deno 2.0 的权限系统,涵盖主包和第三方包的权限控制机制,探讨了通过命令行参数、权限 API 和配置文件等多种权限授予方式,并提供了代码示例和运行指导,帮助开发者有效管理权限,提升应用安全性。
|
23天前
|
前端开发 JavaScript API
前端的全栈之路Meteor篇(完):关于前后端分离及与各框架的对比,浅析分离之下的潜在耦合
本文探讨了Meteor.js这一全栈JavaScript框架的特点与优势,特别是在前后端分离架构中的应用。Meteor通过共享数据结构和简化全栈开发流程,实现了前后端的紧密协作。文章还对比了其他全栈框架,如Next.js、Nuxt.js等,分析了各自的优势与适用场景,最后讨论了通过定义文档归属者和用户专有数据集简化后端构建及端云数据同步的方法。