Payment Request API のよくある誤解を解く
このポストは Chromium Browser Advent Calendar 2017 の 12/8 分です。先日 Medium に投稿した英語版を翻訳し、日本向けに若干加筆したものになります。 Payment Request API が登場してからというもの、おかげさまで非常に多くの方に興味を持っていただいています。一方、その複雑さから勘違いや、誤った情報を元に盛り上がってしまっているような状況が起きています。この記事では、みなさんの反応を見ている中でよくある誤解を解き、正確な情報を提供しようと思います。 そもそも Payment Request API が何かご存じないという方は、まずここから読んでいただくと良いと思います。 Web Payment API? Chrome Payment API? Google Payment API? # すべて間違いです。正しくは "Paymen
新QiitaでReactをやめてhyperappを採用した背景 - Qiita
12/1 に Qiita のトップページをリニューアルしました。これまで React を使っていましたが、それをやめて hyperapp を採用しました。まわりを見てもあまり採用事例が見当たらないので、この記事では一体なんで今をときめく React ではなく hyperapp を選択したのか、どういうところが魅力的なのかについて プレゼンテーション層を実装するためのツールとして 学習コスト の観点から書きたいと思います。なおこの記事に書かれていることは全て個人の感想であり、はっきりいって個人の日記レベルです。 それと hyperapp の開発者が社内にいるという事情もあるので、そこら辺さっぴいて読んでください。 TL;DR プレゼンテーション層を実装するためのツールとして React は機能過多だし、機能不足 hyperapp は過不足ない 学習コスト 仮想 DOM は学ぶ価値のある知識
イマドキのJavaScriptの書き方2018
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
webpack時代の終わりとparcel時代のはじまり - Qiita
設定不要のビルドツール parcelというビルドツールが空前の勢いでGitHubスターを集めており、リリース数日で5000スターを超えています。今日だけでも1000スター以上増えており、Googleなどの有名企業リポジトリ以外でこのスピードで人気がでるのは異例です。 https://github.com/parcel-bundler/parcel https://parceljs.org/ 実際に試してみたところ、これはwebpack一強時代を終わらせるレベルの使いやすさだと確信しました。 作者はAdobeのエンジニアで、その他著名エンジニアも続々と参加している様子です。 webpack疲れ webpackが出た当初、webエンジニアはgulp/grunt疲れの状態だったことを覚えている方もいるかと思います。 webpackの統合された設定ファイルは、タスクランナーで逐次処理していたものを
Handlebars
Semantic templates Handlebars provides the power necessary to let you build semantic templates effectively with no frustration. Mustache-compatible Handlebars is largely compatible with Mustache templates. In most cases it is possible to swap out Mustache with Handlebars and continue using your current templates. Fast execution Handlebars compiles templates into JavaScript functions. This makes th
<a>か<button>か - hitode909の日記
クリックできるものがあって，<a>にするか<button>にするか，という話をしていて，いろんな観点があるなと思ったのでメモ． 単なる画面遷移なら<a> 単にformを送信したいときは，<input type="submit">や<button> <button>はdisabled属性を使って無効状態にできるので，押せない場合もあるなら便利 リンクを<a>にしておくと，PCではホバーするとリンク先が見えるので，ユーザーにとっては何が起きるか予想できて便利 そう考えるとformは押してみるまでどこに飛ぶか分からないので怖い気がする リンクを<a>にしておくと，:visitedを使って訪問済のリンクの色を変えることができて便利 モーダルウィンドウを出すとき，ウェルカムメッセージを開くボタンを<a href="#welcome">として，/#welcomeのときにウェルカムメッセージを出す，とし
VS CodeがDOMによるターミナル実装のパフォーマンスを改善できなかったためCanvasに変更
Integrated Terminal Performance Improvements Electronという史上まれに見るそびえ立つクソのようなGUIプラットフォーム上で実装されているVS Codeが、ターミナルの実装をDOMによるものからCanvasによるものに変更したそうだ。これは、DOMによる実装ではパフォーマンスの改善が十分にできなかったからだという。 DOMでターミナルを実装する際の問題ごととして、テキスト選択、テキストアライメント、GC、パフォーマンスを上げている。 テキスト選択：ターミナルのテキスト選択を実現するためにDOMのテキスト選択の挙動をだいぶ上書きしなければならない。 テキストアライメント：一部の文字はモノスペースになってくれず、workaroundとして一文字ごとに固定長のspanで包む必要があるが、これはパフォーマンス上よろしくない。 GC：DOMでターミナ
ファミコンのエミュレータを書いた - undefined
概要 ファミコンのエミュレータをJSでだらだらと作ってた。そこそこ遊べるようになったので公開しておく。技術的な内容は、またどこかで発表したり、Qiitaなどにまとめたい。（忘れないうちに。需要があるかは怪しいが。） 随分昔に作ってみたいなーと思いFPGAでの実装を開始したんだけど、早々に挫折した覚えがある。今思うとFPGAの場合タイミングの問題が付き纏うのでJSで書くより圧倒的に難易度も高いし、ハードエミュレータを実装するにしても前段階としてソフトウェミュレータを実装するのが定石っぽいので無謀だったっぽい。 ひとまずMapper0という基本的なカセット形式のみに対応し、スーパーマリオブラザーズがそこそこ遊べるくらいを目標とした。 成果物 github.com ファミコンのスペック MPU 6502(RP2A03), 8bit WRAM2KB VRAM 2KB 最大発色数 52色 画面解像度
フロントエンドが嫌い
ウェブフロントエンドの技術の進歩と興亡の速度には目を見張るものがある。 browserifyが生まれ、Gruntが生まれ、Gulpが生まれた。 そしてその全てが死んだ。 Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。 一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。 そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプターを自称し最新技術のケツを追いかけQiitaにクソを垂れ流す彼らこそ我らがイケイケウェブフロントエンジニアである。 最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれた
Polyfill のあり方と Web の進化と協調するためのガイドライン | blog.jxck.io
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、 Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、 Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、 Web における Breaking Change (Break the Web)、具体的には W
2017年のフロントエンドエンジニアならこの程度は知ってて当然だよな？ - Qiita
って海の向こうの人が言ってました。 私はjQueryさえあれば概ね生きていけるので全然知らないけど、 あなたは全部知ってるフロントエンドエンジニアなんだね。すごーい！ 以下はFront-End Developer Handbook 2017の第三部、Front-end Developer Toolsからリンクされているツールと、その簡単な紹介です。 ドキュメントツール Dash 150以上のライブラリのAPIリファレンスを検索できる。有料、Mac専用。 DevDocs 200以上のライブラリをオンラインで検索できる。無料。 Velocity 中身はDashと同じ。 有料、Windows専用。 Zeal 200以上略 無料のオフラインドキュメント。 SEOツール Keyword Tool 検索ワードを入れると関連キーワードを教えてくれる。 Google Webmasters Search C
JavaScript の Number() は副作用がある可能性がある - Qiita
たまたまTwitterを見てたら以下のようなツイートを見かけました。 つまり、 isNumber っていう関数を作るなら一旦Numberでキャストした値と同一かどうかを比較すれば良いと。おそらく NaN を省いた number 型を true にしたいのかなという感じがする (NaN === NaN は必ず false)。 ただこれには問題があるらしく、 V8 のOptimizerリーダーである bmeurer から下記のようなレスが付いてました。 「 Number() では意図しない副作用があるかもしれない」という意味のレス。最初意味がわからなくて、「おや？」と思ったんですけど、その後で補足が。 「ToPrimitive関数が呼ばれてしまい、意図しないJSの動きをするかも。」とのこと。 つまり、 var a = { x: 1, [Symbol.toPrimitive]: function
ES2015～2017に無い初見殺しコード3つ紹介 - Qiita
皆さんもうES2015は大丈夫でしょうか？（私はいまだに理解が怪しいものがあります） 今回はES2015にもES2016にもES2017にもまだない、 だけどよく見る構文を3つ紹介したいと思います。 Rest/Spread Properties (stage-3) spread operatorのオブジェクト版（初見殺しと言いつつ、1つめは大したことなかった）。 配列や関数の引数に対する（...）はES2015で追加されたんですが、 オブジェクトに対する（...）はまだ正式な仕様になっていません。 （...）をオブジェクトに対して使うと、以下のようなコードが書けるようになります。 // Rest Properties let { x, y, ...z } = { x: 1, y: 2, a: 3, b: 4 }; x; // 1 y; // 2 z; // { a: 3, b: 4 } /
たぶんこれが一番分かりやすいと思います React + Redux のフロー図解 - Qiita
【追記】 もうこれ古いから参考にしないでください https://t.co/mXtcc73Orf — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 Redux にはその昔 connect()() とかいうクソ API と， Redux-Saga とかいう宗教がありました という考古学です — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 読者対象 Tutorial: Intro To React - React Example: Todo List · Redux 「チュートリアルそれぞれ一周した！Reactは何とか理解できたが，Reduxがさっぱりわかんねぇ！」 ぐらいの人向け。自分
JavaScriptはなぜトレンドが毎年変わると思われていたのか - Qiita
JavaScriptはなぜトレンドが毎年変わると思われていたのか JavaScriptのエンジニャーは口を開くたびに出てくるツール名が違う、いつも環境設定をしている、みたいな話をよく聞きます。実際、それを揶揄するようなエントリーが人気だったりします。 とはいえ、JavaScriptを実際に使い込んでいる人は別にそんなに大きな変化だと思っていない節があって、台風は外周部ほど風速が速い、みたいな印象を感じます。 カンブリア紀のJavaScript ウェブサイトをパカパカ動かすための言語でした。DHTMLです。FireBugが出る前のJavaScriptを開発していた人類は、念力デバッグを駆使していました。あるいはalert()。 三畳紀のJavaScript prototype.js、jQuery、Closure Compiler、YUI、mochikit、Ext.jsなどの時代。JavaSc
JavaScript初級者のためのコーディングガイド - Qiita
JavaScriptは大変難しい言語です。Rubyの難易度を2、Cの難易度を5、C++の難易度を8にすると、JavaScriptの難易度は12ぐらいあると思います。このコーディングガイドはそんなJavaScriptの深みに嵌まらないようにするためのJavaScriptの書き方を規定したものです。初級者1のための物ですので、わかってやっている人に好きにやってください。 このコーディングガイドは絶対に従わなければならないものではありません。私は一切強制はしませんし、初級者が従わなければならないという義務もありません。採用するしないはみなさんの自由です。 禁止編 JavaScriptには安易に使用してはいけない機能があります。下記の機能は、それぞれの機能を使っても良い、または、使うべきであるという理由を説明できない限り、使用してはいけません。 ==、!= ==と!=を使用してはいけません。代わり
2020年に振り返る2016年のWeb開発
後輩「先輩、このシステム僕が引き継ぐ事になりました。よろしくお願いします」 先輩「そうかそうか、やっと肩の荷がおりるな」 後輩「これ2016年に作ったシステムなんですよね。僕その頃まだ入社してないんで、最初の方から教えてもらっていいですか」 先輩「よしわかった。環境構築から順を追って説明する」 〜 先輩「まずはじめにnode.jsを入れる」 後輩「あ〜昔流行ったサーバーサイドでJavascript使えるやつですよね。このシステムnodeで動いてたんですね」 先輩「いや、nodeは使ってない」 後輩「え？」 先輩「nodeに付属しているnpmというパッケージマネージャーを使ってる」 後輩「なんでまたそんな回りくどいことを・・・」 先輩「当時はnpmが一番メジャーだったんだよ。今主流のN3(N3 is Not Npm)はまだ無かったしな」 〜 先輩「よしnode入れたな。じゃあnpm inst
最近のフロントエンドの変化とビルドツールについて - mizchi's blog
界隈の雑な会話です。注意点として、フロントエンドガチ勢寄りの方面なので、一般的な感覚とは乖離してる可能性があります。 基本的には http://www.s-arcana.co.jp/blog/2016/12/12/3438 や kikuchi1201.hateblo.jp を念頭に。 動き早いって言われるフロントエンド界隈、この1年何も進んでないからな— 現場の声 (@mizchi) 2016年12月14日 今年のフロントエンドの統括、es2016でしょぼかったので皆es2015+ みたいなノリが抜けなかったのと、redux以外のfluxが脱落したのと、angular2+今年も出なかったねというのと、たぶん eslint の採用が増えてそう(肌感)のと、flowの採用が増えたぐらい— 現場の声 (@mizchi) 2016年12月14日 実際browserify/webpackは先行実装だ
技術の流行についてゆくこと - アカベコマイリ
以下の記事とはてブを受けての所感。 【翻訳】 2016年にJavaScriptを学んでどう感じたか - Endo Tech Blog はてなブックマーク - 【翻訳】 2016年にJavaScriptを学んでどう感じたか - Endo Tech Blog JavaScript による Web フロントエンド開発環境について総括する記事があると、はてブでは拒否反応が多く見られる。特にフレームワークやライブラリの乱立や JavaScript/CSS の Transpiler 周りに忌避感があるようだ。 確かに複雑である。しかし「それが何の問題を解決しているのか？」に注目すれば単純な要素技術の集合であることが理解できるはず。 例えば Browserify、webpack、Babel などの Transpiler/Bundler 系と ES2015 や TypeScript の関係は、JVM や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Swig - A Node.js and Browser JavaScript Template Engine