行く2020年、来る2021年 前編 2020年のJavaScript

ピクセルグリッドのエンジニアのアンテナで感知する、2020年の技術動向と2021年の展望を座談会形式でお届けします。前編はJavaScriptの動きと新しく登場したChromium Edgeについてです。

発行

行く2020年、来る2021年 シリーズの記事一覧

はじめに

CodeGridの年中行事、年末年始の座談会です。Web関連の技術動向について、2020年を振り返りながら、2021年を展望します。前編は年末に、後編は年始に公開予定です。まずは、JavaScriptの動きから話を始めましょう。

司会進行はJamstackエンジニアの中村が、ときどき横から編集の外村や丸山が質問をしています。

ECMAScript 2020を振り返る

中村:まずはJavaScriptの今年の流れをお話しましょうか。矢倉さん、どうでしたでしょうか。

矢倉:ECMAScript 2020はどうだったかな……。Dynamic Importが2020ですね。だんだんと入る機能が少なくなってきたというか、機能としては大きいんだけど数は少ない感じなのか、あんまりStage 4に入るのがなくなってきたのかな。でもOptional Chainingとかは入りましたよね。

――ええっと、TC39のFinished Proposalsを見ると、2020では次の機能がリリースされたようですね。

  • String.prototype.matchAll
  • import()
  • BigInt
  • Promise.allSettled
  • globalThis
  • for-in mechanics
  • Optional Chaining
  • Nullish coalescing Operator
  • import.meta

ECMAScriptの仕様策定プロセス

仕様の策定段階は5つに区切られており、ECMAScriptをリリースする段階でStage 4まで策定が進んでいる検討仕様(プロポーザル)が年に一度、その年のECMAScriptとしてリリースされます。Stage 3(Candidate)は「仕様としては完成しており、実装やフィードバックを待っている」という状態です。

矢倉:モジュールの実装ほど影響は大きくはないんだけど、多少書き心地が良くなるものが多い感じですかね。Nullish CoalescingとOptional Chainingは、組み合わせて使うというのが多いかな。

Nullish Coalescing

Nullish Coalescingは、ある値がNullishな場合に代わりの値を使うための仕様です。Nullish Coalescingは目当ての値がなければこれを使うというふうに、代わりの値を定義する場面に有効です。Optional Chainingと組み合わせることで、簡潔な表現ができるようになります。詳しくは次の記事を参考にしてください。

中村:Nullish Coalescingは、TypeScriptだと、もうあるんだっけ?

:そうですね。short-circuiting assignmentっていって、Nullish Coalescingをさらに書きやすくするやつが出てきていますね。最近出ててきたやつなんですけど。

// これまで次のように書いていた演算処理が
a = a + b
a = a - b
a = a * b
a = a / b

// 次のようにも書けるようになった
a += b;
a -= b;
a *= b;
a /= b;

矢倉:ああ、JavaScriptのプロポーザルにも似たようなやつあったかな。

杉浦:ES 2021の、Logical Assignment Operatorsですね。

矢倉:変数に値を代入するときに、aの条件を満たさなかったらb、条件式を満たせるならa、じゃなかったらbみたいなショートハンドを書いていたんですけど、それが式の代入の=の前に書けるので、重複を減らせるとか。オペレーターなんで、それの拡張で。ほんとにうれしいかどうかはわからないんですけど。

中村aが条件満たしたら、なにもしないで済むっていうことなんですね。

杉浦aがあるかどうかっていうのを知る必要がない、知らなくても代入できる。

――Logical Assignment OperatorsはTypeScriptではもう実装されていて、JSでは2021で入ってくるっていうこと?

杉浦:そうですね。これはES2021で実装されるもの(すでにモダンブラウザでは実装済)で、TypeScriptでもバージョン4.0から使えたという話ですね。

中村:TypeScriptはちょっと先のが使える感じはありますね。TypeScript自体は流行っていますよね。これから学びたいねっていっている人も多い感じがします。

