SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
SPA に特化した http.FileServer — KaoriYa
SPA の紹介に特化した http.FileServer (http.Handler) を作っていたので紹介します。 Single Page Application (以下 SPA) の特徴の1つとして、 クライアント側でルーティングを行うことがあります。 これは端的に言うと /foo/ というパスに SPA を配置した場合、 Web サーバーは /foo/bar や /foo/bar/quux/ など /foo/ 以下のパスに対しては /foo/ と同じコンテンツを返さなければならないことを意味します。 先日 tyru さんが Go の net/http で Vue.js / Angular 1 などの HTML5 history mode に対応する において、それに対応する方法を記事にしていました。 実は私も似たようなことをするけど設計思想が少し違うパッケージ koron/go-sp
なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか
最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか！」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として
Mithril.jsでがっつりSPAを作った話 - コード譜共有サイト「ChordKitchen」 - リズムのじかん
Mithril.jsを使って、がっつりSPA（シングルページアプリケーション）を作ったので紹介します。 Mithril使いやすいので広まって欲しいです。 作ったもの コード譜をweb上で作成して共有できるサービスを作りました。 コード譜共有サイト ChordKitchen http://chordkitchen.net サービス紹介動画です。 www.youtube.com 開発環境 プログラミング言語 typescript（versionは1.4） typescriptいいよ！！ コードはできるだけjavascriptっぽく書いて、 コンパイル時にケアレスミスを検出する感じに使いました。 タスクランナー gulp webpack（後述） クライアントサイド 使用しているライブラリ Mithril.js underscore.js Mithril.jsについて 公式サイト https://
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Steve Sanderson - Architecting large Single Page Applications with Knockout.js
