https://jsconf.jp/2021/
Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs
https://jsconf.jp/2021/
Node.js App debug, perf up 戦略 - tkdn
node --inspect=0.0.0.0:9229 app Docker コンテナ内で利用するには 0.0.0.0 が味噌
node.js のメトリクスの計測、ベンチマークの改善、Docker イメージの絞り方を勉強した
フロントエンドのパフォーマンス計測は得意なのだが、サーバーサイド node.js のメトリクスの取り方はあまり知らなくて、いつも勘でやりがちだった。最近は業務でこの周辺で困ることが増えたので、勉強しなおした。 また、最近使ってみたかった cloudflare workers の制限で、メモリ 128MB、CPU 時間 50ms という制約があり、このためにも Node.js の CPU のメトリクスを計測できるようになっておく必要があった。 という目的を踏まえて、今回は OS やデータベースの最適化は扱わず、ネットワークとアプリケーション層だけに絞って学習した。あと仕事の Docker イメージのサイズにも悩んでたので、ここも。 (あと ISUCON 参加者が楽しそうだったのもある。 ISUCON のチューニング対象にフロントエンドは含まれないので…) 計測対象 今回実験したリポジトリはこ
2020 年、 React 軸で学ぶべき技術 - mizchi's blog
なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。 有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。 このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。 モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介
Next.js + Vercel + swr + TypeScript (No Redux + No SSR) で短期間チーム開発した - またのきかいに
はじめに タイトルにある通り Next.js + Vercel + swr + TypeScript という構成で短期間チーム開発をした。 以下のように特殊な状況なので色々試してみた。 開発状況 約3週間の短期間開発。 世間にリリースしない。プロトタイプを作って終了。メンテナンスもしない。 フロントエンドを触るのは自分を含めて3人。 自分・フロントの経験もあるバックエンドエンジニア・フロントエンドの経験が浅いエンジニアの3人。 ログイン機能有りのSNS的なもの。既に世の中に存在するプロダクトと似てる。 それぞれ選定理由と使用感を雑に書いていく。 Next.js github.com 環境構築が楽 Node.js環境さえ整えてもらえればすぐ動く。 ライブラリが最小限で済む Create React Appも環境構築が楽だが使われているライブラリのドキュメントを探すのが初学者には少しハードルが
Hybrid npm packages (ESM and CommonJS)
Warning: This blog post is outdated. It may contain incorrect information. Update 2019-11-22: ESM support in Node.js is not experimental, anymore. This post was updated to reflect that. Conditional exports are now explained. In this blog post, we look at npm packages that contain both ES modules and CommonJS modules. Required knowledge: How ES modules are supported natively on Node.js. You can rea
noteのフロントエンドをNuxt.jsへ刷新します｜こんぴゅ｜note
webサービスのUXを向上させるために、表示速度は非常に大切です。 しかしながら、noteはリリース当初からフロントエンドの実行速度が遅い=表示が遅いという構造的な問題を抱えており、継続率や離脱率など重要指標に悪影響を及ぼすリスクが強くありました。 noteチームはnoteを本格的なメディアプラットフォームへ成長させるスピードを加速していきます。それを踏まえ、手遅れになる前に技術的な負債を解消し、最新のベストプラクティスに沿ったフレームワークに移行することで、高性能なサービスを提供する基盤を作っていくという決断をしました。 本ポストでは、移行プロジェクトの技術的背景や移行手順を説明します。また、途中成果のデモをUPしているのでご紹介します。 技術的な背景noteの現在のフロントエンドはAngular.js 1系で構築されたSPAです。Angular 1系はかなり複雑なUIでも簡単に構築でき
キャッシュフレンドリーなステートレスアプリケーション設計について考える #CDN_Study - mizchi's blog
CDN_Study という勉強にいってきた。 https://http2study.connpass.com/event/81469/ そこで、Akamaiの方が、「個人の意見だけど、アプリケーション側がもっと基礎設計でステートレスでキャッシュフレンドリーな設計になってないといけないよね」という旨の発言をしていて、最近そのことにアプリケーションエンジニアとして同じようなことを考えていたので、書き出してみる。 SPAとかSSRとかフロントの不毛な話は出さないようにしてるが、主にサーバレス環境を意識している。 前提 世の中のアプリケーション内のモジュールは、Statefull or Stateless に分類でき、それをツリー状に表現できれば差分検知できる、という React の仮想 DOM 的な世界観が自分にある 以下の話は、基本的には Fastly のサロゲートペアーとそのためのミドルウェ
Advanced Component styling with Angular (v4+)
@Component({ selector: 'song-track', // <song-track></song-track> template: ` <div class="container"> <track-image image="http://..."></track-image> <div class="track-information"> <track-title>{{track}}</track-title> <track-artist>{{artist}}</track-artist> </div> </div>` }) export class SongTrack { }
RxJS Real World // Speaker Deck
All slide content and descriptions are owned by their creators.
ES Modules への橋渡しとしての nomodule 属性 | blog.jxck.io
Intro ブラウザにおける新機能の利用においては、非対応ブラウザの考慮も必要となる。 ES Modules の利用においても、いかに非対応ブラウザでフォールバックの手段を提供するかが課題となっていた。 今回は、 Modules の対応/非対応を切り分けるための仕様である nomodule 属性を解説する。 script type module classic script (module ではない JS) は、 <script> で指定すると、取得解析しそのまま実行される。 type は省略されることが多いが、その場合 text/javascript と解釈されている。 <script type=text/javascript src=bundle.js></script> 一方、 module script (module として実装された JS) は、 import/export の
util.promisify が追加された - from scratch
Node.js のコアに util.promisify が追加された。 github.com 今回は util.promisify が持つ役割を中心に Node.js における Promise の立場についても話していけるといいと思う。 util.promisify とは 読んで字のごとく関数を Promise に変換してくれるユーティリティメソッド。 下記のような要領で変換できる。 const util = require('util'); const fs = require('fs'); const stat = util.promisify(fs.stat); stat('.').then((stats) => { console.log(stats); }).catch((error) => { console.error(error); }); async-awaitを使いたい
You Don't Know ES Modules
ES Modules仕様と実装の現状をひととおり紹介 Node学園 21時限目 -ES Modules Meetup- http://nodejs.connpass.com/event/34104/
JavaScript Language Update 2016 (LLoT)
This document discusses the evolution of JavaScript and the ECMAScript standard over time. It covers new features introduced in ES2015 (ES6) like arrow functions, classes, modules, and new built-in objects. It also mentions upcoming features in ES2017 like async functions and describes the process for proposing and standardizing new JavaScript features.Read less
Node.js における Promise を使った例外処理 - from scratch
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
Node.js Web Application Survey 2016
Node学園 19時限目資料です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gmork.in
GraphQLの話 (API for Front-end)
IndexedDB, Worker, Server-side Rendering そしてフロントエンドの未来 // Speaker Deck
Client Side of なんちゃらfresh.tv