TypeScript + React JSX + CSS Modules で実現するタイプセーフなWeb開発 - Qiita
はじめに 以前、React JSX with TypeScript(1.6)にて書いたことがありますが、TypeScript 1.6以降ではReact JSXを直接コンパイルできるオプションが追加されています。 一般的にクライアントサイドWebアプリ開発は以下の3言語が土台ですが、 JavaScript HTML CSS TypeScriptのお陰で、1.と2.についてはタイプセーフな世界を手に入れたことになります(HTMLの要素名や属性名まで含めて、コンパイル時のチェックがされる) JavaScript -> TypeScript HTML -> React JSX(.tsx) CSS -> ??? こうなると、3. におけるCSSについても、何とかできんものかと期待するのが人情です。 今回のエントリは、CSS ModulesをTypeScript JSX環境に統合することで、タイプセー
Imba 👐 Intuitive and powerful language for building web apps that fly
Imba is a new programming language for the web that compiles to performant and readable JavaScript. Imba was born to make developing web applications fun again.
babelify v7.2 を試す - アカベコマイリ
2015/10/29 に JavaScript の Transpiler である Babel の 6.0.0 がリリースされた。 6.0.0 Released これまでの Babel はデフォルトで ES6 と React JSX 変換に対応していたが、これからはプラグイン化されたものを指定する形式になるのだという。Browserify 用 Babel の babelify も同様で、これを最新に更新してコンパイルを実行すると ES6 部分が SyntaxError になる。 $ npm run build:js-main > electron-starter@1.0.4 build:js-main .../examples-electron/electron-starter > browserify -t babelify ./src/js/main/Main.js --im --no-
ReactでSPAを作るときのひな形を考えた - Qiita
問題提起 React.jsでSingle-Page-Applicationを作るときに、どんな構成にしたら捗るのか？を考えてみました。 ReactでSPAといったときにざっと問題として考えられそうなのは、 サーバーサイドを実装しなくても、クライアントだけで動作確認したい。 再利用できそうなコンポーネントと、そのページでしか使わないコンポーネントを分けたい。 コンポーネントは独立しているべき（グローバル依存しない） Reactコンポーネントだけじゃ足りないので、古いライブラリやCSSも扱いたい。 開発時のビルドが遅いのはイヤだ。（差分ビルド欲しい） 全体をテストするのは重たいから部分的にテストしたい。 設定ファイルがあちこちに散らばるのはイヤだ。 ES6のフィーチャーを使いたいが、下位互換性も担保しないと。 あたりでしょうか。 今回は、この辺の問題をある程度汎用的に解決する案を考えてみました
ES5 + Facebook JSXで書かれたJavaScriptコードベースをTypeScriptに移行させる - CARTA TECH BLOG
皆さんこんにちは。adingoにてFluctという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 今回は、表題の通り、実際にプロダクトとして動いている既存のコードベースを、ES5ベースからTypeScriptに段階的に移行させた話について書こうと思います。 移行前のコードベース及び直面した課題 今年の1月頃から、アプリケーションのクライアント側の一部を、以下の構成で実際に開発しています。 言語 ECMAScript 5 主要な依存ライブラリ UI開発にReactおよびFacebook JSX syntax 統合イベントシステムとしてのRxJS テストコードのアサーションにpower-assert ビルドチェーン モジュール連結にbrowserify 環境変数に基づくビルドフラグ用途でenvify コードの解析とLintにESLint 未使用変数や未定
JSX と TypeScript の混合 Flux または悪魔合体
JSX + TypeScript の悪魔合体 ギョーム的に気持ちになったので JSX + TypeScript をはじめました。 導入にあたってチーム内への説明を兼ねたブログ。AltJSに対して ES でいいじゃん派ですが、自分の型需要に対して 現状の Flowtype が辛みしかないのでやむをえず。 動機 紆余曲折あって結局 React を使うことにした React Component には JSX with Babel を使いたい（手書きは無理だ） UI 以外のロジックを持ったモジュールは型の恩恵に預かりたい Flowtype つらい TypeScript かー UI 周りは JSX で、その他の堅いロジックは TypeScript で書けばいいのでは？ 共存だ！！ メリットがあるのかも不明瞭ですが、分からないからこそ試してみようという感じです。JSX と TypeScript の境界
AltJSの選び方フローチャート - Qiita
JavaScriptわかる - YES 型がほしい - YES Flash/ActionScript3が青春だった - YES Haxe - NO DeNAに勤めている - YES JSX - NO TypeScript - NO Ruby or Python が好き - YES coffee-script - NO クラスはほしい - YES EcmaScript6(Traceur Compiler) or CoffeeScript - NO JavaScriptの文法に不満がある - YES https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS - NO JavaScript書けよ - NO 関数型わかる - YES 自分の好きな言語に深く精通している - YES 好きな言
続々出てきた JavaScript 系新言語。どれを使う? | プログラマーズ雑記帳
先に選択方針を図にまとめたものをあげておきます。 JavaScript 系新言語のどれかは使うべき ? 最初にそもそも何か新しい言語を使う必要があるのか? というところから考えてみましょう。 JavaScript に変換する言語あるいは取って代わろうとする言語 がいろいろできてきている状況を考えると、 今のままの JavaScript には問題がある と多くの人が思っていることは間違いないです。 そのため、今後は JavaScript を直接書くのはやめて、 どれかの言語は使うべきだと思います。 JavaScript にもいいところはある、 新しい言語を覚えるのは大変という人も多いでしょう。 しかし、理由は後で説明しますが、そういう人でも TypeScript は使うべきです。 対象言語 ここに挙げたもの以外にもありますが、私が有名だなと思うものと対象にしました。 CoffeeScript
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kriasoft/react-starter-kit: The web's most popular Jamstack front-end template (boilerplate) for building web applications with React