私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.136 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>398
メソッドをはやした所で連携はできないよ
メソッドをはやした所で連携はできないよ
まつたけってw
せめてちんこより大きいもので例えなきゃ意味ないじゃん
せめてちんこより大きいもので例えなきゃ意味ないじゃん
>>393
数十あるファイルの読み込み・コンパイルを並列に行うから、CPU 使用率も高い。
PC のエコモードで、1つのCPUだけにすれば、CPU使用率は低い
客は電力について、何にも知らないだろ
速さを競っているブラウザは、電力を食う
数十あるファイルの読み込み・コンパイルを並列に行うから、CPU 使用率も高い。
PC のエコモードで、1つのCPUだけにすれば、CPU使用率は低い
客は電力について、何にも知らないだろ
速さを競っているブラウザは、電力を食う
遅いほうが電力食うよ
遅いと処理の完了まで時間かかるだけで処理に費やす電力は大差ない
それとは別にバックライトとかの一定の電力が時間がかかればかかるほど食う
単純な話、100秒で終わる処理を100000秒掛けてたらどんだけその処理に費やす電力が小さくてもバッテリー切れする
遅いと処理の完了まで時間かかるだけで処理に費やす電力は大差ない
それとは別にバックライトとかの一定の電力が時間がかかればかかるほど食う
単純な話、100秒で終わる処理を100000秒掛けてたらどんだけその処理に費やす電力が小さくてもバッテリー切れする
>>407
ウェブアプリケーション的なの作るにはわりと重要なファクターなんだよ
ウェブアプリケーション的なの作るにはわりと重要なファクターなんだよ
「消費電力を減らすにはどうしたらいいんだ」
「画面を暗くしましょう」
「暗く?そうしたらせっかくのかっこいいMacがダサくなるではないか」
「いいえ、かっこいいんです」
「?」
「いいですか、暗いというのはかっこいいんです」
「だが・・
「かっこいいんです。」
「わ、わかった。そういうことにしよう」
「わかればいいんです。名前をダークモードにしましょう」
「なんだその、中二病まんさ・・
「かっこいいんです。」
こうして消費電力を減らすという目的のために
ダサいデザインが出来ました
「画面を暗くしましょう」
「暗く?そうしたらせっかくのかっこいいMacがダサくなるではないか」
「いいえ、かっこいいんです」
「?」
「いいですか、暗いというのはかっこいいんです」
「だが・・
「かっこいいんです。」
「わ、わかった。そういうことにしよう」
「わかればいいんです。名前をダークモードにしましょう」
「なんだその、中二病まんさ・・
「かっこいいんです。」
こうして消費電力を減らすという目的のために
ダサいデザインが出来ました
とりあえずアニメーションを多用するなってのと画像は圧縮しろとしか言えない
全然重要じゃない。
最近はモバイル製品のバッテリーの持ちもよくなってるし充電スペースも増えてる。
最近はモバイル製品のバッテリーの持ちもよくなってるし充電スペースも増えてる。
http://developer.mozilla.org/ja/docs/Web/API/Window/postMessage
otherWindow.postMessage(message, targetOrigin);
で、
otherWindow.postMessage(message, '*');
だと全部のサイトに送信されるんですよね?
では、httpsのサイトのみに送信したいので、
otherWindow.postMessage(message, 'https://*');
みたいなのは出来ますか?
otherWindow.postMessage(message, targetOrigin);
で、
otherWindow.postMessage(message, '*');
だと全部のサイトに送信されるんですよね?
では、httpsのサイトのみに送信したいので、
otherWindow.postMessage(message, 'https://*');
みたいなのは出来ますか?
そこに指定するのは「オリジン」だからそういうことはできない
あとそれは古い書き方で今はオブジェクトで
{targetOrigin: '~' }と渡すほうが良い
あとそれは古い書き方で今はオブジェクトで
{targetOrigin: '~' }と渡すほうが良い
>>393
他には、60/秒など、フレームレートが高いと、電力を食う
他には、60/秒など、フレームレートが高いと、電力を食う
フレームレートが低いとUX を損なうでしょ
今の時代にまだ人間を犠牲にして機械を尊重してるとかナンセンス
今の時代にまだ人間を犠牲にして機械を尊重してるとかナンセンス
日本製のカーナビってフレームレート低いよなぁ
何で5fpsしか出てないの?カックカクやん
あと液晶テレビの番組表とかも同様
トルネのヌルヌルサクサクUI/UXを見習え
いまならARMのSoC搭載すりゃ同等の表現できるだろうに・・・
フレームレートは60fps必須だよね
スマホでたまにカクカクしてるアプリみかけるけど速攻削除してるわ
UX意識してないサイトやアプリは使う気になれない
何で5fpsしか出てないの?カックカクやん
あと液晶テレビの番組表とかも同様
トルネのヌルヌルサクサクUI/UXを見習え
いまならARMのSoC搭載すりゃ同等の表現できるだろうに・・・
フレームレートは60fps必須だよね
スマホでたまにカクカクしてるアプリみかけるけど速攻削除してるわ
UX意識してないサイトやアプリは使う気になれない
webview使った側アプリだとモッサモサになる
React NativeやVue Nativeなどのネイティブアプリとして出力できるフレームワーク使うと改善される。
http://gamebiz.jp/?p=185520
>当初スマートフォン版はCSSやJavaScriptを駆使したHTML5で開発したのですが、端末のスペックによっては、
>魚がカクカク動いたり瞬間移動したように見えたり表現に限界がありました。
>現在でも使っているCocos2d-js使ってネイティブアプリ化してレンダリングすることで、Androidユーザーにスムーズに魚が動くと言ってもらえるようになりました。
React NativeやVue Nativeなどのネイティブアプリとして出力できるフレームワーク使うと改善される。
http://gamebiz.jp/?p=185520
>当初スマートフォン版はCSSやJavaScriptを駆使したHTML5で開発したのですが、端末のスペックによっては、
>魚がカクカク動いたり瞬間移動したように見えたり表現に限界がありました。
>現在でも使っているCocos2d-js使ってネイティブアプリ化してレンダリングすることで、Androidユーザーにスムーズに魚が動くと言ってもらえるようになりました。
CSSやJSを駆使とか言ってるから限界に達したんだろ
昔はCSSやJSじゃ遅いからSVGアニメをどう駆使するかが最も重要なテクだったよ
昔はCSSやJSじゃ遅いからSVGアニメをどう駆使するかが最も重要なテクだったよ
質問です
xpathで「あるノードの次のノード」(1つ次のやつだけ)を指定する方法ってないんでしょうか。
例えば //td[@class="hoge"] で特定できるノードがあるとしてその右隣のtdを取得したいです。
//td[@class="hoge"]/next-sibling::td みたいに書ければいいと思うんですが。
xpathで「あるノードの次のノード」(1つ次のやつだけ)を指定する方法ってないんでしょうか。
例えば //td[@class="hoge"] で特定できるノードがあるとしてその右隣のtdを取得したいです。
//td[@class="hoge"]/next-sibling::td みたいに書ければいいと思うんですが。
//td[@class="hoge"]/following-sibling::td[1]
react
anguler
vue
ってデザイナーが習得するの無理すぎない?
anguler
vue
ってデザイナーが習得するの無理すぎない?
>>430はthが挟まると条件満たさないから厳密にやるならこうか
//td[@class="hoge"]/following-sibling::*[position()=1 and self::td]
//td[@class="hoge"]/following-sibling::*[position()=1 and self::td]
あーすまん俺が勘違いしてた
JS/ESとMVCモデルを理解してないで使うのは難しいかもしれん
JS/ESとMVCモデルを理解してないで使うのは難しいかもしれん
>>430,432 ありがとうございます!
vueは生JSでも行けるから
jQueryを扱えるようなデザイナーならギリギリ行ける
Reactはトランスパイル前提みたいな部分があるから環境構築で詰む
jQueryを扱えるようなデザイナーならギリギリ行ける
Reactはトランスパイル前提みたいな部分があるから環境構築で詰む
例えば、はてなブログとかしている層が
ブログのデザインjsでちょこっと弄ろうとするのにReactは全く向いてない。
vueならギリギリセーフ。
ブログのデザインjsでちょこっと弄ろうとするのにReactは全く向いてない。
vueならギリギリセーフ。
ReactのJSXがキモすぎる
HTMLのタグにCSS埋め込むような気持ち悪さ
分離してくれよ
可読性さがるじゃん
HTMLのタグにCSS埋め込むような気持ち悪さ
分離してくれよ
可読性さがるじゃん
はぁReactでcss調整やってるんだけどさ、npmのビルドが5分かかるようになってきた
まだ1ページ目なのに
cssやるだけでビルドするの超作業効率悪い
まだ1ページ目なのに
cssやるだけでビルドするの超作業効率悪い
ReactでApp.jsにconst style =でcss書いてるんだけどさ、このstyleを子コンポーネントに渡すのって
いちいち子コンポーネントにパラメータ作って渡さないといけないの?
凄い苦痛…
いちいち子コンポーネントにパラメータ作って渡さないといけないの?
凄い苦痛…
だから殆どがHTML+CSSだけで構成されてる
よくあるウェブサイトをReactで作るとか無意味だって言ったろ?
Reactなんかは普段JavaScriptとDOMだけで作ってる
大規模なウェブアプリなんかを効率よく作るためのフレームワーク
JavaScriptをjQueryを使って少ししか使ってない所に
導入するのは破綻しかもたらさない
よくあるウェブサイトをReactで作るとか無意味だって言ったろ?
Reactなんかは普段JavaScriptとDOMだけで作ってる
大規模なウェブアプリなんかを効率よく作るためのフレームワーク
JavaScriptをjQueryを使って少ししか使ってない所に
導入するのは破綻しかもたらさない
reactやめてvue.js使いなよ
vueのベストプラクティス集めたnuxt.jsオススメ
コンポーネント形式でファイルが分割されてるから
HTML+CSSで作業するより効率的になってる
webデザイナはpageフォルダ以下のfoo.vueをいじるだけ
vueのベストプラクティス集めたnuxt.jsオススメ
コンポーネント形式でファイルが分割されてるから
HTML+CSSで作業するより効率的になってる
webデザイナはpageフォルダ以下のfoo.vueをいじるだけ
> コンポーネント形式でファイルが分割されてるから
HTML+CSSで作ってる人にとっては
そのコンポーネントの殆どが使わないものだろうさ
HTML+CSSで作ってる人にとっては
そのコンポーネントの殆どが使わないものだろうさ
Reactから依存外せるものは外したいなぁ
cssをjsxで作らないでscssにしてそっちだけビルドすればいいかな?
cssをjsxで作らないでscssにしてそっちだけビルドすればいいかな?
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + 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.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.106 + (1001) - [97%] - 2013/7/20 9:30
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.126 + (952) - [97%] - 2015/11/18 13:15
- + JavaScript の質問用スレッド vol.126 + (348) - [97%] - 2023/1/12 17:00
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [95%] - 2014/10/3 15:30
トップメニューへ / →のくす牧場書庫について