タグ

関連タグで絞り込む (200)

タグの絞り込みを解除

JavaScriptとJavascriptに関するsasaplus1のブックマーク (1,087)

  • リアクティブプログラミングの技術を用いてマウスストーカーを実装する - はこべにっき ♨

    古き良きインターネットアプリケーションであるマウスストーカー*1をリアクティブプログラミングの技術を活用して実装してみるという取り組みをしましたのでご紹介します。リアクティブプログラミングというと主語が大きめですが、ここではbacon.jsを使ってるくらいの意味です。 できたもの まずは完成したマウスストーカーを紹介します。チェーンのように連なった星がマウスカーソルの軌跡を辿ってついてきます。工夫してうごかすとなかなか綺麗です。下のボタンを押すと実際にこの画面でマウスストーカーを有効にすることができます(requestAnimationFrameに対応したPCブラウザのみ)。いろいろ動かして遊んでみてください。 このページでマウスストーカーを有効にする 実装 このマウスストーカーがどのように実装されているか紹介します。ソースコードはGitHubに公開していますので、適宜ご参照ください。手元

    リアクティブプログラミングの技術を用いてマウスストーカーを実装する - はこべにっき ♨
  • getComputedStyle について調べてたら深みにハマったのでメモ - IT戦記

    getComputedStyle とは!? ある要素にどんなスタイルが当たっているかを計算してくれる。便利な関数。 使いかたはめっちゃ簡単! var style = getComputedStyle(element, ''); alert(style.fontSize); // 14px alert(style.color); // rgb(0, 0, 0) ちなみに第二引数は疑似要素の style を取りたい場合に使います。通常は空文字列でいい。 でも、 getComputedStyle はこのままでは IE, Safari では動かない。 Safari では window(グローバル領域) に getComputedStyle は定義されてなくて、 document.defaultView だけに getComputedStyle が定義されている。 ちなみに、 Firefox, Op

    getComputedStyle について調べてたら深みにハマったのでメモ - IT戦記
  • JavaScriptパフォーマンスベストプラクティスその4 - 読み書きプログラミング

    Nokia Developerより Document Object Model (DOM) の難解さ ソース: Efficient JavaScript - DOM DOMパフォーマンスの遅さは以下の3つの主な原因に遡ることができる: 大規模なDOM操作 DOM APIの大量の使用は遅さのよく知られた原因である。 スクリプトが多すぎるリフローや再描画を引き起こす DOM操作の結果として、レイアウトのリフローと再描画はとても高価である。 DOMの中にノードを置く遅いやり方 DOMに望みのノードを置くことはDOMがサイズ変更可能だったり複雑だったりすると、潜在的なボトルネックとなる。 Slow DOM performance can be traced back into the following three main causes: Extensive DOM manipulation E

    JavaScriptパフォーマンスベストプラクティスその4 - 読み書きプログラミング
  • Extensible Web を支える低レベル API 群 - Block Rockin’ Codes

    Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの?」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi

  • Web Worker を使って web ページ内の画像を zip してダウンロードする - おなか周りの脂肪がやばい

    クロスドメイン制約がない状況で、Web ページ内に表示されている画像を一括で zip してダウンロードしたいみたいな欲求ありませんか。私にはありました。 ありがたいことに jsZip というライブラリがあり、これを使えば JavaScriptzip ファイルを作成することができます。手順としては以下のような感じでしょうか ダウンロードしたい画像の url 一覧を作る 画像をすべてダウンロード 完了したら画像データを jsZipzip する zip したものを blob にして、ダウンロード用のリンクを作る ご存知のようにブラウザの JavaScript はシングルスレッドで動作しており、JavaScript で時間のかかる処理を行うとユーザーの操作がブロックされます。jsZip による zip 処理もファイル数が少ないうちはいいのですが、ファイル数が増えてくると結構時間がかかっ

    Web Worker を使って web ページ内の画像を zip してダウンロードする - おなか周りの脂肪がやばい
  • SuperAgent

    Module Summary LOC: 369 File size minified: 7.0k/9.9k Dependencies: emitter reduce Browser Support: IE6+ Github: visionmedia/superagent npm: superagent Component: visionmedia/superagent Bower: superagent by Toby Ho on 2/2/2014 SuperAgent is a light-weight, flexible and expressive Ajax library. Note: SuperAgent has been loaded on this page! You can open up the dev console to try out the examples. T

  • Let’s Write Fast JavaScript

    JavaScript is the most popular language as of now, it’s used for a wide variety of things — creating websites, servers, games, operating systems, robots, and a hell of a lot more. But let’s be honest, even with it’s crazy popularity, it’s not as fast as it should be. Yes it’s improving, but wait for it to catch up with native everywhere. I mean, it might not be as slow on desktop, but make a hybir

    Let’s Write Fast JavaScript
  • JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD

    この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり:私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

    JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
  • 完全に状況を掌握した画像の遅延読み込みの実現 - latest log

    IE8の挙動について追記しました。 IE8は、img.complete は 画像読み込みでも true になりません(falseのままです)。 そのかわり、img.readyState が "complete" になります。 JavaScriptでの画像の動的/遅延読み込みといえば (new Image).src = URL; なんですが、 タイムアウトやエラーの状況を把握したい時もあったりします。GoogleMapライクなアプリを作ってるときとか。 今回ちょっと必要になったのでまずは調査から。 以下のコードで、存在しないファイル(missing.jpg)を読み込ませ、実行経路を確認してみます。 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://w

    完全に状況を掌握した画像の遅延読み込みの実現 - latest log
  • Introduction to Service Worker: How to use Service Worker - HTML5 Rocks

    Web Platform Dive into the web platform, at your pace.

    Introduction to Service Worker: How to use Service Worker - HTML5 Rocks
  • ES6テンプレートリテラルをテンプレート関数化する - teppeis blog

    V8にES6テンプレートリテラルが入ったらしいということで、 テンプレートリテラルが実装された - JS.next 先に入っているFirefox 34(現beta)で遊んでみた。 埋め込み変数は即時評価 埋め込み変数は即時評価なので、テンプレートリテラルが評価される時点で定義されない変数を埋め込みに使うとエラーになってしまう。 var name = 'Taro'; console.log(`Hello, ${name}.`); // 'Hello, Taro.' console.log(`Hello, ${hoge}.`); // ReferenceError: hoge is not defined' そうすると、Viewクラスのプロパティにテンプレートを持っていて任意のタイミングで呼ぶみたいなことができず、同じテンプレートでも使うところで毎回リテラルを書く必要がある*1。 // Vie

    ES6テンプレートリテラルをテンプレート関数化する - teppeis blog
  • みんな大好き WebWorkers (WorkerMessage.js 作った) - latest log

    WebWorkers(以下Worker)をハンドリングするのは結構大変で、ちゃんと意味があるコードを書こうとすると、 Worker が応答無くなったらどうしよう。エラーハンドリングどうしよう。どんなエラーがあるんだろう Worker に job 投げて結果を受け取ってクローズしてという基的な部分をもっと楽に書きたい インラインワーカーどうしよう。インラインワーカーの場合の importScripts のパスの指定どうしよう postMessageの呼び出しコストは大丈夫か? 十分な時間分解能があるんだろうか などなど色々と考慮する必要があったりします。 このへんの事を考慮した実装がこちら( WebWorker.js )。半年ほど前の実装です。 https://github.com/uupaa/WebWorker.js/blob/master/lib/WebWorker.js (409行)

    みんな大好き WebWorkers (WorkerMessage.js 作った) - latest log
  • Flow | A static type checker for JavaScript

    Code Faster.Tired of having to run your code to find bugs? Flow identifies problems as you code. Stop wasting your time guessing and checking. Code Smarter.It's hard to build smart tools for dynamic languages like JavaScript. Flow understands your code and makes its knowledge available, enabling other smart tools to be built on top of Flow. Code Confidently.Making major changes to large codebases

    Flow | A static type checker for JavaScript
  • 【翻訳】リッチなWebアプリケーションのための7つの原則 - from scratch

    はじめに この話はGuillermo Rauch氏が書いたhttp://rauchg.com/2014/7-principles-of-rich-web-applications/ という記事の翻訳です。許可を得て翻訳しています。 ここ最近Web業界を賑わしているSingle Page Applicationの必要性、HTTP2/SPDYといった技術、リアクティブプログラミングやIsomorphicデザインという考え方について包括的にまとめたすごく良い記事になっております。 最初に断っておきますが、ものすごく長いです。各セクションがわかれているので時間がない方はセクションごとに書かれたtl;DRとまとめを読むだけでも参考になるかと思います。 ちなみに明日のNode学園祭には、記事を記述したGuillermo Rauch氏が見えるので、そこで詳しく聞いてみるのもいいのではないでしょうか。

    【翻訳】リッチなWebアプリケーションのための7つの原則 - from scratch
  • Fetch API 解説、または Web において "Fetch する" とは何か? - Block Rockin’ Codes

    Update [14/11/11]: Chromium での実装が M40 からあるそうなので、末尾に引用追記させていただきました。 [14/11/12]: この記事を書くにあたって、色々なかたにレビューや助言を頂いたのですが、謝辞などが一切抜けてました、当にすいません。追記しました、ご協力頂いた方々当にありがとうございました。 WHATGW Fetch Spec WHATWG のメンテナンスするドラフトに Fetch Spec が追加されました。 もうすでに日語訳もあります、すばらしい。Fetch Standard 日語訳 この仕様には二つのことが定義されています。 "Fetching": Fetch するとは何か? の定義 "Fetch API": fetch() の定義 後者の定義に基づく fetch() という DOM API の実装も始まっています。(詳細は後述) しかし

  • Class構文について - JS.next

    概要 待ち焦がれた人も多いことだろう。ES2015の一番の目玉機能とも言えるクラス構文が、ついにV8でサポートされた。 Class構文は、『関数(コンストラクタ)定義』+『.prototypeへのメソッド定義』の糖衣構文である。 JSで今まで様々に工夫されてきたクラスの書き方を、綺麗に統一してくれる可能性を秘めている。 クラスを作る 従来、Catクラスを作ろうとした場合このように書いてきた。 function Cat(name) { this.name = name } Cat.prototype.meow = function () { alert( this.name + 'はミャオと鳴きました' ) } しかしこの書き方だとどうしても、コンストラクタとメソッドの定義が分離されているため、クラスとしてまとまりがなく分かりづらく感じる。 メソッドが増えてきた時も、Cat.prototyp

    Class構文について - JS.next
  • Stream API がブラウザにやってくる - Block Rockin’ Codes

    Intro 今日は、フロントのプログラミングスタイルに、にまた一つ大きな変化をもたらすであろう Stream という API についてです。 この仕様は現時点でまだ策定中であるため、 API は変更される恐れがある点にご注意ください。 Stream API 以前 「Node.js の Stream API で「データの流れ」を扱う方法」 という記事を書きましたが、簡単に言うとあれがブラウザにもやってくるという話です。 非同期処理おさらい もう何度も書いた話なので駆け足で。 JS はシングルスレッドでイベント駆動な世界なので、何をするにも非同期であり、コールバックを登録することで完了した結果を受け取る API が基です。 これは、ブラウザの DOM の API でも、 Node.js でも共通しています。 概念を疑似コードで書くと以下のような感じです。 console.log('1');

    Stream API がブラウザにやってくる - Block Rockin’ Codes
  • React JS and why it's awesome

    This document provides an overview of React, including initial reactions to it, fundamental concepts like components and one-way data flow, and how the virtual DOM works. Some key points covered include: - Initial reactions to React were mixed, with some finding it "ugly" but others seeing benefits like separation of concerns with components. - Everything in React is a component, with data flowing

    React JS and why it's awesome
  • A State of Change — On the future of Object.observe

    { } { changed: true } No idea it changed Solutions? var model = new Model(); model.set('foo', 'bar'); model.get('foo'); Dirty checking — a.k.a. $scope.$digest( ) — “Angular models are plain old JavaScript objects. This makes your code easy to test, maintain, reuse, and again free from boilerplate.” var o = {}; Object.observe(o, function(changes) { console.log(changes); }); // Add a property o.foo

    A State of Change — On the future of Object.observe
  • 小さいライブラリを採用する - mizchi's blog

    僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。

    小さいライブラリを採用する - mizchi's blog