――ちょこさん(森)はTypeScriptをよく使っている印象があるんですけど、案件の特性上TypeScriptを使っているんですか? それとも自分が使いたくて?

:2年くらい前からやっているVue.jsの案件があるんですが、自分で使いたいっていうのもあってTypeScriptを入れました。やっぱり、規模が大きくなってくるとタイポしたときに指摘くれたりとか、リファクタがすごく楽だったりするので。

以前、Angularの案件をTypeScriptでやったときすごい楽だなって思って、それをきっかけに個人でも使うようになったんですよね。Vue.jsに関しては、型推論が効かない場面があったりと相性の悪い面もあったのですが、Vue 3に移行したことでそのあたりも解決され、だいぶ楽になりました。移行はけっこう大変だったんですが。

Vue.js、React、Angularの動向

中村:Vue.jsの話が出ましたので、ちょっとフレームワークを振り返ってみましょうか。2020年はやっとVue 3が出ましたね。

杉浦:RFCが出たのが2019年の7月で、正式版が2020年の9月でしたね。

:2020年の春ぐらいに出るみたいな話がなかったでしたっけ?

矢倉:まあ、思い通りのスケジュールでソフトウェアが開発されることって、そもそもないんじゃないかな。

杉浦:順当に議論が進んだ結果、このあいだ出たというだけなのでは。

:みんなが「まだかな、まだかな」って言っていたから、それで遅れたっていう印象があったのかもしれない。

中村:確かに。Vue 3が待ちきれなくなってReactに人が流れているのかなみたいな印象もあったんですけど。

:そんな印象もありますね。ツイートしている人もいたと思います。

中村:React自体は、確か2020年はバージョン17が出たんですよね。

杉浦:そうですね。Reactはリリースノートにも、「No New Features」、新機能はありませんって書いてある通り、ほとんど変わってないですね。JSXの変換を、いい感じにランタイムでやってくれるようになったくらいかな。

React v17.0のリリース

2020年10月にリリースされました。詳細はReact | React v17.0にあります。

:JSXって、コンパイルしなくても使えるようになっているんですか?

杉浦:いや、そうではなくって、全部のファイルにimport React from "react"って書かなくても、勝手に判断してJSXの変換をしてくれるということですね。

:ああ、なるほど。個人的な印象では、Vue 3の今回のリリースがReactを意識している印象ですね。Vue 3のComposition APIと、ReactのReact Hooksとか。

杉浦:似て非なるものですけどね!

:(笑)いや、なんだか、目指す方向が一緒というか、やりたいことが一緒というか。あとはVue 3のTeleportってやつがReactのPortalかなと。それからReactにあるFragmentや、コンポーネントを非同期でロードできるようにするSuspenseコンポーネントもVue 3では導入されていて(FragmentsSuspence)意識しているのかなっていうのは感じましたね。

杉浦:VueのComposition APIのRFCにも、「React Hooksに影響受けています」っていうのは書いてありますね。

We acknowledge the creativity of React Hooks, and it is a major source of inspiration for this proposal.

:ああ、そうですよね。Composition APIには、React Hooksのようなことを実現したいっていう側面もあると思うんです。

Reactの関数コンポーネントのように、頻繁に実行される描画関数内でStateを管理しようとしたら、描画時の無駄な処理をなくすために依存変数を明示する必要がありますよね。りぃさん(杉浦)のPreactのHooks記事にそういう解説があっておもしろかったんですけど、常に依存変数が何かを意識して書くのも結構しんどいなとも感じました。

杉浦:まあ、Vueでも、コンポーネントをまたいでReactiveなものを渡すときには、refにする・しないなどの制御はしないと、無駄にあっちこっち再描画しちゃうことになりますよね。

:そうなんですよね。Composition APIの場合は、一度しか実行されない初期化のタイミングで「描画に影響するStateはこれ」という宣言をする構文になっていて、Stateの変化に応じて実行される描画関数とは違う場所で宣言することになります。そのため依存変数の明示を要求しない構文になっているので、その点は楽だなと思いました。

