Web フロントエンドの実装において本来の機能を損なってはいけない
データの取得・ルーティング・フォームの値の管理に至るまで JavaScript で制御するようになった結果、本来備わっていた機能を損なう形で実装されるような間違いが起きるケースも発生してしまいました。見た目上操作に不都合がないのですが、修飾キーが有効でなかったりと、とある要素が当然に持っているべき機能が失われていることがよくあります。 昨今の Web フロントエンドの開発においては、React や Vue.js などを利用した SPA を採用することが多くなりました。従来の MPA と比較して、リンククリック時やフォーム送信時にページリロードを挟まないので、高速な画面遷移を実現できるため、快適な操作を実現できます。 一方データの取得・ルーティング・フォームの値の管理に至るまで JavaScript で制御するようになった結果、本来備わっていた機能を損なう形で実装されるような間違いが起きるケ
やはりHTML/DOMは再発明されるべきじゃないか - mizchi's blog
と思う次第である。以下理由。 JavaScript, GUI設計の今 JSはそのプラットフォーム特性上、あらゆる言語の使用者の、あらゆる不満が集まる場所で、ヘイトを集めやすい環境だと思う。近年は npm というプラットフォームの登場でエコシステムが生まれ、思いつく限りあらゆるメソッドが適用されてきた。貧弱な言語基盤だが、その中で生き残った方法論が、今一番GUIの課題を上手く扱えている、と自分は考えている。 React/Redux や Angular によって、Flux/MVVMという抽象パターンが枯れてきたように思う。(この際、現場はまだ jQuery だぞ、みたいな話は無視する)。要は View は State の写像である、ということに尽きる。State はシリアライズ可能(JSON)で、Flux Action/Rx.Observable の Event Stream を入力とし、それ
W3CのDTDを取りに行きすぎるとBANされる | 水無月ばけらのえび日記
Yet we receive a surprisingly large number of requests for such resources: up to 130 million requests per day, with periods of sustained bandwidth usage of 350Mbps, for resources that haven't changed in years. W3CのサイトにおかれているDTDなどに対して、1日に1億3千万回ほどのアクセスがあるそうで。 たとえば、.NET FrameworkのXmlDocumentでXHTMLを読むなんてシチュエーションはありがちだと思いますが、XmlResolver = nullを指定せずにそのまま使うと、いちいちDTDにアクセスしに行ってしまいます。世界中でそういうことをされると、まあ、大変です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
