Web Components における依存ライブラリの断片化とエコシステムのコロニー化
あくまで可能性のはなし あまりポジティブな意味で捉えられないのでタイトルですが、あくまで可能性の話であり、直面するかもしれない問題についての一次考察って感じです。 コンポーネントが依存するライブラリの断片化 ラッパーライブラリによるロックインまたは断絶 その他の妄想 ここでは上記の3点について、つらつら書いてます。 1. コンポーネントが依存するライブラリの断片化 これまで開発者は自身がすべてのコンポーネントを管理するつもりで、ときにミニマルに、ときに富豪的に、依存するライブラリを選定していました。 いつの日か Web Components を前提にしてコンポーネントを選定するときも、個々が依存しているライブラリまでコントロールしきれるかは定かではありません。 依存関係の肥大化は避けたい 例えば npm であればさほど気にならない依存関係の肥大化も、ブラウザで実行されるコンポーネントの場合
babel な ESLint の設定をがんばった
やんなくちゃなー、と思っていたので Lint Like It’s 2015 — Medium を眺めながら、ahomu/es6-Kameita の JavaScript Linter を ESLint に乗り換えました。 Lint の設定つくるのがダルイ問題 本当にだるい。この投稿を書いている時点では .eslintrc を以下のようにしました。 スペースの入れ方については、強い意志をもって堅めの設定になっているはず。 max-params はちょい甘めです。consistent-this を全力で否定しているので、流用したい方は気をつけた方がよろしいかと。 { "parser": "babel-eslint", "env": { "browser": true, "node": true }, "rules": { "strict": 2, "default-case": 2, "no-
Reactive Programming in JavaScript - Frontrend Final Conference 資料
Reactive Programming in JavaScript ( 今回のスライド: HTML版 ) このスライド自体が Bacon.js で書かれた ahomu/Talkie で作られています。Rx系のライブラリに興味を持たれた方は、ぜひコードのほうもご覧いただければ。 アジェンダ What is Reactive Programming ? Reactive in Frontend JavaScript FRP with Reactive Extensions Reactive Programming について紹介しました。今回も懲りずに新ネタでしゃべった次第。Reactive も Functional も若干こわいひとたちが生息しているイメージ（個人の感想です）があるので、遅延評価で飛んでくる斧だけがこわい :P ノイズ避け 率直な感想として、RP/FRP を学ぼうとすると情報
もうES6 (ES2015) でいいんじゃないか
個人プロジェクトは ES6 で書いている ブログの頻度が落ちているので、継続のための雑さな記事を醸し出す時期。 以前に es6-Kameita を紹介したときの繰り返しですが、Babel (旧名 6to5) の登場から個人プロジェクトは ECMAScript 6 で書くようにしています。仕事でも新しい開発がある予定なので、そこでもきっと ES6 を使うことでしょう。 ahomu/Talkie ahomu/Urler ahomu/Claylump ということで「もう ES6 でいいんじゃないか」という気持ちを書きます。 厳密には、ES6トランスパイラを使っていけばいいんじゃないか、という話 仕様周りは（きっと）安定してきている 世間的の大多数的には、ES6とES7の境界すらハッキリしていないであろう状況ではありますが、ES6自体は2015年中の勧告を目標に進んでいることから、それなりに安定し
2014年のWebパフォーマンスふりかえり - 来年以降の期待etc
ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ
Polymer v0.8.0 Preview 所感
Improvement Polymer の Twitter アカウントが気になる発言をしていたので、Polymer のアップデート内容を確認した。 Next major version of Polymer: 5 x faster in Chrome, 8 x faster in Safari. Up to 87% smaller (15KB, 6KB gzipped) pic.twitter.com/SBJhuxIxXd — Polymer (@polymer) November 19, 2014 Chrome と Safari における実行速度の高速化はもちろんわかるが、ファイルサイズが 87% 減というのはかなり大きい。v0.5.1 の polymer.min.js が 123KB なのに対して、新しい v0.8.0 では 15KB になっているということだ。 それなりに大きい取捨選
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
AngularJS についての所感
AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が
Web Components(+Virtual DOM)ラッパー書いてみた
Concept 『Web Components with Virtual DOM』 ahomu/Claylump Motivation Web Components ラッパーを書いてみたいなーと思った React の JSX がイマイチ気にくわない（JSとHTMLを一緒にするなオジサン） <template> に書いた内容を Virtual DOM 生成器に変換すればいいんじゃね というような所から人様のライブラリを借りてツギハギして習作してみた次第。借りてきたライブラリ（HTML String パーサと Virtual DOM）は独自実装しても楽しそうなので、やる気があればやる。 もちろん実験品なので、実用には耐えない Files claylump.polyfill.js（webcomponents.js + window.fetch + es6promise） claylump.run
Concatだけでビルドを済ませてた例（Backbone.jsとAngularJS）
Concatでどこまで戦えるのか @jxck_ browserify使ってるんだけどあんま意味ない感じになっててつらいんだよねーっていうのを昨日 @ahomu に話したら、concatで全然いけますよって言われたからさっき乗り換えた。 — Kazuhito Hokamura (@hokaccha) August 6, 2014 (＾ω＾) 全然いけますよ 依存管理をサボってconcat 以下、「依存管理に労力を割きたくない」という理由で依存管理を省略した場合に、concatだけで破綻無くビルドするためにやっていたパターンの紹介。いけますと言った手前はあるが、最終的には現場によってケースバイケースということで、どうかひとつご容赦願いたい。 Case 1: Backbone.js Backbone.jsの場合、extends に代表されるクラスベースのオブジェクト指向モデルに多少の制約が必要に
Polymer と Web Components の違い9選（もとい Polymer の便利機能）
違い、または付加機能 色々な周辺事情で、勢力を広げつつある Polymer さん。（つい最近、それに加担したような気もする） 「どこまでが Web Components で、どこからが Polymer なのか」を理解するためにもPolymerの機能をメモる。Polymer は色々なことを便利にしてくれるライブラリであり、差分を言い出すとキリがないので主要なポイントだけ。 <template> が自動で Shadow DOM に放り込まれる Shadow DOM内の <link> をインラインの <style> に展開 repeat のサポート {{interpolate}} のサポート <element> のかわりを <polymer-element> としてサポート on-click とかイベントハンドラの宣言 this.$ による idが付加された要素のコレクション observe に
Web Components を支えるPolyfillライブラリ
Hello 生成されるJSそのものはピュアな感じなので、たしかにbosonicを捨ててもWeb Componentsとして成り立ちそうではある。 瑣末だが、この記事を書いてる時点で試したらWeb Platform featuresのフラグをEnableにしたCanaryで、bosonic-pollyfillsがエラー吐いてる... 余談、実はえらいかも Polymerコンポーネントって、結局Polymer入れないと使えないなら、BackboneJSで使えないAngularディレクティブみたいなもんな気がしてきた。Bosonicのコンセプト、実は偉いかも。（出来る範囲は制限されるかもしれないけど） — あほむバーガー (@ahomu) June 30, 2014 結論 個人的にはふつうのPolyfillとして動いてくれるものを精査したかったのだけど、結果的に Polymer/platform
AngularJSとサーバーサイドテンプレートの混在とngNonBindable
Angularとサーバーサイドテンプレートの混在 先日リリースされた某サービス(他社)がAngularを使っていて、XSSがボロボロ出てくるだとか、{{var}} な形式で値を入力するとng-template側でテンプレーティングされるだとかの話がありました。 詳しくは見ていないので、今回の話とまったく同じかは把握していませんが、サーバーサイドテンプレートを混在させると、次のようなことが起こりえます。 例えばejsとAngular サンプルとしてスカスカなControllerを用意します。 angular.module('app', []).controller('AcmeCtrl', function($scope) { $scope.foo = 'bar'; }); ejsは次のようなテンプレートになっているとします。
Componentによるフロントエンドのパッケージ管理
直近で、新規案件に関わることになりそうなので、ライブラリ選定やタスクランナー、そして今回の依存管理のようにベーシックな話が続いてます。次第に、具体的な実装やコード設計のポストが多くなる･･･はず。 今回はVue.jsでも触れましたが、改めてcomponent - modular javascript frameworkについて。 概要 Componentはパッケージマネージャー兼、依存解決込みのビルドツールです。クライアントサイドについて、JSのパッケージマネージャーやビルダーは既にありますが、Componentは HTML/CSS/JSをセットにして扱うことができます。 npmでいうpackage.jsonと同様に、component.jsonという定義ファイルによって、パッケージの依存関係やリポジトリなどの各種情報を示します。 component/component コア部分のリポジト
Angularそっちのけで、Vue.jsについて所感
Vue.js 軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog を読んで触発されたので、自分も外見的に良いなと思ったポイントだけ書き留めてみます。さすがに実戦投入できていないので、そのあたりの精度は悪しからず。 サンプルコードの雰囲気 サンプルコードとか自分でちょっと触ってみたときの感触からは、以下のポイントが気に入りました。data-bidingsとかは前提として便利です。はい。 覚え切れそうな分量のAPI Class: Vue - vue.js 脳みそちっちゃいので助かります。それに尽きる。 プロパティによる宣言っぽさ Angularだとイベントハンドラ類を書くにも、$scopeに都度ハンドラを仕込んでいくのがあまり好きでないです。工夫で回避できそうですが、与えられたスタートが下記のような状態であることには変わりません。 angu
GPUアクセラレーションとposition: relativeによるレイヤー生成について
またアニメーション... ボタンなどのUIにGPUアクセラレーションが効いたアニメーションをつけたとき、iOSにおいてはiPhone4か4SのWebViewあたり、Androidにおいては….まぁ機種依存的(げんなり)に、アニメーションの立ち上がりが遅いことがあります。 その辺を調査していたところ、position: relativeの指定による、意図しないレイヤー生成＆GPUアクセラレーション巻き込みによって、何かしら合成レイヤー周りでオーバーヘッドが発生してしまっているんではないかな、という憶測に行き着いた次第。今回はその辺りを見ていきます。 GPUアクセラレーションが効いたアニメーションは、CSS Animations、CSS Transitionsのほか、特殊なプロパティ（transform3d: scale(1,1)とか）で強制的にGPUアクセラレーションを効かせたCanvasア
Backbone.js コメント付きソースコード日本語訳
Annotated Sourceのコメントを訳しました 地味に道のりが長い作業でしたが、何とか先々週末にやっつけて、例によって@cssradar氏に確認していただいたりとかして今に至りご紹介する次第。 日本語訳コメントがついたソースコード· enja-oss/Backbone · GitHub なんだかんだで全域を網羅する必要があったたので、非常に勉強になりました。ソースコード自体は短く簡潔なので、Backboneをこれから使い始める/もう使ってるを問わず、まだ読んでない方は一度読んでみると良いです。 監訳謝辞 Revert original text for supervise by ahomu · Pull Request #12 · enja-oss/Backbone 上記Pull Request＆監訳依頼につきまして、多大なるレビューをしてくださった@cssradar 氏に感謝を。
Gruntによる継続的なビルド環境を求めて 〜 package.jsonと0.4.0のこと
安定したビルド環境 gruntの広まりを感じる...。みんな...package.jsonをつかうのです...そしてバージョンにも気を遣ってstableな環境を目指すのです....安定して使えないビルド環境はいくらナウくてもゴミです....。 — aho.mu (@ahomu) December 11, 2012 夏前に、nodeでビルドってなんかナウい(∩´∀｀)∩ワーイって使い始めて、秋から現職のプロジェクトで実践してみた結果、そんな当たり前な視点を忘れないようにしなければ、と強く思った次第。 今回は下記の2点を紹介します。 Gruntと永く付き合うためのノウハウとして、package.jsonを使った管理について 賞味期限の短いノウハウとして、Grunt 0.4.0への移行に関して Gruntイイヨーの続きとして、今後付き合っていくために必要なことを改めておさらい。 1. packa
Backbone.js FAQ 日本語訳 - "is a library, not a framework"
Backbone.js FAQ を日本語訳しました Backbone/docs/FAQ.md at master · enja-oss/Backbone · GitHub 上記のGitHubから参照できます。 まずFAQから訳しましたが、最終的にはみんなの力で全訳ドキュメントにするのが目標。ほんとは本家をforkすべきだったかもですが、Pull Requestに向けての整備は後で考えます。:) いまは、有志でMarkdownでさくさくと日本語ドキュメントを書きためていければいいんじゃないかと思っています。 enja-oss/Backbone ってことでIssueとかPull Request大歓迎です！ 詳しくはリポジトリをご覧ください。 Backbone.js の本性はMVCでもフレームワークでもない 「クライアントサイドMVCフレームワーク = Backbone.js」というような表現が
勉強会資料シェア Getting Started with RequireJS
げりんぐすたーてっど うぃず りくわぃあーじぇーぇす ということで、社内勉強会でRequireJSの入門資料をこさえたのでシェア。 利用したデモファイルセット http://d.aho.mu/S4mh なんとなくRequireJSが動くセットです。スライド中のr.jsによるビルドコマンドや、gruntを利用したビルドも試せるようになっています。 おさえるべき要点 いくつかの要点だけ記事内に文字列でおこしておきまする。 モジュラーと依存関係 Webサイト → Webアプリ への流れが明確になってきてフロントエンドが複雑化してきている今、1つのJSファイルにつらつらとCSSのようなノリで書き連ねる時代は終わりつつあります。 ParisJS #10 : RequireJS このあたりについては、上記の素晴らしいスライドから、Figureを拝借しました。個々のJavaScriptの粒度が揃えてモジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
