本当は1ヶ月前に下書きを書いた記事なのですが、 忙しくて見直す時間がなく、だいぶ遅くなってしまいました(´･ω･`) その間にバグfixを進め、一応安定動作していますし、 それもふまえた内容に書き換えていく方向で・・・ 相変わらずメンテと拡張を続けている 「チェンクロパーティーシミュレーター」（以下「ccpts」）ですが、 先日Reactでほぼ全体を書き換えました(`･ω･´) ccpts.parrot-studio.com github.com ちょうど1年ほど前、私がReactを初めて意識した際に、 一度やろうとしたことはあるのですが、 いろいろな理由*1があって諦めてました しかし、昨年から仕事でNode.jsを扱うように*2なり、 先日はccptsのロジックをFRPで整理するのに成功したりと、 今ならいけるんじゃないか・・・と思い、今回試してみたわけです React（+flux）に

去年の夏、私たちは大量のコードベース（18,000行以上の コード行数 ）をJavaScriptからTypeScriptへと変更しました。この移行作業を通じて、両者の相違点や類似点について大いに学び、TypeScriptの優れたユースケースや、TypeScriptを使うべきではないケースなどについて考えてみました。 型システムとは補助輪のようなものです。転倒防止してくれる代わりに、遅くなり、操作性が制限されます。 TypeScriptのユースケース コードサイズ ：ソースコードが膨大である場合、また複数の人がプロジェクトに従事している場合、型システムは明らかなエラーを防ぐのに役立ちます。 特に SPA の場合は当てはまります。誰かが変更したコードが他の人のコードを破損させてしまう可能性があるなら、何らかの安全機構を持つ方がいいでしょう。TypeScriptの トランスパイラ は明白な誤りを

こんにちは。良昌です。 Facebook、GithubなどのJSON形式でユーザ情報を返却するAPIや、PhoneGap、Monacaなどのスマートフォンのマルチプラットフォームを提供するライブラリ、IDEが開発ツールとして定着してきたことにより、JavaScriptを利用する機会が増えたのではないでしょうか。 今回は、JavaScriptコンテナがWebブラウザの場合に、動的に確保されるメモリ領域の浪費を避ける方法について書きたいと思います。 JavaScriptにおけるメモリの浪費を避けるコーディング JavaScriptにおけるメモリの浪費を避けるコーディングをするためには、GC(ガベージコレクション)、クロージャについての知識が必要です。まずは、この2つの機能について説明していきます。 ■GC(ガベージコレクション) GCとはプログラムが動的に確保したメモリ領域の内、不要になった領

古典的な構成のサービスを AWS Lambda + S3 で動作するサーバーレスアーキテクチャで再構築し、そのフロントエンドに Riot を採用しました。 プロジェクトは WWD JAPAN.com として公開しています。 React や Angular などに代表される JavaScript の UI ライブラリのうち、Riot はミニマルな API と HTML 標準に近い文法を採用しているのが特徴です。 Riot はコンポーネントベースの UI 開発から複雑さを取り除き、楽しさを与えます。 TL;DR Riot はこれまでの UI ライブラリと比べて以下の点で異なります。 必要最小限の API 少ないボイラープレート Web Components ( HTML Template ) に似た文法 React のコードと比較してみます。 ToDo アプリケーションを React で書くと

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Angular.jsのアドベントカレンダー6日目です。(遅れてすみません汗) 今日は泥臭い?感じの話になります。 この記事は言及している人達の記事やスタイルガイドのまとめという感じなのですが、これからディレクトリ構成を考える初学者の方や，ディレクトリ構成に悩んでるかたの参考になれば幸いです Angular.jsのディレクトリ構成パターン紹介と、利用して感じた考察などのことを書きます。 はじめに LIG主催のAngular.js勉強会 #ng-curry にて、登壇したときの発表内容をまとめようと思っていたのですが、今回のAdvent C

みなさんこんにちは、サイバーエージェントでフロントエンドを中心に開発しています原(@herablog)です。 アメブロでは、2016年9月にフロントエンドをJavaベースのアプリから、node.js・Reactベースのアプリへとシステムの移行をおこないました。本記事では、その移行へといたる経緯やゴール、システム設計、その結果についてお伝えします。 リリース直後に気づいているツワモノな方もいらっしゃいました。 アメブロのSP版がReactのSSRでフルリニューアルしたのを観測した — hr (@hrloca) 2016年9月1日 システム移行へといたる経緯 2004年から始まり、日本国内で最大規模のブログサービスとなったアメブロは、システムの肥大化や多数の関係者が存在したことによるモジュール・導線の急増などの理由により、ページ表示スピードが遅くなり、ページビュー数にも明らかに影響を与えるよう

