JavaScriptのバンドルとトランスパイルが不要なモダンWebアプリ | POSTD
筆者はES6以前のVanilla JSがあまり好きではありませんでした。 そこで、バニラJavaScriptをなるべく書かなくていいように、2000年代を通じてさまざまなアプローチを追求してきました。最初はRJS（Ruby-to-JavaScript）、次はCoffeeScriptでした。どちらのアプローチも、バニラJavaScriptより楽しく書けるソースコードを、ブラウザが実行できるバージョンのJavaScriptへトランスパイルするものです。ある程度は、うまくいっていました。 とはいえ、これは明らかにその場しのぎの手段に過ぎず、ブラウザがより洗練されたJavaScriptを理解できる日を待ちわびていたのです。ただ、そんな日が来ることはなく、永久にその場しのぎでやり過ごすのかと思われる時期がしばらく続きました。 しかし、幸いなことにJavaScriptは改善を続け、2015年にはES6
vendor.js の終焉と Granular Chunks - 徒然技術日記
webpack を使った code splitting のベストプラクティスとして，v3 以前の CommonsChunkPlugin の時代から node_modules 以下に置かれている依存ライブラリを vendor.js という単一の chunk にまとめる方法が紹介されていました． これは webpack の公式ドキュメント Caching | webpack や Google の Make use of long-term caching | Web Fundamentals | Google Developers でも説明されている通り，「ライブラリのコードはアプリケーションコードに比べると更新頻度が低い」という仮定のもと vendor.js にライブラリコードを切り出すことで，キャッシュ効率をよくすることが主な目的でした． しかし時は流れ，いつしか「ライブラリのコー
フロントエンドのパフォーマンスを徹底解説！ブラウザの気持ちで理解するHTML/Javascript/CSSの話 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
HTMLフロントエンドcssdomcssomパフォーマンスJavaScript こんにちは、羽山です。 今回はウェブシステムにおけるフロントエンドのパフォーマンスの話です。 皆様はウェブのパフォーマンスを気にしていますか？ おそらく大抵の方はSQLのチューニングやロジックの改良などをした経験があるのではないでしょうか？ しかしプログラムをチューニングしても、期待ほどはページ表示速度が改善しなかったことはありませんか？ 昨今のウェブサイトは大量のCSS/Javascriptファイルで構成されているページが大半です。例えばHTMLを100～300msほどで生成してブラウザに転送できたとしても、ページ表示が完全に完了するのに4～5秒かかるということも珍しくありません。 「なんか遅いけど沢山いろいろ読み込んでるから仕方ないな・・・」と諦めないでください。ブラウザがどのようにHTMLを解釈して、CS
![フロントエンドのパフォーマンスを徹底解説！ブラウザの気持ちで理解するHTML/Javascript/CSSの話 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/6e392d4350342045b699dea4e2a6421740d16647/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2018%2F04%2Fphoto_47592_20151013_min.jpg)
Immutable.jsとImmer、ちゃんと使い分けていますか？
昨今のフロントエンド開発では、データをイミュータブルなオブジェクトとして扱うのが主流です。すなはち、データが変わるときはオブジェクトを書き換えるのではなく、新しいデータを持った新しいオブジェクトを作ります。最近ではオブジェクトがデータとしてプログラムのあちこちで取り回されることが増えて、一度余所に渡されたデータの中身が後から変更されるのは混乱をきたし設計が困難になるというのが主な理由です。 データを変更するたびに新しいオブジェクトを作るのは、特にデータが複雑になったりネストしたりしていると面倒だしプログラムの見通しが悪くなります。そこで使われるのが、データをイミュータブルに扱うためのライブラリであるImmutable.jsとImmerです。 データをイミュータブルなものとして扱うという目的はどちらのライブラリでも達成することができますが、現在では Immer のほうが開発が活発であり、独自
サーバサイドレンダリングの導入から生じるSSRF | セキュリティブログ | 脆弱性診断（セキュリティ診断）のGMOサイバーセキュリティ byイエラエ
オフェンシブセキュリティ部の山崎です。サーバサイドレンダリング（SSR）の導入によってSSRFが発生する問題を見つける機会があったため、本記事では実例を交えながら紹介したいと思います。 サーバサイドレンダリング（SSR）とは？ 本記事で扱うSSRとは「サーバ上でHTMLを出力すること」を指しています。ただしerbやjspのようなテンプレートからHTMLを出力するのとは異なり、一般的には以下のようにクライアントサイドレンダリング（CSR）の文脈で使われることが主です。 近年のVue.jsやReactを代表するようなWebフロントエンドフレームワークはブラウザ上で動的にDOMツリーを構築して画面を描画（CSR）するのが主流となっています。これによってページ遷移を挟まずユーザ体験のよいシングルページアプリケーション（SPA）が作ることができるというメリットがあります。 ただ、単純なSPAにはデメ
どうして Fastify は生の Node.js より速いの？ : (*x).b=z->a+y/c
Fastify 速いですね Express が hapi より遅いのは意外でした Koa は本体だけだと Express 以上に何もしないので その分速めです よくみると驚きなのが http.Server より Fastify が速いというところ http.Server はフレームワークを使わない Node.js 自体の API です Koa や hapi はこれを中で使っています これより速いということは Fastify は http.Server は使わずに net などを使って ソケット通信部分を直接操作しているのでしょうか？ http.Server を使ってない？Fastify のソースコードを見た限りでは 特に設定をしなければ http.createServer でサーバを作成しています つまり http.Server を使っています https://github.com/fas
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法 2020年でJavaScript学ぶならきっとブラウザ向けJSガン無視していきなり初手node.js（ただし暫く何も足さない）がいいんじゃないかというメモ - min.t (ミント) Node.js を教えることについて、自分は賛成なんですが、その学習パスが整理されてないなと思っていたのと、学習パスがなぜ整理されていないかについて書きます。 はじめに 問題意識として、今のプログラミングスクールや独学勢が Ruby on Rails に偏っていて、 Node.js の人間としては、歯がゆく感じているんですが、実際 Node.js を教えるとしても問題も多いと認識しています。 歴史の話は、当時の実情や政治を省いて結果だけを書きます。具体的には第一次ブラウザ戦争、第二次ブラウザ戦争を言及しませ
JavaScriptからletを絶滅させ、constのみにするためのレシピ集 - Qiita
はじめに 本記事では、constこそが唯一神であることを証明したあと、letを使いがちな場面でいかにしてconstを使うかをまとめていきます。なお、ES2018までの基本構文(reduce, async/await, 配列とオブジェクトのスプレッド構文)を使用します。「いや、reduceとかスプレッド構文とか難しいからlet使うわ」という方のために、便利メソッド詰め合わせであるLodashを使った例もご紹介します。もちろん、Lodashは機能に対してサイズが大きいライブラリであるため、フロントエンド開発でバンドルサイズを軽減したいという方などはLodashの例は無視し、Lodashを使っていない方の例をご参照いただければと思います。 追記：Lodashの使用について 「Lodashのコードにlet使われてるやん」というご指摘を多く頂いたので追記いたします。 誤解を招くタイトルにしてしまい申
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
