私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.133 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
どう考えてもヘビーだろw
同じことをDOM APIだけで実現すれば
ライブラリのサイズは0!
自分で書いたコードの量だけですむ
同じことをDOM APIだけで実現すれば
ライブラリのサイズは0!
自分で書いたコードの量だけですむ
その自分で書いたコードの量が多いっていう落ちだろw
自分で書いたコードはCDN仕えっても効果ないし
という指摘されるところまでが予定のうちですw
自分で書いたコードはCDN仕えっても効果ないし
という指摘されるところまでが予定のうちですw
いったんjQuery入れてしまえば最後、何だかんだでプラグイン始めどこの馬の骨とも分からないクオリティバラバラなjQuery依存のライブラリを導入することになる。そしてさらにこれらに依存したコードを書くからjQueryコケると皆コケるwww
まるで将棋だなwwwww
まるで将棋だなwwwww
クオリティバラバラなのと全部俺様クオリティどちらを取りますか?
俺様クオリティは10年経ってもクオリティはかわりません!
俺様クオリティは10年経ってもクオリティはかわりません!
10年たっても低いクオリティのまま
成長してないんじゃダメだろうw
成長してないんじゃダメだろうw
最近だとasync関数使ってその中で
awaitやfor-awaitやwhile_awaitでイベント待ちたい場合もあると思うんだけど
コールバックベースであるjQuery使ってる人ってどうやって上手く調整してるんだろうか
awaitやfor-awaitやwhile_awaitでイベント待ちたい場合もあると思うんだけど
コールバックベースであるjQuery使ってる人ってどうやって上手く調整してるんだろうか
>>59
そこにも数値じゃない値って書いてあるね
そこにも数値じゃない値って書いてあるね
Not a Numberなのに数値という意味が分からない
Nullが文字列って言うようなものでは?
Nullが文字列って言うようなものでは?
>>29
ソースよろ
NaNはNumberオブジェクトに属し
typeof NaNでnumberを返すくらいの認識しかない
数値計算の結果生成されるからNumberオブジェクトに入れてるだけじゃないの?
ソースよろ
NaNはNumberオブジェクトに属し
typeof NaNでnumberを返すくらいの認識しかない
数値計算の結果生成されるからNumberオブジェクトに入れてるだけじゃないの?
typeof nullがオブジェクトwwwww
javascriptワロタwwwww
javascriptワロタwwwww
Rubyなんか、null(nil)にnil?メソッドが有るんだぜw
もちろん nil.is_a? Object は true である
もちろん nil.is_a? Object は true である
もしdoubleな数値型の値だったら、比較や加減乗除できるはずなんじゃないの
比較も演算もできるやろ
まあ結果が直感には反するかもしれんが
仕様(IEEE 754)に沿ってるだけ
そもそもなんでそんな仕様なんだクソが、とは思わなくもない
既存の数値処理にあわせたとか、ゼロ除算や文字列からの変換をエラーにしたくなかったとか、なんか理由はあるんだろう
まあ結果が直感には反するかもしれんが
仕様(IEEE 754)に沿ってるだけ
そもそもなんでそんな仕様なんだクソが、とは思わなくもない
既存の数値処理にあわせたとか、ゼロ除算や文字列からの変換をエラーにしたくなかったとか、なんか理由はあるんだろう
jQuery は、gzip圧縮時で、30KB。
広告1つ分
CDN はサポートがしっかりしている、Google, MS を使うのが普通
jquery.com は、テスト用で使えるってだけ。
jQuery はソースコードを作っている団体。
CDN サービスなど、やっていない
広告1つ分
CDN はサポートがしっかりしている、Google, MS を使うのが普通
jquery.com は、テスト用で使えるってだけ。
jQuery はソースコードを作っている団体。
CDN サービスなど、やっていない
http://code.jquery.com/
<title>jQuery CDN</title>
<title>jQuery CDN</title>
広告の30KBと圧縮コードの30KBでは全然違う。
jQueryはロードしたねヨカッタヨカッタというようなライブラリではなく、導入しているからには様々なプラグイン、依存ライブラリ、依存コードの依存先となる。
つまり非同期読み込みできない。bodyの下のほうに置いてる場合でもない。head内でなるべく早く読み込まなければ依存コードが動かない。
なのでbodyの最後に置ける広告コードと違い、圧縮状態で30KBのコードが展開され、パースされ、ロードされるまでそのページはブロックされる。
jQueryはロードしたねヨカッタヨカッタというようなライブラリではなく、導入しているからには様々なプラグイン、依存ライブラリ、依存コードの依存先となる。
つまり非同期読み込みできない。bodyの下のほうに置いてる場合でもない。head内でなるべく早く読み込まなければ依存コードが動かない。
なのでbodyの最後に置ける広告コードと違い、圧縮状態で30KBのコードが展開され、パースされ、ロードされるまでそのページはブロックされる。
jQueryはbodyの最後におけるよ
実際にやってる人いた
jQueryとCSSを最後に読み込ませてサイトの表示速度を上げる方法
http://hodalog.com/move-jquery-to-footer/
たしかにjQueryを最後の方で読み込ませることで
表示速度が改善されているね
実際にやってる人いた
jQueryとCSSを最後に読み込ませてサイトの表示速度を上げる方法
http://hodalog.com/move-jquery-to-footer/
たしかにjQueryを最後の方で読み込ませることで
表示速度が改善されているね
最近はwebpackで一つないし少数のファイルに結合してしまうけど、
昔RequireJSを使っていた頃は、jQueryを含めて依存プラグイン全てを
非同期で読み込ませていたな
どういう仕組みかと言うとRequireJSが全てのJavaScriptファイルを
同時に読み込み、依存関係情報に従って、すべてが揃ってから発動する
だから、jQueryをjQueryを使うライブラリを非同期で両方同時に読込始めて、
先にjQueryを使うライブラリの読み込みが終わったとしても
jQueryの読み込みが終わってからライブラリの処理が発動するから問題なく動作する
昔RequireJSを使っていた頃は、jQueryを含めて依存プラグイン全てを
非同期で読み込ませていたな
どういう仕組みかと言うとRequireJSが全てのJavaScriptファイルを
同時に読み込み、依存関係情報に従って、すべてが揃ってから発動する
だから、jQueryをjQueryを使うライブラリを非同期で両方同時に読込始めて、
先にjQueryを使うライブラリの読み込みが終わったとしても
jQueryの読み込みが終わってからライブラリの処理が発動するから問題なく動作する
操作前のDOMが描画された後にガチャガチャ動いて良いなら当然そうできる。
ただし依存コードもすべてその後ろに置くこと。
コードの規模にもよるが、大きくなるにしたがって姿は見えれどインタラクション不能状態が長くなる。
ただし依存コードもすべてその後ろに置くこと。
コードの規模にもよるが、大きくなるにしたがって姿は見えれどインタラクション不能状態が長くなる。
>>75
jQueryに限らずDOMを操作するものは全て同じことでは?
広告はページ本編から独立しているから、問題ないのであって
同じように独立していればjQueryでも同じことできるし。
えーと、なにが良いたいんだい?
最初の一回は読み込むのが遅いけど、二回目以降は
まったく問題ないよで解決するよね。
jQueryに限らずDOMを操作するものは全て同じことでは?
広告はページ本編から独立しているから、問題ないのであって
同じように独立していればjQueryでも同じことできるし。
えーと、なにが良いたいんだい?
最初の一回は読み込むのが遅いけど、二回目以降は
まったく問題ないよで解決するよね。
アホがjQury厨を召喚したせいでまたjQueryのすれになっとるわ
死ねよカス
別スレでやれやばーか
死ねよカス
別スレでやれやばーか
同じサイトで2回目以降問題ないのは当たり前だろ
無関係のサイトでも同じcdnから読んでればキャッシュ効くのがいいとこなのに
無関係のサイトでも同じcdnから読んでればキャッシュ効くのがいいとこなのに
>>61,63
(nullはオブジェクトではないけど)
オブジェクトに対するnullみたいな存在だよ
他にもInfinityとか、0が+-の2種類あるとか、double型ならではの仕様があるけれど
結局それらもNaNも全部ひっくるめてJSの数値の内なんだよ
JSの仕様と言うかもうCPUに内蔵されてる仕様で、
1.0+1.0が2.0になるように、1.0/0.0などをするとNaNになる
それらは全てdouble=64bit型の数値であってビット配列が違うだけなんだよ
(nullはオブジェクトではないけど)
オブジェクトに対するnullみたいな存在だよ
他にもInfinityとか、0が+-の2種類あるとか、double型ならではの仕様があるけれど
結局それらもNaNも全部ひっくるめてJSの数値の内なんだよ
JSの仕様と言うかもうCPUに内蔵されてる仕様で、
1.0+1.0が2.0になるように、1.0/0.0などをするとNaNになる
それらは全てdouble=64bit型の数値であってビット配列が違うだけなんだよ
ちょっと自分もどういう流れで話してたか忘れそうだから纏めるけど、
だから通常の数値=doubleが期待される関数でNaNが返ってくるのは極めて自然なんだよってこと
それとJSの数値がdoubleであることによる特徴と、int/uintの特徴と、int/uint化の手法
くらいはしっかり理解しておくのもいいよということ
(概念上は一時的だけど)intにキャストすればInfinityや-0、NaNなんかは出てこないからね
だから通常の数値=doubleが期待される関数でNaNが返ってくるのは極めて自然なんだよってこと
それとJSの数値がdoubleであることによる特徴と、int/uintの特徴と、int/uint化の手法
くらいはしっかり理解しておくのもいいよということ
(概念上は一時的だけど)intにキャストすればInfinityや-0、NaNなんかは出てこないからね
浮動小数点数の演算においてゼロ除算の結果の扱いと
文字列をintに変換しようとしたときの扱いと
全然関係なくね
文字列をintに変換しようとしたときの扱いと
全然関係なくね
文字列をInt型に変換しようと思ってparseIntを使ったという話ならそれは確かに
parseIntが悪いっていうか紛らわしいってことになるかもしれないね
ただ、(ES.nextの話は抜きで簡単に言うと)
JSの数値っていうのは全てdouble型だからね
Int型を返す関数っていうのは無いの
parseIntのIntは、元のJavaでは確かにint型のIntの意味合いもあるけど、
JSではせいぜいInteger=整数っていう程度のものと考えると良い
つまり文字列の中の整数(=integer)を抜き出して、double型で返す関数ということ
そしてdouble型を返す関数に於いて、不正な値を例えば0にするか、それともNaNを返すか
どちらが自然かと言えばやっぱり後者だろうよ
parseIntが悪いっていうか紛らわしいってことになるかもしれないね
ただ、(ES.nextの話は抜きで簡単に言うと)
JSの数値っていうのは全てdouble型だからね
Int型を返す関数っていうのは無いの
parseIntのIntは、元のJavaでは確かにint型のIntの意味合いもあるけど、
JSではせいぜいInteger=整数っていう程度のものと考えると良い
つまり文字列の中の整数(=integer)を抜き出して、double型で返す関数ということ
そしてdouble型を返す関数に於いて、不正な値を例えば0にするか、それともNaNを返すか
どちらが自然かと言えばやっぱり後者だろうよ
var 試合結果出力 = () => {
var rand = Math.rand();
var 阪神勝利フラグ = true;
console.log(阪神勝ちフラグ ? '阪神勝利!' : rand > 0.5 ? '阪神勝利!' : '阪神敗北…');
};
試合結果出力();
var rand = Math.rand();
var 阪神勝利フラグ = true;
console.log(阪神勝ちフラグ ? '阪神勝利!' : rand > 0.5 ? '阪神勝利!' : '阪神敗北…');
};
試合結果出力();
以上のように、数値リテラルには様々な表現方法がありますが、本質的にはこれらの違いは見かけ上のものに過ぎません。
JavaScriptにとっては「0b10010」(2進数)、「0o22」(8進数)、「0x12」(16進数)、「1.81e1」(指数は)はいずれも同じく10進数の18なのです。
どの表記を選ぶかは、その時々でのよみやすさに応じて決めるべきです。
JavaScript本格入門より
JavaScriptにとっては「0b10010」(2進数)、「0o22」(8進数)、「0x12」(16進数)、「1.81e1」(指数は)はいずれも同じく10進数の18なのです。
どの表記を選ぶかは、その時々でのよみやすさに応じて決めるべきです。
JavaScript本格入門より
10進数と言うのは嘘だな。
ならどうして0.1 + 0.2が0.30000000000000004になるんだい?
2進数だろう?
ならどうして0.1 + 0.2が0.30000000000000004になるんだい?
2進数だろう?
合ってない。
> いずれも同じく10進数の18なのです。
8進数の22なのです。
16進数の12なのです。
"8進数" リテラル を
内部的に2進数に変換して計算しているからだけど?
だから8進数であっている
"16進数" リテラル を
内部的に2進数に変換して計算しているからだけど?
だから16進数であっている
> いずれも同じく10進数の18なのです。
8進数の22なのです。
16進数の12なのです。
"8進数" リテラル を
内部的に2進数に変換して計算しているからだけど?
だから8進数であっている
"16進数" リテラル を
内部的に2進数に変換して計算しているからだけど?
だから16進数であっている
phpにおけるNAN(phpにおいてはNaNじゃなくてNAN)がphpにおいてはfloat/double型に属するというのはいい
しかしNANが数値だとすると以下が成り立ってしまうのではないか
前提1: NAN - 1 は NAN となる
前提2: NAN - 2 は NAN となる
∴1=2である
しかしNANが数値だとすると以下が成り立ってしまうのではないか
前提1: NAN - 1 は NAN となる
前提2: NAN - 2 は NAN となる
∴1=2である
∞に1を足しても∞に2を足しても∞なのは変わらない
しかし1=2とはならない
それは∞が特定のある数値を指すものではなく、∞=無限大という概念を指すものだから
NaNも同じ
しかし1=2とはならない
それは∞が特定のある数値を指すものではなく、∞=無限大という概念を指すものだから
NaNも同じ
JS は、内部的には整数は無い。
数値型は、Double のみ
整数かどうか判断できる、関数もない
一方、Ruby では整数型もある
数値型は、Double のみ
整数かどうか判断できる、関数もない
一方、Ruby では整数型もある
>>94
NaNはdouble型で非数値なんだよ
そう書いてあるでしょ?
http://php.net/manual/ja/function.is-nan.php
> NAN(phpにおいてはNaNじゃなくてNAN)
NANは誤植じゃないの
NaNと書いてある箇所もあるし、NANが正しいなら、"Not A Number" が正式名称になる
単数の "A" を大文字にするのはどう考えてもおかしい
NaNはdouble型で非数値なんだよ
そう書いてあるでしょ?
http://php.net/manual/ja/function.is-nan.php
> NAN(phpにおいてはNaNじゃなくてNAN)
NANは誤植じゃないの
NaNと書いてある箇所もあるし、NANが正しいなら、"Not A Number" が正式名称になる
単数の "A" を大文字にするのはどう考えてもおかしい
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.103 + (1001) - [97%] - 2012/11/9 15:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
トップメニューへ / →のくす牧場書庫について