問題点はIsomorphic実装難易度です。では、アメブロのIsomorphicの実装方法と実装する際にあった問題及びその解決策をお伝えします。 ちなみに、Michael Jackson氏はIsomorphic JavaScript ではなく、 Universal JavaScript と呼ぶべきだと主張しています。私たちはIsomorphic JavaScriptという名前で使うのに慣れたので、ここでは*Isomorphic JavaScriptと記述します。 AmebloのIsomorphic 技術選定 先に結論をあげます：React + Redux 技術選定の基準は下記となります。 安定さ。基本的にプロダクト環境で使える正式版があること。 アクティブな開発。 よいコミュニティ。技術の周りに大きいコミュニティが育っていること。 実績がある。 まずView層のライブラリの選定です。このプ

This document discusses Z-MUSIC, a JavaScript library that allows MML (Music Macro Language) music to be played by emulating the OPM and ADPCM sound chips of the X68000 computer through Web Audio API. It explains how the library works by using an AudioProcessorNode to handle audio processing callbacks from a compiled C++ emulator library. Challenges around managing the JavaScript main thread are a

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近話題のReact.jsですが、実戦投入に当たっては結構重たい選択を迫られることになります。 ざっくり言えば、テンプレートエンジンを捨ててReactしますか?それともReactあきらめますか?という選択です。 本記事ではReactの基本思想とこうした選択肢が生まれてしまう背景を述べるとともに、後半では「どちらもあきらめない」という(若干シミュレーションRPGあるある感のある)第三の方策について案を提示します。 Reactの基本 最初に、Reactの基本的な仕組みについてまとめておきます。 Reactは公式ドキュメントが非常に充実してい

東京Node学園祭2016で話したブッキングテーブルのやつ

Nodefest 2016 Nov 13

これは怪文書です ここから10年はWASMがDOMのGCインテグレーションを果たしてJSを置き換えるか、JSがWASMに追いつかれる前にまともな言語として進化しきれるかのチキンレースになる ES Modules のブラウザ実装が枯れた頃に先鋭化したフロントエンドツールセット群は一旦そこで破棄され、シンプル化への揺り戻しが起こる 仮想DOMはブラウザエンジンの何らかの処理で更新が隠蔽されるか専用のDOM更新APIができ、Reactのような実装の手を離れる WASMで git, vim, bashなどが porting されるにつれ、再びWebOSのようなものが試みられる TC39でJSの型アノテーションの構文だけだけ決めよう => V8 が型アノテーションを元にランタイムを最適化したぜ！ => 気づいたら標準化みたいな流れがある IE11のサポートは延長されず、MSがなんらかの強攻策に出る

※何度投稿しようとしてもBad Requestが出てしまったのでgistで投稿します。ご了承下さい。 gist.github.com

ReactとMaterial UIを組み合わせると、それだけでBrowserifyで結合したJavaScriptファイルが1MB超えてしまうので、やっぱり圧縮とかした方が良いのかな―と思い、やり方を調べてみました。 ※2015/08/03更新 Licensifyを開発された @t_wada さんから改良の連絡をいただいたので、Licensifyの最新版1.4.0をもとに内容を更新しました。 Licensify - Nodeモジュールのライセンスコメントを生成する JSファイルを圧縮すると、ライセンスが記載されているコメントが消えてしまうという問題があるということで、本題の前に、Browserifyと組み合わせて、読み込んだNodeモジュールのライセンスコメントを生成してくれる Licensify を試しておくことにしました。 インストールはnpmから。 $ npm install lice

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このポストは、Why I Left Gulp and Grunt for npm Scriptsを筆者の許諾を得て意訳したものです。間違いがありましたら、ご指摘いただけると幸いです。 （以下、訳） 私はGulpとGruntが不要な抽象化レイヤーだと気づきました。npmのscriptsはとても強力で、そっちの方が便利だったりします。 例を挙げましょう 私はかつてはGulpが大好きでした。しかし結局のところ、100行ものgulpfileと大量のgulpプラグインを扱うハメになりました。Gulp上でWebpackやBrowsersync、Mo

The following is a guest post by David Khourshid about how he uses Sass and the 7-1 pattern to style React components. React being all over the place these days, I am very glad to have him talking about his experience here. Chances are, as a frontend developer, you’ve heard of Facebook’s library for building user interfaces, React. Of course, an important part of building UI is styling it, as well

最近、JSを書く時はBabelを使ってES6で書いている。 mochaでテストを書く場合も下記で簡単に導入できる。 $ npm i -D mocha babel $ $(npm bin)/mocha --compilers js:babel/register そんな感じでTestiumとmochaで下記のようにテストケースを書いて、テストを実行するとエラーが出た。 // test/home.js 'use strict'; import injectBrowser from 'testium/mocha'; describe('Some page', () => { before(injectBrowser()); it('should display "Hello World"', () => { this.browser.navigateTo('/'); this.browser.as