中村:あと、大きなフレームワークというと、Angularもありますね。今日の座談会には、社内のAngularに詳しい人が参加していないんだけど。

――社内のAngularマンの宇野さんに、簡単ではありますがコメントを貰っています。今年はそんなにAngularの動向を細かく追ってはいなかったそうですが。

「2019年のv8からフラグ付きで使えるようになっていたIvyが、2020年の初めのv9でデフォルトで有効になりました。Ivyを使うことで、バンドルサイズが小さくなったり、テンプレートで型が効くようになったりするなどの利点があります」(宇野コメント)

:型が効くようになるのはいいですね。Angularがいち早くTSを取り入れて「わー、型付け便利〜」ってなってたけど、それだけにテンプレ経由すると型がはずれちゃうのがほんと残念っていう気持ちでしたので。

――なるほど。続いて、2020年6月にリリースされたAngular v10と、2020年11月にリリースされたAngular v11についてはどうでしょうか。これも宇野さんのコメントをもらっています。

「v10/v11は、DXを向上させるアップデートという印象がありました。

v10では、プロジェクト作成時に--strictオプションを付けることができるようになりました。このオプションを有効にすることで、型チェックがより厳密になったり、バンドルサイズの制限が厳しくなったりする代わりに、CLIによる最適化が働いたりして、保守性が向上するようです。

v11では、HMR(Hot Module Replacement)をサポートしました。ファイルの更新を検知して、そのファイルが影響する部分のモジュールだけが差し替わる、Webpackの機能です。読み込みに時間のかかるページだと、必要なところだけ更新されるのは、フルリロードと比べて読み込み時間が短くなるからうれしい、ということらしいですね。規模の大きいアプリに向いてるAngularだと、うれしい人も多いのかな?」(宇野コメント)

坂巻:まあ、勝手にリロードしないでほしいと思う人もいるよね。

矢倉:そういえば、これはAngularJSの話なのですが、LTSのサポート終了がCOVID-19の影響で半年伸びたというアナウンスがありました。

AngularJS 1.8のLTS延長

AngularJS 1.8はすでに2018年の7月1日にLTSに入っており、2021年7月31日にサポート終了になるはずでした。しかし、新型コロナウイルスの影響を受けて、2021年12月31日まで半年間延長すると発表しています。

――こんなところにも、コロナの影響が出ているんですね。

PreactやSvelte、最近注目しているライブラリ

中村:さっき、Reactに関係してPreactの話も出たんですけど、そのあたりの新しいライブラリはどうでしょうね? 新しいってわけでもないか。Preactは結構前からありますよね。

矢倉:npmを見ると、5年以上前からあるっぽいですね。

杉浦:まあ、Preact、流行りはしていないですよね。

中村:ただ、前にCodeGridで行った読者アンケートでは、「今、気になっている、注目しているライブラリ/フレームワーク」という問いで、Preactを挙げている人もいたんですよね。この先どうなるんでしょうね?

杉浦:この先どうなるかはだれにもわかりませんが(笑)、ReactのロードマップにはあるConcurrent Modeは、Preactには来ないらしいということだけは、Issuesでわかっています。Reactの根本的なところに基づいた機能なので、実装するとすればコードがすごく増えてしまうからでしょうね。

――「ブラウザ独自のAPIを利用しつつ、必要最小限のAPIを選びぬいた分だけ軽い」という、当初のPreactのアイデンティティが崩れちゃうんですね。だからPreactに入れることはないのか。

ReactのConcurrent Mode

Concurrent Mode(日本語のドキュメントでは「並列モード」とされています)は、次期Reactの内部的な実行モードとして、実験・検討が進められている機能群です。コンポーネントのレンダリング処理をいつでも中断可能にすることで、デバイスの処理能力やネットワークの速度などに関わらず、より効率よくUIを表示することができるそうです。

