2017年，包括非前端技术在内，总结了前端工程师所接触的Web技术

由于2017年即将结束，我想简单地记录一下今年接触过的技术，也兼作给自己的备忘录。

对于前端技术，我大致上都使用了现代化的工具。但对于其他方面，情况并不一样。所以，我打算明年以后将自己感觉过时的技术进行迁移，同时也要总结一下想要尝试的技术。

顺便提一下，今年在GitHub上可见的活动大概是这个样子。我写了一些代码。

技术分类

暂时先按以下方式进行分类。还有一些相对较多的其他选项。

• Webフロントエンド

 

• Webバックエンド

 

• その他Node周り

 

• インフラ / ミドルウェア

 

• Webサービス(クラウド周り)

 

まとめ

网页前端

框架周边

今年も去年に続き、私は主にVue.jsを中心にコーディングする機会が多かったです。私の体感では、Vue:React:Angularの比率は大体7:2:1でした。他のフレームワークも少しずつ触れる機会がありました。有名なフレームワークとしては、以下のものに一応触れてみました。

• Vue.js

 

• React

 

• preact

 

• Angular

 

jQuery

我从来没有碰过AngularJS，但是有过接触jQuery的机会。
尽管用于构建严谨的Web应用程序所需的技术在变化，但用于简单地在网页上使用的jQuery仍然有着很强的需求。

就算从现代的角度来看，我从来没有接触过Mithril、Riot和Svelte。我个人认为这只是因为这些对我来说不适合，并且在工作中，由于缺乏足够成熟的社区，它们也无法稳定地使用。

由于Vue的使用率不断增长，且它易于入门，因此需求也很高，所以除非明年有新的东西出现，否则Vue很可能仍然是基础。我自己也是属于这个社区的一员，而工作量也非常大。

关于Nuxt.js.

我认为今年在框架领域最大的改变是基于Vue.js的前端开发框架”Nuxt.js”的增长。

Vue.js不仅包含了用于独立开发的所有困难之处，还附带了SSR功能。它还配备了所谓的中间件，可根据访问情况修改请求内容，并能将Vue应用程序导出为静态网站。这就像一个梦一样的框架。

我个人认为，这是目前前端开发中最好的选择，也是最值得使用的。

开发环境周围

最近我用了Webpack做了一些东西。即使在创建库的时候也使用了Webpack的UMD格式，而没有用到Rollup。
最近很流行的Parcel，我虽然尝试了一下作为兴趣爱好，但还没有在实际运用中使用过。这就是我的印象。
尽管现在有些人提倡不使用Webpack，但我认为如果对Webpack和适当的插件有很好的理解，没有享受到Webpack强大好处的开发是毫无意义的。就这个意义上说，我对象把Webpack包装起来并且让我能够轻松使用的egoist/poi抱有希望。

在babel的使用中，除了preset-env、vue-app和react-app，几乎不再使用其他框架作为基础。根据需要可能会添加flow或插件，但es2015和stage-x已经完成了它们的任务。

类型系统等

我基本上只使用Flowtype。對於Angular，我不得不使用TypeScript，但我認為沒有必要放棄針對JS的強大支持工具而使用TS。

个人对于这个问题并没有太浓厚的兴趣，所以并没有深入研究，但是使用Flow工具可以自动生成代码，享受s2s工具的好处，所以实际上有试用s2s的动力。不过，可能只是业余使用而已。

代码格式

使用ESLint遵循StandardJS标准，以prettier（+prettier-eslint）格式自动化工具完成了整体代码格式的最终调整。

由于人工进行JavaScript代码格式化的时代已经结束，现在连服务器端都是用这个方法进行。不过，对于.vue文件来说，虽然没有完全掌握，但还是在借助ESLint尽力自己修复。

网页后端

我原本是一位PHPer，也同时在兼顾前端工作时学习Node.js。因此，我自然而然地发展出适应这两方面的技能组合。

PHP相关

PHP没有特别大的变化。一如既往地使用Laravel或CakePHP3，或者纯PHP进行开发。

• 既にあるWebサービス

 

• 書き捨てスクリプト

 

• エンドポイントの少ない軽いView付きのSQLと接続をするWeb UIの開発

 

軽いWebサービス開発

今年我一直在某一方面上使用它，在编写服务器端的时候它总是陪我一起战斗。这个社区拥有各种现代和古旧的资源，这些资源对我总是帮助很大。明年我也打算继续把它作为我们后端开发的主语言使用。

学习PHP只了解了7.1和7.2版本的相关信息，似乎没有了解其他版本的内容。虽然表达了想要使用名为Peridot的BDD测试框架，但却没有使用，所以明年打算使用。

Node.js

节点.js

我觉得我只是不断地写下来。在Web后端的环境中，我创建了符合API规范的模拟API服务器、Bot服务器、轻量级API服务器和代理服务器等，一旦完成了任务就将它们关闭。另外，我偶尔也需要编写Lambda或GAS来进行Bot操作。

基本上，我們大多數情況下只需使用Express來簡單地完成工作，即可結束！ Bot伺服器和輕量級API可以正確接收端點並且容易建立，只要每個端點互相疏散即可，模擬伺服器則在真實伺服器完成後就可以作廢了，儘管這樣做對於短促的時間來說可能不夠，但這是為了在需要的時候能夠快速捨棄不可或缺的內容。

