Electron, Reactでタブブラウザを作ってみた - Qiita
知人がesaのデスクトップクライアントを使わなくなった理由が、複数タブが開けなくて不便だったと聞いた。 確かに「Electronのアプリでも複数タブが使えるといいな」と思ったのでさくっと作ってみました。 作ったもの タブ周りの処理を中心に書いた。ブラウザというよりただのQiitaリーダ。 環境 MacOS X 10.10.4 Node.js v.4.1.1 electron v.0.34.3 準備 Electron環境の導入が必須。 30分で出来る、JavaScript (Electron) でデスクトップアプリを作って配布するまでがとても参考になります。 今回はReactをES6で書くのでbabel+webpack+gulpの設定を書いておきます。 gulpfile.js webpack.config.js npmで必要なパッケージをインストールし、gulpでビルド用のタスクを起動すると
gulp ありの Web フロントエンド開発 - アカベコマイリ
gulp なしの Web フロントエンド開発 の追補編として gulp を利用するケースもまとめておく。元記事と同じプロジェクトと機能を gulp で実装した。記事の構成は「gulp なしの〜」を踏襲。各項の説明は package.json の scripts に代わって gulp タスクとしている。 設計方針 はじめに設計方針を決めておく。 AltJS から JavaScript へのコンパイルに対応する AltCSS から CSS へのコンパイルに対応する ファイル監視による AltJS/AltCSS の自動コンパイルに対応する ユニット テストに対応する コードド キュメント生成に対応する Windows 環境を考慮する 単体 gulpfile.js のみで実装する 方針 1 〜 6 までは「gulp なしの〜」と一緒。方針 7 は環境に関する設定を package.json と g
ReactでSPAを作るときのひな形を考えた - Qiita
問題提起 React.jsでSingle-Page-Applicationを作るときに、どんな構成にしたら捗るのか？を考えてみました。 ReactでSPAといったときにざっと問題として考えられそうなのは、 サーバーサイドを実装しなくても、クライアントだけで動作確認したい。 再利用できそうなコンポーネントと、そのページでしか使わないコンポーネントを分けたい。 コンポーネントは独立しているべき（グローバル依存しない） Reactコンポーネントだけじゃ足りないので、古いライブラリやCSSも扱いたい。 開発時のビルドが遅いのはイヤだ。（差分ビルド欲しい） 全体をテストするのは重たいから部分的にテストしたい。 設定ファイルがあちこちに散らばるのはイヤだ。 ES6のフィーチャーを使いたいが、下位互換性も担保しないと。 あたりでしょうか。 今回は、この辺の問題をある程度汎用的に解決する案を考えてみました
Babelを6系にアップデートしたらgulpでこける - Qiita
gulpの3.9.0からES6でタスクを記述できるようになったので使っていたけど、 Babelの6系にアップデートしたら動かなくなった。 ※ぼーっとしてたら最近いろいろアップデートされてていろいろ動かなくなっているので下の方に追記(2016/01/26) 現象 gulp: 3.9.0 babel-core: 6.0.14 以下のようにgulpコマンドでdefaultタスクを実行しようとしたところ importなんてしらない！と怒られる。。 [sawapi: ~/dev/git/sawapi/mw]$ gulp [17:11:48] Requiring external module babel-core/register /home/sawapi/dev/git/sawapi/mw/gulpfile.babel.js:3 import requireDir from 'require-di
gulp なしの Web フロントエンド開発 - アカベコマイリ
Web フロントエンド開発において gulp は非常に便利だ。しかしあまりにも gulp に依存しすぎており、これなしで開発できるだろうか？という不安もある。というわけで gulp を利用せず package.json と npm だけで同等の機能を実現する方法を検討してみた。 2015/11/4 追記 babelify v7.2 を試すで babelyfy 7.2 ( とその中の Babel 6.x ) について調べ、npm-scripts の変更が必要なことを確認したので追記。また Windows 環境の動作検証をおこなったところ、最新の watchify なら -o オプションが通ることを確認できた。よって本記事の最後の課題が解決したことになる。 2015/9/23 追記 cpx と rimraf を試すの内容をファイル処理に反映して簡略化。 2015/9/15 修正 Stylus
npm で依存もタスクも一元化する - Qiita
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
gulp × TypeScript × Browserifyな開発環境構築 - Qiita
概要 ビルドツール ： gulp altJS ： TypeScript モジュール管理： Browserify 以下で説明していく開発環境のひな形はGitHubに置いてありますm(_ _)m https://github.com/massa142/typescript-devenv 前提 Node.jsインストール済み。 Node.jsのインストール方法に関しては、以下の記事が詳しいのでご参照ください。 node.jsのversionを管理するためにnodebrewを利用する - Qiita 参考にしたもの TypeScriptリファレンス Ver.1.0対応 gulpでbrowserifyを使う | 4uing Usage npm install gulp tsd gulp (tsc| browserify | watch| minify) ファイル構成 root ├── src
Gulp + browserify + watchify + gulp-sass で自動高速コンパイル環境
Gulp とは Gulp は Web 制作に関するいろいろな作業を自動化するためのツールです。Sass のコンパイルや Gulp の使用には node.js や Sass などのインストールが必要なので、ちょっと古い記事ですが下記を参考に適当にインストールしてみてください。 browserify とは そんなに詳しくないのですが、browserify はざっくりと言えば js で requireを使えるようにするためのツールです。今までであれば複数の js ファイルが必要な場合、例えば、a.js と、a.js がないと動かないb.js を読み込む場合だと、HTML ファイルに下記のような記述が必要でした。 // index.html <script src=".js/a.js"></script> <script src=".js/b.js"></script> browserify を使
ブラウザとサーバで全く同じjavascriptを動かそう。[gulpとbrowserify超入門] - Qiita
はじめに この記事は、 gulpも browserifyも知らない 初心者を対象にしています。 最近になってnode.jsでプログラミングしていますよって人が対象です あまりにも０ステップからで、それくらいわかるよって事もあるかもしれません。 node.jsについて、０から勉強したい人はドットインストールとか便利かもね。 gulpって？browserifyって？ まず、gulpもbrowserifyもなんのことだか、さっぱりわからないって！ でも、まだ説明しません。 なぜなら、 なんで必要？を説明していないから。 目的は ブラウザとサーバで全く同じjavascriptを動かそう 最近は、node.jsでサーバサイドjavascriptも珍しくなくなってきました。 でも、微妙に違うサーバとブラウザでのjavascript！ 特に、違うなーと感じるのは、記述する場所ですね。 本当はもっといろい
![ブラウザとサーバで全く同じjavascriptを動かそう。[gulpとbrowserify超入門] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/1ff0a41ceecafa4e397802cc783f27b518beef93/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgyJUE2JUUzJTgyJUI2JUUzJTgxJUE4JUUzJTgyJUI1JUUzJTgzJUJDJUUzJTgzJTkwJUUzJTgxJUE3JUU1JTg1JUE4JUUzJTgxJThGJUU1JTkwJThDJUUzJTgxJTk4amF2YXNjcmlwdCVFMyU4MiU5MiVFNSU4QiU5NSVFMyU4MSU4QiVFMyU4MSU5RCVFMyU4MSU4NiVFMyU4MCU4MiU1Qmd1bHAlRTMlODElQThicm93c2VyaWZ5JUU4JUI2JTg1JUU1JTg1JUE1JUU5JTk2JTgwJTVEJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mZWU5MjYxYjk3ZjJhODU0ZWI4Yzk3ZmY2NmM3N2ZjMA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwY29jb3R0ZWpzJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1jNzgzMDgyZmFiOThlMmMxM2QyNDYyMTY3ZmE3ZGU1Yw%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D94c9deecde5a7e46e0f163c8d0a9ae18)
なぜ僕は(2015年のフロントエンドで、makeではなく)gulpを選ぶのか - mizchi's blog
http://d.hatena.ne.jp/m-hiyama/20150511/1431306678 の件 最初に 僕もgulpが今後生き残るかというと、かなり懐疑的です。開発パラダイムに合わせて変わっていくで、来年の段階で自分はgulp使えないなといっている可能性は十二分にあります。そのタイミングの一つはES6 import がHTTP2で並列ロードのオーバーヘッド無しで解決されるようになるタイミングでしょう。 根本的な問題として、Web周りは標準化の関係で動きが遅いです。最新の仕様ではままならず、ブラウザ間の実装がまちまちで、また開発上の要求が多様なのでプリプロセッサで解決する文化が根付きました。プリプロセッサがいらなくなるぐらい個々の標準が洗練されればプリプロセッサも不要になりますが、そのような未来は、今の動きをみるに、あと15年は来ないように思えます。 とはいえ、ただひとつ言えるの
jspm で快適 javascript 生活（クライアントサイド JS の依存管理決定版） - Qiita
追記 config.js は常に自動生成されるものだと思っていましたが、その認識は誤りだったようです。 そのため、jspm_packages 下ではなく、public ディレクトリに設置するようにしました。 はじめに ぼくは Web の技術が大好き。 はじめに HTML 書いてブラウザで見たら表示されて感動したのを今でも覚えてる。 そんな調子でプログラミングの仕事について、ずっとそこらへんを書いてるけど、 最近の開発、めんどくせーこと多くないですか。 AltJS だー、React + JSX だー。ミニファイだー。依存の解決だー！ もちろん、必要なことだし、イケてるのもわかるけど、開発中に毎回 watch すんのもめんどいし...。と思っていた。 救世主 jspm 会社の人がなにげなく紹介していた jspm。 ビルドツールとかの「開発全体がキレイで楽になります！」っていうのが好きなので、試
Architecting large Single Page Applications with Knockout.js
Last week in Oslo I was lucky enough to attend the fantastic NDC 2014 conference, at which I gave the following talk about using brand-new not-yet-released Knockout.js features, along with Yeoman, Gulp, and Karma to build large single-page web apps in a very modern style (while still retaining backward compatibility all the way to IE 6!). Published Jun 11, 2014 This should be of interest to anyone
タスクランナーgulp.js最速入門 - id:anatooのブログ
相変わらず仕事ではデザインやりつつJavaScript書いている。 タスクランナーとしてGrunt.jsを使っていたけれども、使ううちに段々不満がでてきた。遅かったり、記述が冗長になりがちでつらかったので最近になってgulpに乗り換えた。 gulpは良い。タスクは自動的に並列に実行され、かつストリームで処理されるので速いし、タスクの記述もストリームベースの書き方のおかげでGrunt.jsに比べるとだいぶ短くなる。 ただ、そこらにあるgulpをちょっと試しただけの日本語の記事やドキュメントをみてても実際のプロジェクトで使えるレベルまでの知識を得られず学習に一日かかった。 この記事では、gulpをまともに使えるようになるまでに必要な知識を書く。 導入とHelloWorld まずは導入。npmからgulpをインストールする。 $ npm install gulp -g $ gulp -v [gu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
