Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

var cnt = 100000; var moji = ''; console.time("Case1"); for (var i = cnt - 1; i >= 0; i--) { moji = ''; moji += 'もじもじ'; moji += 'もじもじ'; moji += 'もじもじ'; moji += 'もじもじ'; moji += 'もじもじ'; }; console.timeEnd("Case1"); console.time("Case2"); for (var i = cnt - 1; i >= 0; i--) { moji = ''+ 'もじもじ'+ 'もじもじ'+ 'もじもじ'+ 'もじもじ'+ 'もじもじ'; }; console.timeEnd("Case2"); console.time("Case3"); for (var i = cnt - 1; i
※ただのメモで、未来志向なのであまり真に受けてはいけない。 良いっぽい React.js 早速い/コンポネント志向/APIの設計がいい。JSXと他のトランスパイラの組み合わせという問題はある Promise ネイティブに入った、誰もが使ってる TypeScript ES6時代でも存在意義のある言語。TypeScript互換のFacebook Flowの動向に注目 Backbone.js ModelとEventを使う/Viewは使わなくていい Lodash Underscore.jsをよくしたやつ Gulp Gruntより良いという意味で。browserifyまわりがうまく動かない問題があってnpm runのほうがいいという噂もあるがまあ良いに分類してもいい EventEmitter Custom EventはDOMにくっ付いてる感があるのでロジック志向の物にはEventEmitter使った
もうなんかこの際マジで言わせていただくんですけど、知ってるか知らないか分かりませんが世の中にはすごい頻度で呼ばれうるDOMイベントって言うのがいくつかあるわけですよ 例えば scroll mousemove, touchmove devicemotion 辺りですよ。 で、高頻度で呼ばれるって言うことは必然的に処理量が増えるって分かりますよね?????while(1) {}じゃないとはいえUIスレッドに十分影響を与えうる頻度で呼ばれる訳です。分かりますよね???????? そうなると当然そのイベント内で重い処理を行えば人間が認識できるレベルでのレスポンス遅延が起きるっていうのはご理解できますよね? 重い処理っていうのはまぁ想像出来るとは思うんですが例えばよくあるのが DOMのレイアウトプロパティへのアクセス offsetTop、offsetLeft、offsetWidth、offsetHe
Javascriptを使うのをやめろ:Railsの時代遅れ云々についての結論 - Qiita この記事は、全体的に自分の業務以外の評価基準やトレンドを知らないんだなという感じで、わざわざ付き合うと精神的に消耗する感じがした。ただ、それが彼らの本職でない以上、自分もこの結論に至るのは仕方ないと感じている部分はある。 真の問題は、自分がレガシーなJavaScriptを書いているという自覚がない人間が、ここ数年の技術トレンドから乖離したコードを書き続けることで他のエンジニアやエコシステムそのものに悪影響を及ぼしているケースが散見されている。一行書く毎にグローバル汚染するスクリプトを見せられてもメンテ出来んと言われても、はいそうですねとしか言えないし、そういう人に最近のライブラリを触らせると遅くなるというのは、画面全体を一つのMustacheテンプレートにしてBackbone.Modelのパラメー
JavaScriptでフレームワークを書くのはもうやめましょう。 JavaScriptフレームワークというものは、あたかも避けられない死と税金のようなもの、絶対にぶちあたる避けられないものといわれています。こっそり聞いてみましょう、新しいウェブプロジェクトが始まるとき、一番初めに聞かれる質問は?十中八九は「どのJSフレームワーク使っているの?」でしょうね。昨今の業界においてJSフレームワークというものは本当に根深く浸透しているのです。でも、だから必須だというものではないのです。実際、もう使うべきではないのです。 どうしてこういった結論に至ったのか、振り返ってみましょう。 AngularにBackbone、Ember・・・ ここのところ長い間、 ウェブプラットフォーム とはHTML+CSS+JS、と簡潔に技術用語の羅列でまとめられてしまっていましたが、そこにはもっとぴったり表す用語“大混乱”
Twitter CPIのTwitterアカウントでは、サイト、サーバー管理者のための重要なセキュリティ情報や、サイト運営者のためのヒント、お得なキャンペーン情報をお知らせしています。 Follow @cpiadjp Tweets by cpiadjp 掲載内容について、当社は情報の掲載には細心の注意を払っておりますが、完全性などについて保証を行うものではありませんので予めご了承ください。 掲載されている情報をご利用いただいた際に、損害が発生・誘発した場合や、情報自体の真偽性・合法性・道徳性・著作権の許諾等について問題が発生した場合などについて、当社は一切の責任を負いません。掲載されている情報を利用したサイト製作については、ご自身の責任において行ってください。
こんにちは、中川です。 ここ1・2年ですが、私の担当するプロジェクトでは、 PHPよりもJavaScriptの開発が多い状態が続いております。 JSのプロジェクトを重ねるにつれ、開発環境も段々と整理されてきましたので、 一旦、最近のJS開発で利用しているライブラリやツールなどをまとめてみました。 フレームワーク ●Backbone.js http://backbonejs.org/ JavaScriptのMVCフレームワーク。 何も使わない(もしくは我流)よりは、これを使って欲しいと思えるフレームワークです。 利用者が多く日本語情報も豊富にあるのと、フレームワーク自体が1500行程度と軽量なため、学習コストを低く抑えることができます。 ●AngularJS http://angularjs.org/ データバインディングを備えたフレームワーク。 高機能なテンプレートや、DIの仕組み、ルーテ
JavaScriptでは、初見の人にはさっぱりわからないけれども、ある程度慣れた人は当たり前に使うイディオムが結構たくさんあります。知ってしまえば何てことはないので、私の知っている限りのイディオムとその意味を解説します。 (7/3追記: twitter等で教えていただいた内容を追加しました) +v (数値化) var v = "123"; console.log(+v + 100) // 223 console.log(v + 100) // 123100 vを数値化する方法では最もメジャーです。parseFloat(v) に比べて高速なのに加えて、parseFloatとは細かい挙動が異なります(例えば空文字列の場合、parseFloatならば NaN になりますが、 +v の場合はゼロになります)。必ず数値になることが保証されており、文字列などで数値化出来ない場合はNaNが返ります。 v
Web制作で面倒な作業を自動化するビルドツール、Grunt v0.4 入門 2013-03-14 / 2014-03-12 Webサイトの表示速度を気にすると、CSSやJavaScriptのminify、gzip、CSS Sprite、画像の最適化などの面倒な作業が発生します。 Grunt.jsとは? Grunt.jsは、サーバーサイドJavaScriptのNode.jsを使用したCUIのビルドツールです。 タスクを設定しておき、それらを自動化します。 コマンドプロンプトやターミナルなど、いわゆる「黒い画面」を使います。 Grunt.jsの現在のバージョンは0.4.1です。 バージョンが0.3から0.4になったことで、大きく仕様が変わりました。 Grunt.js v0.4ではgrunt-cliをインストールしてプロジェクトごとにGruntやプラグインをインストールして使用します。 プラグイ
ウェブサイトの多数のページ全体に渡り、スタイルシートで定義されたセレクタが使用されているかどうかチェックし、使われていないセレクタのレポートを生成するスクリプトを紹介します。 納品する際に、不要なセレクタを除去するのに役立ちますよ。 Helium -GitHub Heliumの準備 Heliumの使用方法 Heliumの準備 HeliumはjQueryなど他のスクリプトを必要せず動作し、URLのリストから全てのページをロードし、解析して、スタイルシートで見つけたセレクタが全ページで使用されているかどうかチェックし、レポートを作成します。 スクリプトは、開発環境で実行してください。 公開中のサイトで実行すると、ユーザーにもHeliumの動作が見えてしまいます。 Step 1: 外部ファイル テストするページの全てに、当スクリプトを外部ファイルとして記述します。 場所は、head内でも</bo
今日は、HTML5 Advent Calendar 2011 9日目です。 何を書こうかネタに迷い、ひたすらHTML5のマイナーなAPIをあさっておりました。 FullScreen API/Page Visibility API も既に 登場してしまい、 @sada_h さんから Quota Management API はいかがとお奨めを受けましたがさすがに Quota管理だけでネタを展開するのは辛く、途方に暮れていました。 そんな折、ふと見かけたのが「Navigation Timing API」。マイナーだと思いますねぁ。今回このAPIの紹介とデモをさせていただきます。 Navigation Timing API 「いったい Navigation Timing API は何をするAPIか? 」単純です。 「ブラウザーがWebの画面を表示する時にどこにどれだけ時間がかかているか知るAPI
W3C Recommendation 17 December 2012 This version: http://www.w3.org/TR/2012/REC-navigation-timing-20121217/ Latest version: http://www.w3.org/TR/navigation-timing/ Previous version: http://www.w3.org/TR/2012/PR-navigation-timing-20120726/ Editor: Zhiheng Wang (Google Inc.) <zhihengw@google.com> Please refer to the errata for this document, which may include some normative corrections. See also tra
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く