バックエンドエンジニアが Next.js でモダンなフロントエンド開発を始めるにあたり学習したこと
2021年秋ごろ、副業のような形で Next.js による新規フロントエンド開発のお手伝いをさせていただくことになりました。プライベートの空き時間でフロントエンドの学習をし、今はひとまず開発できるようになってきた気がするので、これまで学んできたことをご紹介します。 基本の TypeScript, React, Next.js だけでなく、GraphQL の周辺ツールやテストについても学習しました。 これまで 当時、Web 系の受託開発会社にて主に Ruby on Rails でバックエンドの開発をしていました。TypeScript, React は学生の頃から趣味で書いていました。 テストは、Rails での開発なら RSpec や Capybara で書いていましたが、JS ではほぼやったことがありませんでした。GraphQL は全くの未経験でした。 やったこと React チュートリア
2022年におけるフロントエンド開発のベースライン
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
lodash やめ方 - Qiita
みなさん、 lodash で消耗してますか？ 私は消耗しています。 なぜ lodash で消耗するかというと、とにかく思考停止でインストールされ、 node_modules 下で大量に重複します。サイズが大きいlodashが複数バンドルされてビルドされると、重篤なパフォーマンス上の問題を引き起こします。 lodash には実装上の問題もあり、異様に丁寧に、そして富豪的に作られており、その結果ビルドサイズが無駄に大きいです。丁寧に作られて入るのですが、現代のフロントエンド水準や一般的なポリフィルと噛み合っていません。というわけで、常々やめたいと思っています。 ちゃんとES201xを追ってる人からすると、ほとんどの lodash のメソッドは不要に見えるはずです。本エントリは、思考停止で lodash で実装しようとする人に、ちょっと考え直しては？ と投げつける用の記事になります。 現代におい
60FPSへの夢、そしていかにキャッシュを従えるか / 書評「超速! Webページ速度改善ガイド 使いやすさは「速さ」はじまる」 - mizchi's blog
CAの ahomu/1000ch さんからご恵贈頂き、レビュー書いてくれと頼まれたので、自分のパフォーマンスというものへの思いの丈と共に書評を書こうと思う。 自分も6年ぐらいフロントエンドぐらいやってきたけど、あんまりちゃんと用語定義をしないまま「勘」で調査しがちだったのと、彼ら二人がどの数値見てるんだろう、という視点で読んだ。 gihyo.jp 要約: これはフロントエンドエンジニアの勘を体系化/言語化したものだ フロントエンドエンジニアにとって Chrome DevTools は日常的にお世話になる、「これナシでは生きていけない」という類のツールだ。だが、これの読み方は癖があり、経験的に蓄積してきた積み重ねがなければやや難しい側面があった。 この本は、フロントエンドエンジニアが今まで経験的に蓄積してきたでろう「勘」を、Webの仕様や各社のUXガイドラインの明確な定義を通して再整理したも
なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか
最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか！」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として
【意訳】Webpackの混乱ポイント - Qiita
この記事はWebpack — The Confusing Partsを、筆者の許諾を得て意訳しています。 何か誤りがありましたら、ご指摘いただけると幸いです。 (以下、訳) ReactとReduxで作られたアプリケーションにとって、Webpackは最先端を行くモジュールバンドラです。Angluar2やその他のフレームワークを使っている人々は、たいへんWebpackのお世話になっていることでしょう。 私が初めてWebpackの設定ファイルを見た時、それはさながら宇宙人のようで非常にわかりづらく見えました。しばらく試しているうちに、今では次のように考えるようになりました。Webpackは単に独特のシンタックスと新しい哲学を持っており、それがとっつきにくさの原因になっているのだと。偶発的とはいえ、これらの哲学は、Webpackの人気を押し上げた原因の１つでもあります。 Webpackのとっつきに
フロントエンドへの複雑化について、一つの視点 - mizchi's blog
これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記
フロントエンドで使ってるものがあまり変わってない - No Regrets in Bathing
自分のスタックはあまり変わっていない。ほとんど10年のツケを払っていない。学習能力が低いせいでもあり、選んだスタックがバージョンを重ねている成果でもある。 毎回使う フレームワーク：Vue.js 消耗、などの意見が散見されたが、べつに今でも便利に使えている。 browserifyやwebpackがあれば便利だけど、なくてもいい、ってバランスが好き データフローは特に考えない。状態がそこにあるので書き換えれば良い。 あまり頭を使わなくていいのが助かる Reactの考え方は好きなのだけど、よっしゃFluxやるぞって気持ちにはならず、Reactのみでよしなにやるソリューションが広まったらいいなと思う。 ビルドシステム： browserify / watchify substackの作るものはどれも品質が高いので、もうsubstack製品だけ使っていればいいやという気持ちになりがち。余計な処理が全
フロントエンド速度改善でやったこと(Expiresヘッダ、faviconのgzip圧縮、JSの読み込み遅延化) - $shibayu36->blog;
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog; という記事を以前に書いたのだけど、結局何をやったか書いて欲しいと社内で言われたので、今回のフロントエンドの速度改善でやったことについて書いてみる。そこまで大したことはやってないので参考程度にどうぞ。 前提 ページのレンダリングが遅いと思い始めたので改善をすることになったのだが、改善をし始めたところChromeのアップデートがあり爆速になってしまった(FirefoxやSafari等はもともと速かった)ので、では明らかにやったほうが良いことだけやりますかという話になった。そのためあんまりbefore/afterもちゃんと取っていないので、今回はやったことの紹介くらいに留める。 やったこと 計測や調査をしてみたところ、以下のようなことはやってしまったほうが良いということになった。 静的ファイルに適切にEx
karma + babel + browserify + isparta を使って、es2015 で書いたフロントエンドテストのカバレッジを出す設定 - Qiita
karma + babel + browserify + isparta を使って、es2015 で書いたフロントエンドテストのカバレッジを出す設定JavaScriptTDDkarmacoveragebabel こちらの記事も合わせて参考にしてください。 - karma + babel + istanbul でフロントエンドのカバレッジを出す設定 2016年版 フロントエンドで es2015 かつ browserify でバンドルしつつ書きたいという需要はそこそこ高まっているんじゃないかと思いますが、そのセッティングで開発した場合に、テストカバレッジってどうやって出したらいいの？という情報があまり出回っていない気がしたので、自分なりにミニマルだと思う設定の例をまとめてみました。 なお、この記事では、テストランナーには、karma、バンドラには browserify を使う前提で書いています
2015年の振り返りと2016年の目標 - undefined
昨日年が変わる2時間前くらいから、書こうか書かまいか、もやもやして、結局書かないまま年が変わってしまった。今日もどうしたものかと考えていたけれど、書くことでプラスになることが多いように思ったので書いておく。 良くも悪くも2015年は自分にとって激動の年となり、同時に実りを感じた年でもあった。 2015年振り返り ブログを始めた プログラミングを腰を据えて学びはじめた 会社の閉鎖が決定した 家をたてた 転職活動した ブログを始めた なんとなくブログを始めた。正確には2014年に開始したが、記事をちゃんと書こうと思ったのは2015年にはいってから。アウトプットするってのは自分にとってとても良い訓練で2016年も続けていきたい。自分は特に日本語の能力が極めて低いので、最も適したリハビリかもしれない。 1年間でよく読んでいただいたのは以下の記事。 blog.bokuweb.me blog.boku
2015年のWebクライアントサイドの温度感 - Tetsuharu OHZEKI - Medium
この3~4年間でJavaScriptとかWebクライアントサイドを取り巻く温度感も大きく変わった。これからはHTML5だぜイエーイと騒いでいたのも随分過去の話になったように思う。だけど、このあたりの温度感はそんなに掴みやすいものでは無い。別に放っておいてもいいんだけど、放っておくと10年20年経たないと誰も書かなんてのも割とよくある話。でも、そこまで待ちたくは無い。なにとなしに説明してみようと思う。 だいたい2011~13年ぐらいはHTML5がバブルっていた。今からすると「バブルだった」というのが一番説明しやすい。Node.jsあたりが世の中に認知を拡大していたのもこの時期だし、スマートフォンのシェアの伸びに合わせて、クロスプラットフォームで出せるWebにみんな夢を見ていた。MVCだの設計だの何だの言い出したのも、だいたいこのくらいの時期だし、Single Page Application
社内JavaScript勉強会で作ったコンテンツまとめ - Qiita
はじめに 弊社で実施している社内向けJavaScriptの勉強会のコンテンツまとめです(最近はやってないのも上げてる)。対象は独学でJavaScriptを少し触ったことがあるけど企業でやったことはない、くらいのレベルの人です。このコンテンツを作っている筆者も1年くらいしかJavaScriptを触ってないので怪しい所もあると思いますが、社内でのJavaScript教育に困っている方の参考になればと思います。 ちょっと一部古かったりするので、Issueでも立てて下さい。気が向いたら直します。 ES2015(ES6) JavaScriptを書く上でスタンダードになりつつあるトランスパイラBabelを使用したコーディングについて学びます。ES2015の記法について全て網羅しているわけでなく、今すぐ使える簡単なものを優先して開設しています。ES2015の構文を使うことで何が楽になるのか、という点を重
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
20 年代のフロントエンド.md
クロスブラウザテストの闇と闇と闇
Vue.js 2.0 Server Side Rendering
PostCSS とは何か
ペパボのフロントエンドスタンダード に関する記事一覧 - ペパボテックブログ