因为感觉Node.js没有好用的ORM，所以除了写一些零碎的代码以外没有其他用途，这导致了我完全没有动力去用它来开发正式的Web后端。另外，我也是一个关注关系型数据库的爱好者，对于NoSQL技术来说无法想象如何正常运营数据库。而且，因为几乎没有公司使用Node.js来进行正式运营的Web服务，也没有迫切的需求去学习和使用它。

心中仍然心有余悸，今年最終結果還是Express佔了大部分的工作，並沒有真正使用fastify的機會。雖然已經走到了實際運用的一步之前，但明年還是想要使用它。對於koa沒有動力。只有在非常基本的情況下偶爾使用micro，但那個工具太嚴苛了。

红宝石 shí)

今年又出现很多类似的情况，比如说刚接了前端的工作，结果又得在后端用Rails稍微修修改改的。

由于不知道 railstutorial 之外的内容，因此我想在某个地方尝试自己管理服务器，所以只是开始使用 API 模式进行建设而已。

从只了解Rails 4.x的状态开始，同时学习5.x的webpacker / API模式技术，以便更好地理解从4到5的升级过程，这是相当具有挑战性的。

个人认为，我认为Webpack在后端和前端之间应该是松散耦合的，所以我没有动力去使用它。

关于Node.js的其他事项

总结一下今年关于与Node相关的一些事情吧，因为它在前端和后端都是必需的，并且通过创建和发布npm模块可以在两者之间共用，所以这样做是非常有利的。

关于Node.js和babel的事项。

尽管Node在过去一年中显著地迈进了，包括引入了async/await等功能，但我个人认为处理ES模块的方式是最不方便的。由于被迫使用.mjs格式进行模块加载，因此我已经放弃了在编写Node.js时直接写代码的选择。

在开发npm模块时，以及开发后端时，都必须使用babel作为必要的工具。为了方便使用Flowtype在npm模块开发中，我也准备了适用于自己的模板。

对于直接使用Node核心的方式，我在遇到.mjs文件之后变得更加怀疑了。

版本发布仍然使用ES5。

npm模块的发布仍然使用ES5。对于前端的模板项目，很多都不太了解，因此在webpack.config.js中设置exclude: node_modules的模板非常多，这导致必须将代码转译为ES5。

由于这一趋势可能会持续下去，所以前端使用的库似乎会一直以ES5编写。

基础设施/中间件

证书方面等等

基本上，由於大部分的雲端服務已經幫忙處理了證書的事情，所以自己處理證書的情況非常少見。但前幾天有個機會，我久違地又嘗試了一下，才發現使用Let’s Encrypt取得證書變得非常簡單。
搞不好以後使用certbot可能會成為預設工具，感覺上進化了。

如果过于依赖云，就会自然而然地无法掌握基础设施的变化，所以确实很困难，但我认为在不久的将来我不会在这里投入赌注。

网络服务（云端相关）

总之，AWS和Heroku是主要的选择。

平台即服务

如果想要在临时运行服务器上运行某些东西，基本上除了应用的生产环境，我几乎都使用了Heroku。它基本上是免费的，并且几乎可以运行任何技术，是风险投资支持的，并且内部使用了AWS，另外还可以在测试环境中免费使用RDB或Memcache等等。还有Review Apps的存在，今年它在我的工作中表现出色。总之，能在Heroku以外的服务上运行审查环境或内部工具的选项基本上是不存在的，至少对我来说。当然，如果已经有一个IaaS服务器用作验证环境，那就另当别论。

虽然我也看过IBM Bluemix和now.sh，但我没有将其用于生产的程度。

本番环境基本上大部分使用AWS，不仅限于PaaS。虽然也有在GCP上使用过GAE，但与主要的后端PHP相兼容性较差，虽然曾经在生产环境中使用过，但很快就停止使用了。

基础设施即服务 (IaaS)

因为我基本上把IaaS视为“云上部署”，所以我几乎没有去碰它。所以对于这个问题，我真的没有考虑。

移动后端即服务 (mBaaS)

Firebase在处理小型数据存储和轻量级托管等方面做得很出色。今年推出了很多实用的服务，如Cloud Functions和FireStore，因此我们对未来也有更高的期望。

就个人而言，我通常会将RTDB用于粗略数据的持久化，并且经常使用Firebase Hosting作为一个相当稳定和方便的托管服务，它支持http/2（自然而然地使用了独立域名的HTTPS）。

因为我并不是应用程序工程师，所以我完全没有使用过任何与应用程序相关的功能。

总结

前端使用Vue.js，後端作為前端子系使用Node.js，應用層面已經使用了一年。基建方面主要使用AWS或Heroku，如果不自己搭建的話，可能會使用Firebase。目前來看，這之外的基建暫時都不是特別必要的。

好像应该记住的清单

最后，根据现有的情况，简单列举出下一步应该记住的东西。

• gRPCの概念の基本

 

• NoSQL周りの最低限のスキーマ設計について(当分はRDBで良いけれど事例が増えてきてはいるのでコミュニケーションできる程度にはなったほうが良さそう)

 

• Goあたりの言語のWebアプリケーションでの利用(NodeはProduction Likeではないし、PHPは最近はあまり多くない)

 

JSのSSR周り大分使ってるけどガツガツトラフィックがくるシビアな世界の運用経験がないのでWebフロント on SSRな世界での高速化はある程度追求しておいて損はなさそう