中村:あと、Svelteはどうでしょうね。わりと2020年はSvelteの名前を聞くようになった気がします。ちょっと前から、速度が優先されるプロダクトでは使われるというのはあるかなと思いますね。

杉浦:自分が知ったから意識して聞くようになったからかもしれないので、いたるところで使われているとか、みんなが使っている、みたいな感覚はないですね。ほんと、知っている人は知っているって感じですね。

:前に社内で、「2019年流行っていたフレームワークを集計したサイト(編集部注:The State of JavaScript 2019)」のことを話題にしたことがあったと思うんですけど、あれを見ると結構Svelteが上でしたよね。

フロントエンドのフレームワークで、満足度のランキング。2019年(2020年はまだ未発表)はReactの89%についでSvelteが88%となっている。(出典:The State of JavaScript 2019 | Front End Frameworks

杉浦:そうなんです、世界的には有名なんですよ!

中村:国内ではほぼSvelteの名前は聞かないんですけど、世界のデータとか見ていると、結構出ているなと。他のフレームワークと使い勝手的には一緒なんですけど、アプローチが違うので。そういう意味ではいいなあと。

:Svelteって生成されるファイルサイズはちっちゃいんですよね? 仮想DOMを用いず、小さなランタイムライブラリで済むように、事前コンパイルするので。

杉浦:もちろんアプリの規模によりますが、だいたいは比較にならないほど小さくなると思います。

中村:Svelteはコンパイラだと、一応言っていますからね。ただのJSファイルが吐かれるだけ。

:TypeScriptの対応はどんな感じですか?

杉浦:最近そこそこがんばって対応されていて、いちおう使える感じですね。使えるけど、完璧ではなく、TypeScriptであるがゆえにこう書かなきゃいけないというのもいくつかあるみたいですけど。

中村:Svelteはその構造ゆえにテストが書きにくいという話があったかと思いますけど。ユニットテストみたいなものは、どうなんだろう?

杉浦:ソースコードだけを使ってっていうのはもちろん厳しいですよ。コンパイラ通さないとなにものにもならないので。別にコンポーネントをレンダリングしてそこに対してテストかけるのは普通にできますね。

:来年、流行るかなあ……。

中村:別にプロダクトに入れるにあたって、海外では実績もあるし、これから日本で流行ってもおかしくないのかなって感じですね。

杉浦:そうですね。

中村:Svelteは使われていても、あんまりわかりやすくないのかな、プロダクトのものとしては。わかりやすくライブラリを読み込んでいるわけではないし。

杉浦:いや、それなりにわかりやすい(笑)。CSSのためのsvelte-ってクラス名がマークアップにいっぱいつきますから。

――じゃあわかりますね。

:アメリカの大統領選の開票速報サイトにSvelteが使われているみたいなことが、社内の雑談で出たことありますね。

杉浦:まあそれを言ってしまうと、Svelteの作者Rich Harris氏はニューヨーク・タイムズのグラフィックエディタなんで、ニューヨーク・タイムズで使いまくっていますよ(笑)。

――それは使いますよねえ(笑)。

これからのライブラリ選定

中村:あとは、Next.jsとかの話だけど……去年のほうが流行っていた気もするけど。会社名が変わったのって2020年?

矢倉:そうですね、社名がZEITからVercelになった。Next.jsはお金の調達もすごいし、ぶいぶい言わせている印象がありますね。リッチなほうのスタティックサイトジェネレーションっぽいものを押し出しているのが今年ですね。

いまはReactとほかのライブラリを組み合わせて~というよりは、Next.jsを使うことが多いのかなってなんとなく思っていたんですけど。どうですかね?

杉浦:Next.jsだけで、だいたいなんでもできますからねえ。

中村:Next.jsはnpx create-next-appを実行して、pagesディレクトリの中にJSXでコンポーネント書いていったら、それだけでサイトとかアプリとかできるぞって感じですよね。コンポーネント書くだけでページができる。

:やっぱり自前でゴリゴリやるよりは、そういうものに乗っかったほうが楽だったりするんですかね。でも、使っているうちに「かゆいところ」が出てきて、「この場合はどうやるんだ!?」みたいのがありがちかなと思ったりするんですが。そういうのって直面したりしませんでした?

杉浦:「相当かゆいやつ」ぐらいですね。そこはだいたい「こういうのが欲しいんだろ?」みたいのはあるから、これだけ支持されいてるのかなと思います。やっぱり、「流行っている」は「使っている層が多い」ってことなんですよね。

中村:流行っていないやつは、困ったときに検索しても出てこないつらみがあるんで。

――こうやってライブラリもいろいろあると、どれを選んでいったらいいんでしょうね。2020年の状況としては。

杉浦:各ライブラリより、リアクティブにUIを定義するという本質を学んでください、みんな! と、言いたい(笑)。ReactもVueもSvelteも結局、Stateを用意してそれを更新したら表示がいいかんじに書き換わるというのがみんなやりたいことなんです。その考え方と作法さえ知っていれば、どのライブラリを使うかは些末な問題だと思いますね。

あとは、そういう基本の話の上に、めちゃくちゃでかいアプリを作ろうとすると、やっぱりどうにもこうにも正規化するところに労力を割かないといけないっていう流れはありますね。そうなると関数でシンプルに合成できるようにしたいし、TypeScriptみたいに型も導入したいとなる。なので、ReactもHooksで関数を混ぜようぜ!ってなってるし、Vue 3のComposition APIも、シンタックスとしては同じような方向になってますね。

――そうすると、二極化していくってことですか? 大きなものを作るアプローチと、SvelteやPreactだと、軽量化していくアプローチと。

杉浦:二極化するというより、それぞれのフレームワークが持つ思想の色がより強く出てくるのではないかなと思ってます。

Reactは、大きいアプリをきれいに作れるよう関数によって正規化していく思想だと思っているので、小さいものを作ろうとした場合に持て余すというか。哲学を学ばずに場当たり的にコードを書いちゃうと、後でメンテできなくなるみたいなのがよくある印象です。

VueのComposition APIは、別に使いたくなければ使わなくていいようになっているんですよね。なので大した規模でないなら、今まで通り書けばいいし、大きいアプリをきれいに作らなければいけなくなったときには、そういうやり方が用意されている。というのが、VueのVueたるゆえんの一番いいところですよね。

Svelteは、小さいものを作るのには、コードの記述量も少なくて本当に楽ですね。ただ大きいものを作るためには、仕組みはあれどノウハウがまだ蓄積されておらず、一般的には難しいという印象です。

というように、どういうものを作りたいのかに応じて、フレームワークを使い分けるというのもアリかなと思っています。

――このあたりのお話はまたどこかでじっくりしてみたいですね。今日は、ひとまず次の話題、HTML/CSS関係に進みましょう。

Chromium Edgeのリリース

中村:HTML関係では、今年一番大きなニュースは、Chromium Edgeが出たこと?

矢倉:出たのは、2020年1月だったんですよね。もう1年くらいか。

坂巻:Windows Updateの自動配信でEdge Legacyと置き換わるのが、4月にずれ込んだんですよね。

中村:そうそう。コロナで確定申告の期限が4月まで延長されることになったので、その影響に考慮したと発表していましたね。

矢倉:ただ、自動で入るのも、Windows Updateのオプションで入れる感じで、OSのアップデートにバンドルされるかたちじゃなかったらしいです。バンドルされるようになったのが、今年の10月の20H2と呼ばれているアップデートですかね。

Windowsのバージョン表記

Windows 10はバージョン表記システムが2020年秋から切り替わり、西暦の下二桁と上半期/下半期を示すH1/H2を組み合わせたものになりました。たとえば、お話の中にある「20H2」は「2020年の下半期」のバージョンとなります。ただし、一般消費者向けにはこれまでの「2020年5月の更新」など、わかりやすい表記を使っていくようです。

中村:では、現時点では、普通にアップデートしていれば、みんなChromium Edgeになっているということですね。

矢倉:今、手元に会社の検証機のSurfaceがあるんですけど、このあいだアップデートしたらChromium Edgeに変わっていました。

Microsoft 365のEdge Legacyのサポートが、2021年3月に終わりますね。IE11に関しては、Microsoft Teamsで2020年の11月に、Microsoft 365で2021年の8月にサポートが終わるようです。

(出典:Microsoft 365 apps say farewell to Internet Explorer 11 and Windows 10 sunsets Microsoft Edge Legacy

杉浦:IEで開いたサイトが強制的にEdgeに飛ばされるのは、あれはなんでしたっけ?

矢倉:それはMicrosoftが用意したIE非互換サイトのリストに登録されていたサイトへ、IEで開いたらEdgeに転送されるというものですね。日本のサイトはあんまりないみたいですね。増えていくかもしれないけど。

IEからEdgeへの転送

IE非互換サイトのリストへの登録は、Microsoftへの申請により対応されます。詳細はMoving users to Microsoft Edge from Internet Explorerを参照してください。日本のサイトでは、ミツエーリンクス(mitsue.co.jpドメイン)が申請、追加されたと同社のブログで発表していました。

IEは昔からそういう互換性のリスト持っているんですよね。たとえば、古いDOCTYPEでIEのdocumentModeが8だけどHTMLのビデオを使っちゃったがゆえにみたいな、ねじれた互換性のところを表示するリストですね。IEからEdgeへの転送も、たぶんそれの応用なんだと思うんですけど。

だから、もうちょい前からできたんじゃないかなと思うので、なんで今のタイミングなのかはわからないんですけど。でも、まあ、それでしあわせになれるところもあるんじゃないかと思いますね。

中村:げこたん(坂巻)、HTMLを書く人としてはどうですか。Chromium Edgeで、前のEdge Legacyがいなくなったことで楽になったりします?

坂巻:まあ、「Chromiumだからそんなに細かく見なくていいよね〜?」ということは少しあるかな。

中村:最後に1回ぐらい動いているのを見ればいいかと。

坂巻:そうですね。EdgeHTMLはキメラみたいな感じだと思うんですよね。WebKitで起きるバグは起きるし、IE由来の不具合も起きなくはないし、わりと大変だった。あと、以前のEdgeはブラウザ自体の操作感があまり良くなかったので、Chromiumになったことで操作感も改善したと思います。

矢倉:そうですね、デフォルトになって、中身もほとんどChromeなのはいいですね。コンピューターに明るくない人が新しくWindowsマシンを買ったときとか、何かのアプリを使うためにChromeをインストールしなくてもよくなる。

開発のほうも、ChromeのDevToolsのチームがEdgeのチームに引き抜かれたりしたようです。Chromium Edgeにしかない機能も多少あります。開発環境としてもMicrosoftは力を入れているっぽいですね。

――なるほど。Chromium EdgeはMac版も出ていますしね。では、次はHTMLやCSSの仕様について、2020年を振り返ってみましょう。

(後編へ続く)

(構成:編集、丸山)

中村 享介
PixelGrid Inc.
Jamstackエンジニア

2009年、JavaScriptの会社として株式会社ピクセルグリッドを設立。
多数のWebリニューアル、新規立ち上げを取り仕切った経験を持ち、情報設計、フロントエンド、クラウド活用、開発フローの効率化を得意とする。
Webをより発展させるため、新しくブラウザに実装された機能の活用事例を数多く生み出しつつ、日々、クラウドサービスを利用した効率のよい制作・開発手法の試行錯誤を続けている。現在の興味はWeb Componentsを使ったマークアップの改善とJamstack。
著書に『WebクリエイティブのためのDOM Scripting』(単著:毎日コミュニケーションズ、2007年)など。ここ数年は書籍の執筆をせず、フロントエンド技術情報メディア「CodeGrid」で精力的に執筆活動を行っている。

外村 奈津子
PixelGrid Inc.
編集

情報出版社に在籍中、Mac雑誌、中高年向けフリーペーパー、コラムサイト運営、健康食雑誌、グラフィック・Web技術書籍編集、IT系ニュースサイトの編集記者を経験。その後フリーランスのエディター/ライターとして独立。2011年4月より株式会社ピクセルグリッドへ入社。ピクセルグリッドが提供するフロントエンド技術情報を提供するサービス「CodeGrid」の編集を担当している。

宇野 陽太
PixelGrid Inc.
フロントエンド・エンジニア

大手ソフトウェアダウンロード販売会社、ソーシャルアプリケーションプロバイダーなどで、デザイナー、マークアップ・エンジニア、フロントエンド・エンジニアとして、主にスマートフォン向けゲームの開発に携わる。2015年1月に株式会社ピクセルグリッドに入社。
JavaScriptフレームワークを用いたアプリケーション設計・実装を得意とする。
著書に『Angularデベロッパーズガイド 高速にかつ堅牢に動作するフロントエンドフレームワーク』(共著:インプレスジャパン、2017年12月15日)などがある。

坂巻 翔大郎
PixelGrid Inc.
フロントエンド・エンジニア

大手ソフトウェアダウンロード販売会社、Web制作会社などで、マークアップエンジニア、プログラマ、サービス企画、ディレクターを経験。2013年、株式会社ピクセルグリッドに入社。HTML、CSS、JavaScriptなどをオールラウンドに担当。とりわけ、プログラマブルなCSSの設計、実装を得意とする。
趣味で作成したゲーム「CSS PANIC」は、JavaScriptを一切使わず、HTMLとCSSのみで実装。海外サイトで紹介されるなど話題となった。

森 大典
PixelGrid Inc.
フロントエンド・エンジニア

大手電機メーカーを中心とした基幹系システム開発プロジェクトにSE兼プログラマとして多数参画。WEBシステム、C/S、POSレジ、無線ハンディ、汎用機(COBOL)、工場設備(シーケンス制御)、など、多数のシステム構築の実務経験を積む。2015年株式会社ピクセルグリッドへ入社。ブログにて発信しているチュートリアル、リファレンス関連の記事は幅広い層に利用されている。

矢倉 眞隆
PixelGrid Inc.
フロントエンド・エンジニア

2016年10月にピクセルグリッドへ入社。Web標準技術やブラウザの実装動向に明るく、イベントでの講演や雑誌・オンラインメディアへの原稿執筆、書籍の監修・監訳などを数多く経験。
Google Developer Expertとしても活動中。

丸山 陽子
PixelGrid Inc.
編集

Mac雑誌の編集者を経験後、フリーランスのエディター/ライターとして独立。パソコン系雑誌やデジタルカメラ雑誌、iPhone/iPadの初心者向け書籍などの編集や執筆に携わる。2015年にピクセルグリッドへ入社し、「CodeGrid」の編集を担当する。

杉浦 有右嗣
PixelGrid Inc.
シニアエンジニア

SIerとしてシステム開発の上流工程を経験した後、大手インターネット企業でモバイルブラウザ向けソーシャルゲーム開発を数多く経験した。2015年にピクセルグリッドへ入社し、フロントエンド・エンジニアとして数々のWebアプリ制作を手掛ける。2018年に大手通信会社に転職し、低遅延配信の技術やプロトコルを使ったプラットフォームの開発と運用に携わっていたが、2020年ピクセルグリッドに再び入社。プライベートでのOSS公開やコントリビュート経験を活かしながら、実務ではクライアントにとって、ちょうどいいエンジニアリングを日々探求している。

この記事についてのご意見・ご感想 この記事をTweet

全記事アクセス+月4回配信、月額880円(税込)

CodeGridを購読する

初めてお申し込みの方には、30日間無料でお使いいただけます