Redux(react-redux)における適切な配列要素の更新
2021年8月23日…
大注目のフルスタックフレームワーク「Meteor」を試してみた (2)
2016年2月14日
前回は、Meteorの紹介に終わった。今回は公式チュートリアルを実際にやってみる。
Todoアプリの公式チュートリアルをやってみる
前回記事にて、Todoアプリをたかだか1コマンドで生成し、実行したあとでとてもアレなのだが、フレームワークを理解するために今度は自分でやってみようと思う。最近では、Angular JSが必要な開発に直面していることもあり、チュートリアルはAngular版Todoのものをやってみたいな…と思ったのだが、よくよく見てみるとほとんど普通のAngularっぽい感じだったので、ここは思い切ってMeteorの標準(?)のBlazeの構文でやってみようと思う。
2017年4月14日更新
Blazeの注意点については下記の記事を参照。Meteor 1.4より、BlazeはMeteor公式という立ち位置からは外れている。Blazeは簡素フレームワークのため、現状でもチュートリアルには向いている。
Meteorアプリケーション(Blaze)の運用をしてみてハマったこと – MMiyauchi Blog
http://mmiyauchi.com/?p=1465
基本的には、Meteor 1.2.1の公式チュートリアルを噛み砕いて日本語でやっていくものと思って欲しい。説明用のコードも公式チュートリアルと全く同じである。
アプリケーションの作成
まずはアプリケーションのひな型を作成する。
$ meteor create simple-todos
基本書いてあるまんまだけど、重要なのは、.meteorという隠しディレクトリにMeteorの全てが詰まっているということと、あくまでこの３つのファイルでサーバサイドとフロントサイドの仕組みを作ることができるということ(正確には.htmlと.jsファイルの２つ)。
simple-todos.js # a JavaScript file loaded on both client and server simple-todos.html # an HTML file that defines view templates simple-todos.css # a CSS file to define your app's styles .meteor # internal Meteor files
あとはアプリケーションを実行するために、該当ディレクトリに移動し、サンプルアプリを立ち上げておく。
$ cd simple-todos $ meteor
ちなみに、meteorコマンドを打ったのちに、このままターミナルを立ち上げっぱなしを推奨である。なぜなら、コードを変更しても勝手にMeteorサーバが自動的に再起動するからである。
テンプレートを作成し、表示する
ひな型アプリを作成したところで、htmlファイルを下記のように変える。
<head>
<title>Todo List</title>
</head>
<body>
<div class="container">
<header>
<h1>Todo List</h1>
</header>
<ul>
{{#each tasks}}
{{> task}}
{{/each}}
</ul>
</div>
</body>
<template name="task">
<li>{{text}}</li>
</template>
次に、.jsファイルも下記のように編集する。
if (Meteor.isClient) {
// This code only runs on the client
Template.body.helpers({
tasks: [
{ text: "This is task 1" },
{ text: "This is task 2" },
{ text: "This is task 3" }
]
});
}
赤くはなっていないだろうが、ブラウザで確認すると、公式にあるようにこんな感じでヴューが生成されていることだろう。
ここでは、正当なHTMLの構造をあまり考えずにいたほうが、分かりやすいかもしれない。simple-todo.jsに書いたテキストを<template>要素内に出力している。nameでtaskとしていて、それを#each tasksで取得して、li内に表示している。Meteorでは<template>要素がMeteorのテンプレートとして解釈される。
次に、CSSを下記のようなCSSで、simple-todos.cssを置き換える。
/* CSS declarations go here */
body {
font-family: sans-serif;
background-color: #315481;
background-image: linear-gradient(to bottom, #315481, #918e82 100%);
background-attachment: fixed;
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
padding: 0;
margin: 0;
font-size: 14px;
}
.container {
max-width: 600px;
margin: 0 auto;
min-height: 100%;
background: white;
}
header {
background: #d2edf4;
background-image: linear-gradient(to bottom, #d0edf5, #e1e5f0 100%);
padding: 20px 15px 15px 15px;
position: relative;
}
#login-buttons {
display: block;
}
h1 {
font-size: 1.5em;
margin: 0;
margin-bottom: 10px;
display: inline-block;
margin-right: 1em;
}
form {
margin-top: 10px;
margin-bottom: -10px;
position: relative;
}
.new-task input {
box-sizing: border-box;
padding: 10px 0;
background: transparent;
border: none;
width: 100%;
padding-right: 80px;
font-size: 1em;
}
.new-task input:focus{
outline: 0;
}
ul {
margin: 0;
padding: 0;
background: white;
}
.delete {
float: right;
font-weight: bold;
background: none;
font-size: 1em;
border: none;
position: relative;
}
li {
position: relative;
list-style: none;
padding: 15px;
border-bottom: #eee solid 1px;
}
li .text {
margin-left: 10px;
}
li.checked {
color: #888;
}
li.checked .text {
text-decoration: line-through;
}
li.private {
background: #eee;
border-color: #ddd;
}
header .hide-completed {
float: right;
}
.toggle-private {
margin-left: 5px;
}
@media (max-width: 600px) {
li {
padding: 12px 15px;
}
.search {
width: 150px;
clear: both;
}
.new-task input {
padding-bottom: 5px;
}
}
MongoDB(minimongo)と接続する
タスク保存に使うデータベースとして、minimongoをインストールする(というか、最初から入ってるものを使うみたいな感じなので立ち上げる?のほうが正しいか。パッケージの追加コマンドは$meteor add package-name)。
$ meteor mongo
minimongoと接続するには、 new Mongo.Collection(“コレクション名”)みたいにする。
Tasks = new Mongo.Collection("tasks");
if (Meteor.isClient) {
// This code only runs on the client
Template.body.helpers({
tasks: function () {
return Tasks.find({});
}
});
}
動作確認は、下記のようにコードを変えておこなう。動作確認なので、3行目は終わったらコメントアウトか削除する。
Tasks = new Mongo.Collection("tasks");
db.tasks.insert({ text: "Hello world!", createdAt: new Date() });
if (Meteor.isClient) {
// This code only runs on the client
Template.body.helpers({
tasks: function () {
return Tasks.find({});
}
});
}
フォームからタスクを追加する
simple-todos.htmlにフォームを作成
<div class="container">
<header>
<h1>Todo List</h1>
<form class="new-task">
<input type="text" name="text" placeholder="Type to add new tasks" />
</form>
</header>
<ul>
フォームから送られてきた文字列を処理するコードがこちら
return Tasks.find({});
}
});
Template.body.events({
"submit .new-task": function (event) {
// Prevent default browser form submit
event.preventDefault();
// Get value from form element
var text = event.target.text.value;
// Insert a task into the collection
Tasks.insert({
text: text,
createdAt: new Date() // current time
});
// Clear form
event.target.text.value = "";
}
});
}
まさにコメントのまんまで特に説明が必要はないとは思うが、一応流れを日本語にしてみると、event.preventDefault()でsubmitイベントをキャンセル、キャンセルしたのち変数textにフォームから送信されたテキストを格納、Task.insertによりminiMongoにデータを格納している。最後にフォームの内容を消して、もとの入力値がない状態に戻して終わりだ。要は、submitがそのままキャンセルされないでいると、画面リロードが発生してしまうので、あえてキャンセルしているということだ。
Todoリストのチェック機能と削除の実装
テンプレートエンジンを利用して、チェックボックスをチェックしているときの表示の変更と、削除ボタンを押したときのタスクの削除機能をCSSのclassで設定。jQueryのようにCSSのclassの有無でイベントをハンドリングしている。
</body>
<template name="task">
<li class="{{#if checked}}checked{{/if}}">
<button class="delete">×</button>
<input type="checkbox" checked="{{checked}}" class="toggle-checked" />
<span class="text">{{text}}</span>
</li>
</template>
今度は、テンプレート側で設定したイベントの処理内容をsimple-todo.jsに書く。CSSの特定クラスの付与の有無により、miniMongoのコレクション「task」に保存されている該当するタスクについて処理を行っている。
event.target.text.value = "";
}
});
Template.task.events({
"click .toggle-checked": function () {
// Set the checked property to the opposite of its current value
Tasks.update(this._id, {
$set: {checked: ! this.checked}
});
},
"click .delete": function () {
Tasks.remove(this._id);
}
});
}
アプリケーションをmeteor.comにデプロイしてインターネット上に公開する
ターミナルで、meteor deployコマンドを実行する。下記my_app_nameの部分はURLで認識できる文字列で適宜変更して実行する。たしか、meteor.comのユーザ登録が最初は必要だと思ったが、それだけで無料でアプリケーションをホスティングできる。
$ meteor deploy my_app_name.meteor.com
(※meteor.comへの無料デプロイは、2016年3月25日で終了した。今後はGalaxyへ有償でのデプロイに対応)
チュートリアルの半分(Webアプリケーションの作成・デプロイまで終了)
これでMeteor公式チュートリアルの、Todoアプリ作成・デプロイのWebアプリケーション編は終了。この先、公式チュートリアルではiOSアプリの作成と色々進んでいくが、とりあえず今回はここまで。
Meteorについて、総評
とりあえず、主にWebアプリケーションに限った話について、良い点、悪い点をさっとまとめてみる。
Pros
- Meteorの開発環境の構築が1コマンドで楽
- 標準でリアクティブプログラミングの概念
- フルスタックのフレームワークだが、JavaScriptがある程度分かっていれば理解はしやすい
- 生産性が高そう
Cons
Meteor本来の挙動を実行するためのデータベースが、現状だとminimongo固定(2016年7月19日訂正 本記事の最下部にリレーショナルDBでリアクティブ動作をするものを追記。しかしながら、Meteor本来の推奨構成はMongoDBとminimongoである)- リアクティブ動作のコアがそもそもminimongoなので、RDBのサポートについては今後のMeteor開発チームのSQLサポートの動向によって変わってくる(いわゆる、RDBを使ったしっかりしたアプリケーションには現状向かない)
- プロダクションで、Meteorアプリケーションを分散させるとかどうするのかが疑問
- 製品レベルでの成功例が少ない。運用ノウハウの情報が少ない
こんな感じである。総評的には、プロダクションレベルには当てられないが、それでも作る楽しさ、新しい次世代のWebアプリケーションフレームを学ぶ、という観点だとすごく良いフレームワークだと思う。
フルスタックのWebアプリケーションフレームワークのRailsだと環境構築で、四苦八苦する人も多いと思うが、Meteorはほとんど間違えようのないレベルにまで昇華されている(LinuxやMacは1コマンド)。リアクティブプログラミングで、フルスタックという位置付けでメジャーなものだとMeteorが筆頭だと思うし、これも良い。また、フルスタックではあるものの、JavaScriptが分かればそんなに理解に苦労はしなかった。Webアプリケーションを作る分には生産性は高そう、高そうというのはチュートリアルレベルのコードの段階なのであくまで予想だ。また、そもそも論として、Meteorは単にWebアプリケーションの分野にとどまらないことを考えると、かなり高次元なフレームワークと思える。
一方で、Meteorの欠点に目を当てると、製品レベルでの運用のノウハウ欠如に集約されている。例えば、Meteorの推奨された構成を実現するために、クライアントサイドではminimonogoというデータベースを使用している。これはMeteorの構造を実現する上でキモなわけであるが、このデータベース自体の運用ノウハウが足りな過ぎることが問題と思える。そもそも、minimongoはもともとMeteorのために作られており、(2016年7月19日訂正 Meteor 公式で” This is achieved thanks to the Minimongo library”とコメントがあり、調べてみたところGithubのmWater/minimongoのものを使っている)、このMetorの推奨構成で製品レベルの成功実例みたいなものが出てこないとその実績が評価しにくいものとなっている。一方で、大きくスケールはしていない事例ではあるが、少し古いQuoraの記事によれば、海外のスタートアップではMeteorが採用されていそうなことが分かる。念のために補足すると、現状では、他データベースだと、Meteor向けMySQLパッケージなどもAtmosphereで配布されている。
またデータベースの諸々の事情に詳しい方で、中にはMongo DBそのもののパフォーマンス自体にも疑問を持っている方もおられるだろう。個人的には、基幹となるデータベースシステムには、RDBを選択したく、PostgresSQLまたはMaria DBを選びたいところだ。しかしながら、Meteorのリアクティブ動作のコアはクライアントのminimongoなので、RDBMSが出てくると少し話が違ってくる。ちなみに、Meteorの公式ブログでは、v1.2の時点の今後ロードマップとして、SQLの対応を宣言している(2015年7月の段階)。なので、MeteorでのRDBの対応状況については、完全にMeteorチームの手腕にかかっているような節があり、Meteorはvs Ruby on Railsというのは少し違っていて、RailsはRailsで、現状ではRDBを使用したサーバサイドアプリケーションを作るための、フルスタックフレームワークの最高峰であることには間違いないだろう。
あとは、製品レベルだとどうしてもロードバランシングについてが気になる。アプリケーションサーバ、データベースサーバに分けて分散処理を、というのが必要不可欠だと思うが、これのノウハウもちょっと不明だ(※あくまでmeteorコマンドでチュートリアルのTodoアプリを立ち上げた感覚値)。これは探せば出てくるのかもしれないが、なんとなくノウハウや実績が少なそう。ちょっと探した感じMeteorHacksというサイトがあり、ここを当たればいくつかの負荷分散の方法はありそうなことは分かるのだが、なんか特殊そうだなーという印象を持った(どうやら、Nginxなどでリバースプロキシして、クラスタリングに対応するmeteorhacks/clusterを使ってMeteorを動かすといけるようである)。ちなみに、2016年9月7日時点の「meteor load balancing」というキーワードでのGoogleの検索結果では、やはりmeteorhacks/clusterについての記事が多くヒットするようだ。なので、もしかしたら感覚値通りに、Meteorはロードバランシングのやり方も少し特殊で、方法が限られてくるのかもしれない。
しかしながら、この記事の一つ前の記事(1)でも紹介しているとおり、Meteorはスタートアップの登竜門Y Combinatorの卒業生で、短期間でGithubのスター数でRailsを抜き去る勢いを持っている側面があり、運用の実績値というのは短期間で出しにくいという事実を加味すると、Meteorは今後やはり見逃せない存在である。
2016年7月19日追記
リレーショナルDBでMeteorにてリアクティブ動作と謳っているパッケージを書いておく。リレーショナルDBでもリアクティブ動作はするようだ。
numtel/meteor-mysql: Reactive MySQL for Meteor
https://github.com/numtel/meteor-mysql
numtel/meteor-pg: Reactive PostgreSQL for Meteor
https://github.com/numtel/meteor-pg
こちらもどうぞ
フロント＞サーバサイドも多少＞5年後以降には将来はアプリ制作も考えたいと思っている者です。
絶対的な答えはないので、沢山の方の意見が聞きたく質問しています。
HTML5＞CSS3>jQueryとやってきたのですが、その後どう学んでいくか迷っています。
その後どうするかがわかりません。
候補は下記ですが、
・リアクト
・メテオ
・タイプスクリプト
リアクトはサーバサイドは出来ないようなので、いきなりメテオが出来れば一番合理的なのかなと思っています。
そんな簡単な物ではないでしょうか？
それでは、今後も勉強になる記事を楽しみにしています。
頑張ってください。
＞JS好きさん
こんにちは、コメントありがとうございます。
さて、今後どの技術を習得すれば…ということですが、JavaScript界隈の技術は技術の流行り・廃りが激しいので難しいですよね。
まず、挙げられたReact,Meteor,TypeScriptの3つの技術ですが、どれも技術的な傾向が異なるものですので、ここではJS好きさんの目指す最終的なゴールについて役にたちそうな内容の情報を提供にフォーカスしようと思います。
コメントにある内容ですと、JS好きさんはこれまでフロントエンドを起点に学習してこられ、最終的なゴールが「総合的なアプリケーション開発者」と認識しています。最終的なゴールを達成するための技術選定について、ヒントになりそうなことをコメントしてみたいと思います。
いきなりですが、少しだけ脱線します。
ご存知かもしれないですが、今、JavaScriptフルスタック技術者(フロントエンドだけでなくサーバサイドもJavaScriptを使える)というポジションが特に海外を始めとして、業界ではホットです。
シリコンバレーエリアでも、一昔前はフルスタックといえばRuby on Railsが主流でしたが、近年ではこれがMEANスタックに置き換わっているようです(Railsは未だに多いとは思います)。
僕個人の知るところでは、スタートアップが人材を募集している、Angel List(https://angel.co)というサイトがありますが、先月あたり英国のあるスタートアップから応募しないかとメッセージがきましたが、そこも技術構成がMEANスタックでした(MongoDBではなく、MySQL+Redisでした)。
MEANスタックについての参考記事：
MEANスタックで始めるWebアプリ開発入門（1）：LAMPに代わる構成として注目のMEANスタックの基礎知識とインストール、ひな型作成 (1/3) – ＠IT
http://www.atmarkit.co.jp/ait/articles/1412/01/news041.html
脱線しましたが、JavaScript経験のあるフロントエンド技術者が「総合的な開発者」を目指すにあたり、前提として、今は「サーバサイドもJavaScriptを使った技術で固めていく」で正しいです。
それでいうと、今後くるであろうMeteorに身をまかせて、Railsエンジニアならぬ、Meteorエンジニアを今から先駆的に目指すのもよいと思います。
おっしゃるとおり、Reactはサーバサイドで動くものではないので、フルスタックフレームワークであるMeteorを学習すればフロントエンドもバックエンドも習得できると思います。Meteorの学習のコツをつかめばもちろん学習の効率も良いと思います。
ただ、Meteorの学習について覚悟をしないといけないのが、日本語の情報がそれほど多くはないので、ひたすら英語を読ないといけないことです。
あとは学習する際の懸念点として、Meteorはフルスタックフレームワークなので、作りがちょっと特殊です。
僕は日頃Expressを使ってアプリケーションを作っていまして、Meteorは記事にあるチュートリアル程度しかやってないですが、Meteorのノウハウが完全にこれまでのWeb開発の知見として汎用的に役に立つか、というと疑問です。
初心者がサーバサイドのフルスタックフレームワークを学習するにあたり、最初にRailsを学ぶのはおすすめできない、みたいな意見もありますが、これは一体何が言いたいかというと、フルスタックフレームワークはRails流なら「あくまでRailsのルールで」、Meteor流なら「あくまでMeteorのルール」の独特なやり方でやっていることが多いからです。
フルスタックフレームワークは、独自のルールにのっとり、「良い感じ」に我々が知らないところでなにか便利なように処理してくれている場合が多いです。
独自ルールがあるからこそ、強力なパフォーマンスを発揮するフルスタックフレームワークですが、Meteorについても例外ではなく、この点が「諸刃」だと思っています。
あとは、リスクとしては、Meteorが製品レベルで今後流行することがなかったら…という悲惨なパターンです。Meteorの開発速度をみれば、さすがにないとは思いますが、100%ないとは言い切れません。
フルスタックフレームワークがそもそも独自なんだ、と理解して学習する分なら良いと思いますが、フルスタックフレームワークでするWeb開発が標準と思ってしまう懸念がある、もしくは今後Meteorが普及するか分からないという点にリスクを感じたすれば、Meteorを学ぶべきではないと思います。
僕が現状で個人的におすすめするのは、既に業界的に認知もあり、製品で使われている実績のあるMEANスタックの技術セットです。
これは、基本的にはAngular JSとNode.jsを中心に勉強することになる技術セットです。
サーバサイドのフレームークのExpressがサーバサイド未経験者にも理解しやすいのと、学習する上でインターネット上に知見が多いです。何かを探す際に、日本語で該当しなければ、英語で調べるとほとんど解決策が見つかります。
ExpressフレームワークはMeteorとは異なり、フルスタックではないので、開発の知見は他の異なる技術の開発でも応用しやすいです。
また、この技術セットはアプリケーション開発上のリスクヘッジにもなります。
例えばフロントエンドのAngular JSをEmber.jsに置き換えても良いですし、Express(Node.js)を数年度Go言語でリプレースしたり…。
あくまでMEANスタックは流行りの構成なだけですので、分解して置換することもできます。
MEANスタックのトレンドは、スタートアップを中心に現在も継続中なので、これを学習して損になったりすることはほぼないと思いますよ。
長文になりましたが、何かしら参考になればと思います。
こんにちは、お忙しい中、ご丁寧なご回答大変ありがとうございます。
>>>
それでいうと、今後くるであろうMeteorに身をまかせて、Railsエンジニアならぬ、Meteorエンジニアを今から先駆的に目指すのもよいと思います。
おっしゃるとおり、Reactはサーバサイドで動くものではないので、フルスタックフレームワークであるMeteorを学習すればフロントエンドもバックエンドも習得できると思います。Meteorの学習のコツをつかめばもちろん学習の効率も良いと思います。
ただ、Meteorの学習について覚悟をしないといけないのが、日本語の情報がそれほど多くはないので、ひたすら英語を読ないといけないことです。
下記のようなサイトで基本は解説されていますが、仰る通り本は全くありませんね。
http://gihyo.jp/dev/serial/01/meteor
つまり、すぐにJSの基礎を学んだあとにメテオという形で進むと、お金をかけて書籍を買っても日本語で学ぶことは無理ということですね。
私が行うサーバサイドのプログラミングといえば、小規模サイト制作が中心なので、当分の間せいぜい、問い合わせフォーム、簡易なショッピングカート程度だと思いますが、
それくらいであれば、少ない日本語の情報でも可能でしょうか？
ただし、掲示板やQandAサイト、簡単な予約システム程度を作るなどのレベルなると、英語の情報を理解できなければ不可能な状態が、3年以上は少なくても続くイメージなのですね。
JavaScript入門① はじめてのJavaScriptの1～4講座（https://schoo.jp/class/1729）や
よくわかるJavaScriptの教科書 単行本（ソフトカバー） たにぐち まこと氏
を学んで、その後、JSその物をさらに深く行う事、メタ言語であるtypescript、ライブラリのjQuery(簡単な事は出来ますが)を飛ばして、
meteroにいきなり移行出来れば、無駄ではないですが、JSその物のメソッドなどを覚えても、meteorのメソッドを覚えれば、それらは必要なくなるのでしょうから、
すぐにmeteorに移行することが一番学習コストが低く効率が良いと思っていました。
もしmeteorで、簡易なパララックスやスライドショー、カルーセル、問い合わせフォーム、簡易なショッピングカートなど位のレベルであれば、簡単にmeteorで作る事が出来るのであれば、
JSその物をさらに深く行う事、メタ言語であるtypescriptなどを飛ばした方が、一見一番効率的ですよね。
フロント側はCSS3で出来ない事を、meteorで実装出来れば良いなと思っています。
例えば、簡易なパララックスやスライドショー、カルーセルなど最近よく見る小規模サイトでも実装されているインタラクティブな部分位が出来れば十分です。
ガッツリと動く海外一流サイトのようなパララックスまでは、数年は望んでいません。
しかし、お話を聞いておりますと、小規模サイトでの問い合わせフォームやスライドショーレベルで十分だとしても、それでも上記位の学習でmeteorで実装することは、
難しいと考えた方がよろしいでしょうか？
meteorに手を出すには、上記位のレベルを達成するにしても、オライリーのサイ本を読み終えるレベルか、Node.js入門 Nodeとはの1から4を（https://schoo.jp/class/2452）
大体理解する位が最低ラインでしょうか？
それとも、掲示板やQandAサイト、簡単な予約システムレベルだと、とても無理ではあるが上記位なら、十分に可能と考えても良いでしょうか？
もし可能であればJS基礎後、上記位をmeteorで行いそれ以上は、日本語の情報が出るまで数年待ち、その後本などが出れば、スマホアプリ制作や、もっと高度なWEBアプリ制作の学習を再開しようかと思っています。
＞＞＞
独自ルールがあるからこそ、強力なパフォーマンスを発揮するフルスタックフレームワークですが、Meteorについても例外ではなく、この点が「諸刃」だと思っています。
あとは、リスクとしては、Meteorが製品レベルで今後流行することがなかったら…という悲惨なパターンです。Meteorの開発速度をみれば、さすがにないとは思いますが、100%ないとは言い切れません。
仰っておられるように、Meteorエンジニアは特殊なようなので、会社やチーム制で動く場合、他の方が合わせてくれる事は数年はあり得ないのでしょうから、
自分一人で行わない限りは、必然的に、サーバサイドはエクスプレス、クライアントサイドは、jQuery、typescriptとなるのでしょうね。
そしてまずあり得ないでしょうが、流行らなかった場合(一人でWEBサイト制作を受ける分にはクライアントさんは何も言わないので問題ないですが)
や将来いつかmeteorを使わなくなる日が来た時に、他の物に移らないといけなくなるという覚悟は必要なのでしょうね。
特殊なので、移行する際に、経験があまり役に立たず大変な思いをすると考えておくべきでしょうか。
そこまで考えると実は効率的では無いかもしれないという事ですね。うーん、難しいですね…。
mmiyauchiさんがお勧めしてくださっているのは、meteroでもなくreactでもなく、typescriptでJSその物を極めていくでもなく、JSそのものの基礎を学んだ後は、
フロントはアンギュラ、サーバサイドは、Nodejsを学んだあとにExpressというルートという事ですね。
アンギュラ、Expressならmeteor、reactのようなクセが無いので、学習の難易度、もその他の物に移行するのも容易という事ですね。
Aurelia.JSという物も出てきているようですね。本当にフロントは異常なので、JSそのものの基礎を学んだ後いったい何をやったら良いか、皆さんも頭が混乱していると思います。
長文失礼いたしました。
>>JS好きさん
こんばんは。
まずMeteorでの実装についてです。
Metorでやりたいことをいくつか挙げられていますが、Meteorでのカルーセルやスライドショーの実装はそれほど難しくはないと思います。きっと探せばここにあると思いますよ。Meteorのパッケージが公開されている、公式サイトです。
https://atmospherejs.com/
小規模サイトでショッピングカートを実装するような案件にて、Meteorで実装する難易度についてですが、このあたりは仕様によるのでなかなかコメントがしにくいです。
ただ、記事にも書きましたが、Meteorのデータベースは、基本はMongoDBなので、MySQLなどのRDBを使いたい場合はMeteorだと少し情報を調べる苦労があるかもしれません。これはあくまでMeteorのチュートリアルをやった程度での感覚値での話ですが、ログイン機能だったり、掲示板やQ&Aサイトの実現はそれほど難しくないんじゃないかと思います。
あとは、なぜMeteorを採用するのか？というのが大切で、基本的に技術自体がいかに素晴らしくても、それで目の前の問題を解決するとは限りません。
今回おっしゃられている、小中規模サイトのフロントエンド部、インタラクションを強化をしたいという目的については、Meteorは適任でない気がしています。
Meteorの環境はサーバにインストールするので、バックエンドも影響を受けます。
仮にデータベースを使わないとしても、Meteorのロジックを稼働させるためには環境をインストールし、meteorコマンドでアプリケーションを起動させる必要があります。
Meteorは、本来的にはフロントエンドをリッチにするのが目的のフレームワークではないです。
Meteorの目指すところはフロントエンドとバックエンドをあまり気にすることがない、リアクティブプログラミングでの実装であり、またJavaScriptのコード1つで、多種多様なプラットフォーム(具体的にはWebとモバイルアプリ)に対応することです。ですので、Meteorを扱う上で本当にMeteorのような大きいフレームワークが必要か？ということを考える必要があります。
Meteorには前述のような結構モリモリの目的があるがために、Meteorがフルスタックフレームワークということです。このMeteor目指す目的と、自分の目的がある程度マッチしないと、選ぶ必要はないんじゃないかと思います。
次に、Meteorの学習についてですが、JavaScriptにある程度慣れている人で、サーバサイドも多少分かる人なら理解しやすいと思います。
書かれていたオンライン学習講座の内容をある程度理解して、Meteorを学習するなら全然余裕だと思いますよ。
Meteorのチュートリアルをやった感じだと、同じフルスタックフレームワークでも、Railsほどルールでガチガチで複雑ではないように感じました(Railsもチュートリアル程度です)。Meteorは、内部的な実装はNode.jsなんでしょうけど、書いていて別段Node.jsっぽさは感じませんでした。ExpressのほうがMeteorに比べてローレベルの実装ですので、Node.jsをやっている感じがします。ですので、Node.jsのオンライン講座のリンクもご紹介されていましたが、Node.jsについて理解、というよりはJavaScriptの基本事項の理解が重要だと思います。
それから、サイ本ですが、僕も先日買いましたが、まだ読まずに机の上に置きっぱなしです。
別にサイ本を読まなくても、Meteorはいけるんじゃないかと思います。
MeteorはJavaScriptの理解も必要ですが、既に言及した通り、やはり英語の読解力が要求されます。
ちなみに、僕がJavaScriptの言語自体についての内容で熟読した本はこちらです。
JavaScript本格入門 ～モダンスタイルによる基礎からAjax・ｊQueryまで
JS好きさんのおっしゃるところで、JavaScriptフレームワークを使いつつ、インタラクティブ表現をよりリッチにしたい、という要件でしたら、Angular JSがおすすめですよ。
なぜAngular JSかというと、これにはカルーセルだったり、スライドショーだったり、そのあたりがAngular JSのモジュールとして数多く公開されているからです。あとは、jQuery経験者ないしやっている人のうち、「jQueryはプラグイン豊富だから」という知見の活用に特にメリットを感じている人は、Angular JSに移行しやすいと思います。現状のフロントエンドJavaScriptフレームワークの中では、Angular JSが最も周辺環境が充実しています。
Angularのモジュールを読み込めば、リッチなUIを実装できることでしょう。あとは、Angular JSはフロントエンドだけに影響力を持つので、バックエンドの環境はもちろんMeteorのように影響は受けないです。
個人事業主でやられているとしたら、データベースの構築だったり、サーバサイドに環境を作らないような小さめな案件も中にはあると思いますし、ちょっとした案件に便利ですよ。別なエントリーで書きましたが、僕も小さめな案件でAngular JSを実際に使ってみましたが、jQueryよりも仕様変更に強い状態で作れるし、何より生産性が高いと感じました。
あとは、Angular JSを習得してから、Meteorを学習するのだと、MeteorはAngular JSに対応しているので、テンプレートエンジン(?)のBlazeの代わりにAngular JSを使うという選択肢にできますよ。あくまで、これは副産物ですが。
最後に、諸々の補足です。
Meteorは今後Railsと置き換わる可能性を持つ、とても良い技術だと思います。
ただ、仕事で何らか活かしたいとすれば、やはりまずはMEANスタックの学習をお勧めします。JS好きさんの質問が、趣味でMeteorをやるのはどうなのか？という質問よりかは、仕事よりの質問と思ったので念のための補足です。僕もMeteorが良いらしいと、知り合いの会社の人が言ってたのをたまたま聞いて、その日のうちに遊びでやってみて、ついでに書いてみたエントリーです。ですので、Meteorは今後もフォローするものの、あくまで自分が手がける製品は基本的にはMEANスタックに近い技術セットで作っていくスタンスです。
TypeScriptですが、これも良い技術だと思います。でも、これをやることが純粋にJavaScriptを極めることとは違う気がします。
TypeScriptはあくまでJavaScriptのメタ言語です。ES6でJavaScriptに実装されるクラスと、TypeScriptでのクラスは概念から違います。僕も少しの期間TypeScriptを使ったことがありますが、LLにはないコンパイルで、動作がある程度保障されることにメリットを感じたのと、強力なチェックによりつまらないミスを減らすことができたので、技術自体は非常に良いものだと思います。
純粋な意味で、JavaScriptを極めるというと、Babel(https://babeljs.io/)というものがあります。これは、ブラウザ未実装の最新のJavaScriptで書けるトランスコンパイラですので、そちらをお勧めしますよ。
フロントエンドのフレームワークや、その他技術について、現在の情勢を調べるのにGoogleトレンドが多少の参考になります。
このへんなんかどうでしょう。
Google トレンド – ウェブ検索の人気度: AngularJS, aurelia, react – すべての国, 2004年 – 現在
https://www.google.co.jp/trends/explore#q=%2Fm%2F0j45p7w%2C%20Aurelia%2C%20React&cmpt=q&tz=Etc%2FGMT-9
上記のコメントの一部に訂正箇所が見つかりましたので、訂正です。
>> TypeScriptはあくまでJavaScriptのメタ言語です。ES6でJavaScriptに実装されるクラスと、TypeScriptでのクラスは概念から違います。
これは間違いで、TypeScriptにおいても、ES6のクラスと同様のものが実装されていました。大変失礼しました。
Classes · TypeScript
https://www.typescriptlang.org/docs/handbook/classes.html
お忙しい中、ご丁寧なご回答大変ありがとうございます。
＞＞＞
ただ、記事にも書きましたが、Meteorのデータベースは、基本はMongoDBなので、MySQLなどのRDBを使いたい場合はMeteorだと少し情報を調べる苦労があるかもしれません。これはあくまでMeteorのチュートリアルをやった程度での感覚値での話ですが、ログイン機能だったり、
掲示板やQ&Aサイトの実現はそれほど難しくないんじゃないかと思います。
MeteroはmongoDBしか使えないと思っていたのですが、mysqlも使えない訳ではないのですね。
ただ日本語のサイトや本で学ぶ事は数年は無理という事ですね。
私はまだDBは学習した事が無いのですが、せっかくこれからやるなら、将来性のあるMongoDBの方が良いのかなと思っていたのですが、
フリーランスで行う程度でしたら、mysqlとアンギュラないしは、JSその物などの方が良いのかもしれませんね。
＞＞＞
今回おっしゃられている、小中規模サイトのフロントエンド部、インタラクションを強化をしたいという目的については、Meteorは適任でない気がしています。
Meteorの環境はサーバにインストールするので、バックエンドも影響を受けます。
仮にデータベースを使わないとしても、Meteorのロジックを稼働させるためには環境をインストールし、meteorコマンドでアプリケーションを起動させる必要があります。
Meteorは、本来的にはフロントエンドをリッチにするのが目的のフレームワークではないです。
Meteorの目指すところはフロントエンドとバックエンドをあまり気にすることがない、リアクティブプログラミングでの実装であり、またJavaScriptのコード1つで、多種多様なプラットフォーム(具体的にはWebとモバイルアプリ)に対応することです。ですので、Meteorを扱う上で本当にMeteorのような大きいフレームワークが必要か？ということを考える必要があります。
Meteorには前述のような結構モリモリの目的があるがために、Meteorがフルスタックフレームワークということです。このMeteor目指す目的と、自分の目的がある程度マッチしないと、選ぶ必要はないんじゃないかと思います。
＞＞＞
Meteorは今後Railsと置き換わる可能性を持つ、とても良い技術だと思います。
ただ、仕事で何らか活かしたいとすれば、やはりまずはMEANスタックの学習をお勧めします。JS好きさんの質問が、趣味でMeteorをやるのはどうなのか？という質問よりかは、仕事よりの質問と思ったので念のための補足です。僕もMeteorが良いらしいと、知り合いの会社の人が言ってたのをたまたま聞いて、その日のうちに遊びでやってみて、ついでに書いてみたエントリーです。
ですので、Meteorは今後もフォローするものの、あくまで自分が手がける製品は基本的にはMEANスタックに近い技術セットで作っていくスタンスです。
meteorはまだ、実務で使えるレベルでは無いのですね。
問い合わせフォームだけという小規模コーポレートサイト案件位であれば、DBの必要性もないので、
不要なのにmeteorの為だけにmongodbをインストールすると言う事は、重くなるのでコンバージョン率が下がるので良くないという事ですね。
meteorは基本的に相当複雑な、不動産会社の不動産検索などのサーバサイドの事がない場合を除けば、EXPRESSより重くなるという事なのですね。
＞＞＞
TypeScriptですが、これも良い技術だと思います。でも、これをやることが純粋にJavaScriptを極めることとは違う気がします。
TypeScriptはあくまでJavaScriptのメタ言語です。ES6でJavaScriptに実装されるクラスと、TypeScriptでのクラスは概念から違います。
僕も少しの期間TypeScriptを使ったことがありますが、LLにはないコンパイルで、動作がある程度保障されることにメリットを感じたのと、
強力なチェックによりつまらないミスを減らすことができたので、技術自体は非常に良いものだと思います。
純粋な意味で、JavaScriptを極めるというと、Babel(https://babeljs.io/)というものがあります。
これは、ブラウザ未実装の最新のJavaScriptで書けるトランスコンパイラですので、そちらをお勧めしますよ。
知識不足で大変恐縮ですが、実はJS自体が大好きなわけでは無く、今後WEBサイト制作で、フロントとサーバサイドのプログラミングをしっかり行えれば、
特にこだわりはありません。
こだわっているのは、せっかく初めてインタラクティブな部分を作る言語を学ぶなら、将来性があり、色々な事が出来る物を学べれば効率的で有りがたいと思っています。
ただ、TypeScriptをやった場合、meteorやnode、reactなどと全く違い別言語を学ぶようなイメージになってしまうなら、仰る通り、
こちらを選ぶのは辞めた方が良いですね。
meteorやnode、reactなどとそっくりであろう、アンギュラ、jQuery、JSその物、ないしは今最も勢いのあるreactをいきなり学んだ方がいいと思います。
・
私も調べてみました。アンギュラとリアクトがダントツですね。
https://www.google.co.jp/trends/explore#q=react%E3%80%80js%2C%20Angular%20%E3%80%80js%2C%20meteor%E3%80%80js%2C%20typescript%E3%80%80js%2C%20babel%E3%80%80js&date=1%2F2016%2012m&cmpt=q&tz=Etc%2FGMT-9
・お話をうかがって、meteorはまだ実務では数年は早すぎて、しかも中小規模サイト位では、将来もあまり使われないのかなと思いました。
ｊQueryは、古すぎて、アンギュラが一番良い時期で、reactはまだ若干速いという感じでしょうか？
将来性ならreact、今実用性ならアンギュラ、難易度はjQueryという感じですかね。
aureliaもみてみた所フルスタックだったのですね。
ただmeteorと同じように、フルスタック故の余計な部分がきっとあるのでしょうね。
aureliaをいきなりやってすべて済むようになる前にmeteorで済むようになるのでしょうね。
クライアントサイドだけでいいならバベルがお勧めなのですね。
>>JS好きさん
こんにちは。
MeteorはMySQLも使えます。
ただ、僕もよく調べていませんので、やり方は理解まではいってないです。
MySQLのモジュールはAtmosphereで確認しましたし、Githubにドキュメントとちょっとした例がありました。
データベース操作のご経験が少ないということでしたら、MySQLなどRDBからのが学習はしやすいです。
NoSQLもデータ設計でコツがいるみたいですが、設計のやり方の日本語での情報が少ない上、MySQLではないところにMongoDBや他のNoSQLのデータベースを当てるなど、局所的な使われ方をよくされると認識しています。
メインのDBにMongo DB採用はあまり聞かないし、まずはRDBからではないでしょうか。
MySQLのデータベースエンジンは、MongoDBのそれよりも優れていると記事で見かけたことがあるので、新しいデータベースが必ずしもハイパフォーマンスとは限らなそうです。
Meteorは製品レベルで使えない、というわけではなく「使うのに勇気がいる」技術ですね。
やはり技術者皆、安定した技術を採用したいですから。採用事例が聞かないのが怖いだけですね。
現在バージョンも1.3ですし、使えるタイミングがあったら使って良いと思います。
Meteorのパフォーマンスについては正直なんともです。
パフォーマンスを気にするのであれば、現段階ではExpressのほうがチューニングはしやすいでしょう。
Reactは今着手するには早過ぎることはないです。
むしろ、フロントエンド技術に関心のある方は、Angular JSもReactもどちらもやるべきだと思います。
どちらも方向性が全く違う技術ですので、アプローチの差異を理解してやることは、フロントエンドの理解度の向上になります。
あと、Angular JS 1.xのバージョンの双方向データバインディングという概念が、Angular JS 2.xより廃止され、現行のReactのような単方向のデータバインディングに変更になります。
まだAngular JS 2.xは早いと思いますが、Reactの勉強は、今後主流になってくるであろうデータバインドの手法を勉強する良い機会になると思いますよ。
jQueryは個人的には…古いですね。なるべくなら今後は使用したくないです。
視覚的にリッチなサイトにすればするほど、DOM操作のレンダリングコストとなり、むしろユーザビリティが低下するので。
僕がよく使うサイトであまりにこの現象がひどいのが、Beatportです。
とにかく、DOMのレンダリングコストを気にした経験があり、嫌だなあと思ったらAngular JSに行けば幸せになれると思います。
Reactでもいいですが、Angular JSを勧める理由として、jQueryがだいたいそのまま使える機能があるからです。仮想DOM上の操作で、たいがいのjQueryでやっていた操作を実現できると思いますよ。
こんにちは、お返事ありがとうございます。
>>>
MeteorはMySQLも使えます。
ただ、僕もよく調べていませんので、やり方は理解まではいってないです。
MySQLのモジュールはAtmosphereで確認しましたし、Githubにドキュメントとちょっとした例がありました。
データベース操作のご経験が少ないということでしたら、MySQLなどRDBからのが学習はしやすいです。
mysqlも使える物の、meteorでそれを使うには英語のサイトが読める位でないと不可能という事ですね。
現場では、mongoDBはまだまだメインとしては使われておらず、かつ難易度もmysqlと比べて高いので、
中小規模サイト制作ならなおさら、当分mysqlで十二分という事ですね。
mongoDBの先取りは不要だと言う事が分かりました。
mysqlにしておきます。
＞＞＞
Meteorのパフォーマンスについては正直なんともです。
パフォーマンスを気にするのであれば、現段階ではExpressのほうがチューニングはしやすいでしょう。
meteorが重いとは言えないが、Expressの方がmeteorより軽い事は間違いないという位なのですね。
個人や小規模な会社で受ける程度のWEBサイト制作でも使えないほど重くはないが、ちょっと心配位なのでしょうね。
＞＞＞
Reactは今着手するには早過ぎることはないです。
むしろ、フロントエンド技術に関心のある方は、Angular JSもReactもどちらもやるべきだと思います。
どちらも方向性が全く違う技術ですので、アプローチの差異を理解してやることは、フロントエンドの理解度の向上になります。
あと、Angular JS 1.xのバージョンの双方向データバインディングという概念が、Angular JS 2.xより廃止され、現行のReactのような単方向のデータバインディングに変更になります。
まだAngular JS 2.xは早いと思いますが、Reactの勉強は、今後主流になってくるであろうデータバインドの手法を勉強する良い機会になると思いますよ。
Angular JS 2.xは選ばない方がまだ良いという事ですね。jQueryも多少やってしまったのですが、
せっかくなら古いAngular JS 1.xかReactに早めに乗り換えた方が良いのか難しいですね。
JSその物かjQueryで一年位まって、Angular JS 2.xをいきなりやると言う方法もあり、難しいですね。
Reactの勉強は、今後主流になってくるであろうデータバインドの手法を勉強する良い機会になるので、
Angular JS 1.xよりより良い選択という事でよろしいでしょうか？
typescriptやバベルもあり、正直何を買ったらよいかわからない状態ですが、これらはハイブリットアプリ制作が
出来ないと思うので、将来に含みを持たせたいのであれば、reactが良いのかもしれませんね。
＞＞＞
jQueryは個人的には…古いですね。なるべくなら今後は使用したくないです。
視覚的にリッチなサイトにすればするほど、DOM操作のレンダリングコストとなり、むしろユーザビリティが低下するので。
僕がよく使うサイトであまりにこの現象がひどいのが、Beatportです。
とにかく、DOMのレンダリングコストを気にした経験があり、嫌だなあと思ったらAngular JSに行けば幸せになれると思います。
Reactでもいいですが、Angular JSを勧める理由として、jQueryがだいたいそのまま使える機能があるからです。仮想DOM上の操作で、たいがいのjQueryでやっていた操作を実現できると思いますよ。
まだ当分はコロコロかわり落ち着かない状況でしょうから、
ある程度やってしまったjQuery、JSその物（typescriptや教えて頂いたバベルという方法も有りますが）かで一、二年様子見をして、
ある程度これと決まったらそれをやると言う方法も有るかなと思ったのですが、やはりAngular JS1系が良いという事ですね。
小規模サイトではまだ中心的に使われていますが、jQueryは確かに重いので、もっと上を目指すならjQueryは途中までやったとしても、
変えた方が良いというお考えですね。
ありがとうございました。
・下記のような気になる情報を見つけました。
小規模なコーポレートサイトや病院、レストランなどの商用サイトで、SEOが不要という事は、十年は無いのではないでしょうか？
大規模サイトを中心に作る方であればもしかすると不要なページも有るのかもしれませんが、私のように個人で受けたり、
小規模な会社の下請けで受けるようなWEBクリエイターでSEOが難しいアンギュラは向かないのでしょうか？
また、アンギュラは2系に代わると、根本的に変わってしまうとも聞きました。
アンギュラをやるなら一年位まって2系から始めるのが良いのかもしれないと思いました。
・
http://www.publickey1.jp/blog/15/angularjsangularjsdeverlopers_summit_2015.html
より
FAQ：SEO対策ってどうしたらいいですか？
無理です。JavaScriptなので無理なものは無理です。
Googleなどのクローラーが来たときに静的なHTMLを吐くという仕組みは必要になってきますが、
SEOが必要なページは、僕は基本的におすすめしません。
川田氏 オワコンになるので使わない方がいい機能はありますか？
金井氏 AngularJS 2.0で全てが変わるので……（会場笑）
・こんな情報も有りました。
金井氏 僕はAngularJS万能説じゃないんですね。例えばWebサイトを作るならjQueryの方がいいと思うし。
林氏氏 万能じゃない、というのは同意です。いまReactなどもちょっと触っているので、
それぞれメリット、デメリットを分 かって使うのがいいと思います。でもAngularJSはフレームワークとしては楽しい、プロダクトに使うかどうかは別にして楽しいので、一緒にやってみ たい方はぜひご連絡ください（笑）
小規模なコーポレートサイトや病院、レストランなどの商用サイトを中心に作る私レベルなら、
とりあえずJSその物（typescriptやbabelもあり）やjQueryで数年位やって、その後間違いない物が出て来た時にそれに移行するのが良いのかもしれませんね。
簡単といわれているVue.jsも気になりますが、本当にきりがないのですね。
>>JS好きさん
こんばんは。
>Reactの勉強は、今後主流になってくるであろうデータバインドの手法を勉強する良い機会になるので、Angular JS 1.xよりより良い選択という事でよろしいでしょうか？
こちらですが、ReactとAngular JS1.xについては、二者を簡単に比較することはできません。
Reactは良い技術ですが、Angular JS1.xも同様に良い技術です。両者では目的も違えば、アプローチも違います。
例えば、違いが分かりやすいあたりだと、Angular JSはテンプレートエンジン機能がついてますが、Reactにはなかったはずです。
僕は今はメインでAngular JSを使っていますが、Reactもいずれ勉強をする予定です。どちらも、JavaScriptを語る上では現状では押さえておきたい技術と認識しています。
それから、コメントにあるようなパネルディスカッションなどの国内の記事は僕もいくつか参考にしましたが、本当に参考程度で良いと思います。万能な技術はまず存在しないので、ケースバイケースで使うために、その技術の何が重要かで技術選定するのかが大切だと思います。
僕はAngular JSについては、jQueryのようなViewの見た目の部分の操作性、仮想DOM操作によるViewのレンダリングコスト減、無数のモジュールによる周辺環境のサポートを求めました。どんな技術にもデメリットは少なからずありますから、そこに目を当てたとしても、「デメリットは確かにこれだけある。しかし、少なくともこの技術に求めたメリットには満足している」という状態にしておくのが重要なことだと思います。
あと、これは僕なりの感覚の意見ですが、JavaScriptは環境を作るのが全然大変じゃないので、気になる技術は「まずやってみる」というのが一番楽かもしれません。
Reactについてじゃ現段階では何かに使う予定はないですが、参考書も買ってしまったので、勉強してみて良さそうならどこかのタイミングで使ってみようと思っているところです。JavaScriptエンジニアは、基本どれだけフレームワーク扱えるかみたいなところも十分価値になると思いますから、気になるフレームワークはちょっとやってみるくらいの楽なスタンスのほうが案外得かもしれませんよ。
＞＞＞
。JavaScriptエンジニアは、基本どれだけフレームワーク扱えるかみたいなところも十分価値になると思いますから、気になるフレームワークはちょっとやってみるくらいの楽なスタンスのほうが案外得かもしれませんよ。
ありがとうございます。
angular、react両方ともそれでサイト制作を行っていて絶対の損をしない技術そうですね。
このどちらかとEXPRESSをやっておけば、問題なさそうですね。
typescriptやJSその物を極めていかなくても、フレームワークで必要なWEBアプリが出来ればJSは良さそうですね。
ありがとうございました。
今後も頑張ってください。
>>JS好きさん
こんにちは。
ありがとうございます、今後も頑張ります。
もし、何かしらJS好きさんのお役に立てたのなら良かったです。
ぼちぼちJavaScriptに関する記事は投稿していこうと思っているので、たまに覗いてもらえると嬉しいです。
また何か気になることがあれば、コメントないし、問い合わせページからお気軽にご連絡ください。
それでは。
JSの記事楽しみにしています。
頑張ってください。
JSその物やtypescriptでも、nodeやexpressと組み合わせれば、
問い合わせフォームやショッピングカートのサーバサイトのWEBアプリが作れるというような情報をその後見つけました。
私が知識不足でJSその物やtyescriptではサーバサイドのプログラミングは出来ず、NodejsやEXPRESSは、
JSその物やtyescriptとは違う言語のように大きく違う物と思っていましたが、下記をみるとあまり変わらず、
クライアントサイドがJSその物やtyescriptで出来れば、NodejsやEXPRESSを同じように作れるのかもしれませんね。
http://okamuuu.hatenablog.com/entry/2016/02/02/165404
何度もコメント恐縮です。アンギュラを進めていただきましたが、それもとてもいいと思うのですが、
比べるべきでは無いと言われてしまうのですが素のJSをBabelでトランスパイルするのとRiot.js、reactどれにしようか迷っています。
ｊｓ基礎をやっている人にはどちらの方が簡単に理解出来、Webアプリが作れるでしょうか。
Htmlは解るので、タグを使うRiot.js 、Reactは非常に分かり易いのでしょうかね？
Riot.js、reactはjQueryのように、よく使うメソッドがまとめられていて、
バニラjsだと大量に記載をしないといけないのが、iQueryのようにほんのわずかなメソッドを記載しただけで実現できるメリットはあると考えてよいでしょうか？
jQueryはそれでバニラjsより圧倒的に簡単になっていると思います。
どうもそのようであるという話をいただいているのですが、Riot.js 、reactも同じでしょうか？
バニラjsですと、仮にbabelをつかってフューチャーシンタックスで記載しても、
jQueryやRiot.js 、reactよりも大量のメソッドの記述が相変わらず必要で大変なことに変わりはないのでしょうか？
それともフューチャーシンタックスでは、ライブラリのように、よく使うメソッドがまとめられていて、大量に記載しないといけない問題が解決されているのでしょうか？
人によって答えが違ってくる質問なので、たくさんの方の意見が聞きたく質問しています。
お忙しい中大変恐縮ですが、フリーランスで小規模サイト制作を受ける程度の、WEBクリエイターなら、どのJSを学ぶべきでしょうか？
Riot.js をお勧めされているので、やはり、将来すたれた時に癖がないので、すぐに他に移れる。
jQueryの次に学習が簡単なので一番でしょうか？
>> JS好きさん
どうもご無沙汰してます、mmiyauchiです。
コメントありがとうございます。
一旦、BabelやTypeScriptなど、トランスパイラのことはおいておき、ほとんどフレームワークの話題にしぼりたいと思います(トランスパイラについては最後に少しだけ回答してあります)。
基本的には、Reactについては現在勉強中で、Riot.jsについては存在は認識していたものの、チュートリアルその他ノータッチで調べつつの状態での回答内容ということになりますので、ご理解ください。
まず他でRiot.jsやVanila jsをお勧めされたということですが、今の時代でVanila JSは選択肢としては含める必要はないと思います。Vanila JSについては僕も詳しくはないですが、こちら(http://vanilla-js.com/)のものを指しているとすれば、Vanila JSは数世代前の時代のフレームワークという認識です。2択であれば間違いなくRiot.jsを選ぶべきでしょう。
次に、ReactとRiot.jsの比較ですが、もうRiot.jsの公式サイトの下記を参照されたと思いますが、
RiotをReact・Polymerと比較する · Riot.js
http://riotjs.com/ja/compare/
こちらがとても分かりやすいのでコードを参考にします。後述のコメントについて、上記URLのコードを見つつ読んで頂ければと思います。
どちらもいわゆる「コンポーネント指向」のフレームワークですね。ReactとRiot.jsの記法上の主な違いについてざっくり言うと、これはコンポーネントの表現方法の差異が主だと認識しています。よくReactはJSXという、HTMLやXMLタグに似た記法でコンポーネントを書くことが推奨されます。一方で、Riot.jsはまさにコンポーネントの記法がほとんど純粋なHTMLタグになっていると思います。最初、Riot.jsのコードを見て、あまりにもHTMLコードに似ているので、初めてRiot.jsのサンプルコードを見た際にはHTMLに直接書くようなよくあるMVCスタイルのフレームワークと見間違えました。
Riot.jsが理解しやすいだったり、学習コストが低い、と評価される所以が、おそらくこのコンポーネントの記法が1つ、あとは、ロジックを書く際にはHTMLタグのような記法のコンポーネント中に、まさにMVCフレームワークでいうテンプレートエンジンのようなスタイルでロジックを記述していくためでしょう。実際、MVCのスタイルを知る人間からすると、確かにRiot.jsのシンタックスはかなり分かりやすいです。
Riot.js公式サイトでのReactとの比較では、Riot.jsのほうがReactよりも圧倒的にコード分量が少なく、見通しも良いです。ですが、当然ReactとRiot.jsで目指している方向性が異なるものですので、コードの少なさや記法で全てを決定することはできません。
Riot.jsはvs React的なポジションのフレームワークですので、当面は問題なく使えることと思います。ですが、Githubのスター数や周辺環境の充実度を見ると、なにか複雑なことをやろうとしたときに困るかもしれません。以下は、技術選定の基本であると認識していますが、「小さめなフレームワーク」を謳うものはもちろん、実装されているコード数が少ないですからもちろんできることが限られていることが多いです。Riot.jsはこの小さめなフレームワークに属します。また、マイナーなフレームワークにいくほど、周辺環境(追加モジュールだったり、知見)が充実していない可能性もあります。Riot.jsはややマイナーなフレームワークという認識です。逆にメジャーなフレームワークを選ぶと、周辺環境が充実していることが多いです。
個人的には、学習コスト、周辺環境などのバランスを考えると、Riot.jsに似た、Riot.jsよりもバランスのとれた良さそうなフレームワークとして、Vue.jsをお勧めします(※お勧めしますが、使ったことがないので聞き流してもらっても結構です)。Vue.jsはGithubのスター数は25980で、Riot.jsの1.5倍ほどあります(※2016年9月3日現在)。
また、下記の記事のJavaScriptフレームワークの満足度のグラフでは、
The State Of JavaScript: Front-End Frameworks – Medium
https://medium.com/@sachagreif/the-state-of-javascript-front-end-frameworks-1a2d8a61510#.kzl5lwewr
Vue.jsについて使用者の88%が満足と回答されているようです。開発時期ですが、Vue.jsはRiot.js(Sep 22, 2013)よりも後発で、2014年7月に開発が開始された比較的新しいフレームワークのようです。
これは余談ですが、個人的には、JavaScriptフレームワークで現在最も注目度が高いのがReactです。世界の最新動向でも、ホットなJavaScriptフレームワークといえばReactのようです。それを裏付ける統計がこちらです。
Hacker News Hiring Trends – Most Popular Programming Languages (August 2016)
http://www.ryan-williams.net/hacker-news-hiring-trends/2016/august.html?compare1=React&compare2=AngularJS&compare3=Ember&compare4=
これは、2016年8月のHacker Newsによるシリコンバレーエリアのスタートアップ企業の雇用統計です。グラフはReact, Angular JS, Ember.jsの比較ですが、Reactが圧倒的な伸びを示しているのが分かります。Angular JSもとても便利なフレームワークだとは思いますが、注目度の高さから、今はReactを勉強し、扱えるようになりたいと思っています。
最後に、Babelのようなトランスパイラ利用時の新しいJavaScriptシンタックスについてです。
>>それともフューチャーシンタックスでは、ライブラリのように、よく使うメソッドがまとめられていて、大量に記載しないといけない問題が解決されているのでしょうか？
こちらですが、この認識は違います。
Babelのようなトランスパイラは、あくまで「ECMA Internationalで新しいECMA Script(JavaScript)の仕様が策定される前のシンタックスを先取りする」といったものです。イメージ的には、どのブラウザでも新しいシンタックスで動作する未来の環境を、開発環境で擬似的に先取りをするものです。Babelなどのトランスパイラは、フレームワークやライブラリとは性質が完全に異なり、現状のJavaScriptに理解があり、未来のJavaScript仕様についてより先取りをして理解する場合に使う手段となっています。ですので、無理を手を出す必要はないものです。
お忙しい中何度もご回答いただき大変ありがとうございます。
＞＞＞
まず他でRiot.jsやVanila jsをお勧めされたということですが、今の時代でVanila JSは選択肢としては含める必要はないと思います。Vanila JSについては僕も詳しくはないですが、
こちら(http://vanilla-js.com/)のものを指しているとすれば、Vanila JSは数世代前の時代のフレームワークという認識です。2択であれば間違いなくRiot.jsを選ぶべきでしょう。
わかりにくい表現ですいません。バニラJSとは素のJSという意味で記載しました。
Vanila JSは、プレーンという意味のジョークで、素のJSの事を言っていると聞きました。
それとも本当に昔あったのでしょうか？
素のJSをBabelでトランスパイルするというのは、つまりバニラJSをBabelでトランスパイルするという意味でした。
＞＞＞
最後に、Babelのようなトランスパイラ利用時の新しいJavaScriptシンタックスについてです。
>>それともフューチャーシンタックスでは、ライブラリのように、よく使うメソッドがまとめられていて、大量に記載しないといけない問題が解決されているのでしょうか？
こちらですが、この認識は違います。
Babelのようなトランスパイラは、あくまで「ECMA Internationalで新しいECMA Script(JavaScript)の仕様が策定される前のシンタックスを先取りする」といったものです。イメージ的には、どのブラウザでも新しいシンタックスで動作する未来の環境を、開発環境で擬似的に先取りをするものです。Babelなどのトランスパイラは、フレームワークやライブラリとは性質が完全に異なり、現状のJavaScriptに理解があり、
未来のJavaScript仕様についてより先取りをして理解する場合に使う手段となっています。ですので、無理を手を出す必要はないものです。
ただ上記のお話を見る限り、フューチャーシンタックスで記載しても、jQueryやReactなどのライブラリのように、簡単にちょっとした、まとまった便利メソッドを記載するだけで、
古い素のJSであれば大量に、難しい記述をしないと再現できないものが、再現できるようになるわけではないようですね。
するとフューチャーシンタックスで記載しても、ちょっと複雑なことをやると、この選択肢が、どのライブライより難しくて、大変という認識でよいのですね。
Reactが今一番勢いがあり、jQueryはお先真っ暗だが、本職でないフリーランスのWEBデザイナーなどは、ずっとこれを使い続ければ十分なので、
残り続けるという感じなんでしょうね。
自分で聞いておいて、恐縮ですが、JSの基礎のみとjQueryを少しやったくらいの私は、jQueryで様子を見ておいて、
数年後に決着がついてから、それを始めればよいのですかね。
それとも、せっかく今後もやり続けるなら、VueやRiotにjQueryから移ったほうが、合理的な選択でしょうか？
ライブラリのまとめは下記の認識でよろしいでしょうか？
難易度
jquery＜Vue＝Riot＜React＜＜＜素のJS
将来性 RiotはVueより古いのにこれより流行っていないということは、今後もVue以上になることはないということでしょうか？
jquery＜Riot＜Vue＜React＜？素のJS
記述の癖
素のJS＜Riot＜Vue＜jquery＜React
最後に
JSのフレームワークは過渡期で、コロコロ変わるので、今は手を出さず、素のJSをやっておけば、
今後フレームワークが固まった時に簡単に移れるのと、私のように素のJSがガリガリかけない人が逆にフレームワーク
だけをやってしまうと、フレームワークが変わった時に、移ることが厳しく、技術を使うのではなく使われる人になってしまうという、
話を聞いたことがあります。
もちろんフレームワークのご質問をしているので、これが正しいかもJS初心者の私には判断ができないので、
どう思われるかお教えいただければ幸いです。
>>JS好きさん
こんばんは。
なるほど、JavaScriptを形容するVanila jsというジョークは少なくとも、自分はJS好きさんのコメントで初めて知りました。
おそらくAjaxが流行る前のJavaScript不遇の時代の言葉とか、古い言葉なのかもしれません。または、僕の知識不足かもしれないですが、今の時代のES6のJavaScriptは、クラスや静的型付けなど、構造的には素のJavaScriptとジョークで形容されるような貧相なプログラミング言語ではなくなっている、という認識です(JavaScriptは、Ajaxが流行る時代より前では、ブラウザでふざけたことをやるとてもチープな言語と広く認識されていたようです)。
jQueryについてですが、今後についてはなんとも言えません。僕はJavaScriptを知る上で、jQueryというライブラリは必須だと思っています。例えば、ブラウザのエンジンが急激に進化をして、DOM操作のコストが圧倒的に低くなったら、またそれなりに注目をされると思いますし(現状では、複雑なDOM操作時の変更コストが高いので、ReactのようなDOMをより抽象化したレイヤーで操作して見た目を変更するフレームワークが流行っていると認識しています)。それに、なんといっても、JavaScriptの見た目上の操作の基本を知る上でこれ以上に簡単に操作ができ、安定した、長くメンテナンスもされ続けているライブラリは他にないと思います。個人的には、jQueryはいつの時代も存在する、初心者から中級者に好んで使われるという技術というポジションは今後もゆるがないと思っています。ただ、現状だとあまりにDOMの描画コストが高いので、中級者、上級者はReact、Angular JSなどのフレームワークに移り、低コストなDOMのレンダリングに慣れたほうが良いと考えています。
それから、諸々、技術の比較がでていますが、「JavaScriptは書いているうちに覚える」が基本だと思っています。やっぱり、学習はなんでもそうですが、実践でやってみることが一番です。JavaScriptをフレームワークやライブラリを使わず素の状態だけでやれ、は正直僕もブラウザで使えるAPIを把握していないので、できるとは思いますが、かなり辛いです。僕もJavaScriptは、フレームワークを使った開発を通して覚えている節があります。実際の開発の場においても、素のJavaScript縛りというのは、かなり珍しいパターンだと思います。ですので、まずは、フレームワークの学習と同時に必要なJavaScriptの文法を理解していく、で良いのではないかと思います。
>>今後フレームワークが固まった時に簡単に移れるのと、私のように素のJSがガリガリかけない人が逆にフレームワーク
だけをやってしまうと、フレームワークが変わった時に、移ることが厳しく、技術を使うのではなく使われる人になってしまうという、
話を聞いたことがあります。
僕は上記の意見については疑問です。
まず、JavaScriptフレームワークはこれまでの歴史の中を振り返っても、これだ！と決まったことは一度もありません。歴史を見ても、新しいフレームワークの出現、淘汰の歴史を繰り返しているのが現実です。それでいうと、「いつやるの？今でしょ！」という話にしかなりません。
あとは、コメントの中で列挙しているフレームワークを学ぶと仮定した場合、それらのフレームワークにはいくつか共通項があるので、今後どれかを学んで極めていった場合に、他のフレームワークに移りにくいという意見は少しおかしいと思います。
今のモダンJavaScriptフレームワークで、最近のコメントで比較にあがっている、React. Riot.js, Vue.js, Angular JSは、共通項として、基本的にはReactでいう仮想DOMのような抽象概念でViewを描画する、またコンポーネント志向です(※Angular JSは2.Xから)。このようにモダンフレームワークでは、基本概念がほとんど似ているので、僕はReactができれば、Vue.jsだってRiot.jsだってできると思っています。Angular JSだけはどうしても独自色が強いのですが、わりかし学習コストとしては重めと言われるAngular JSが理解できたのなら、他のフルスタックでないフレームワークだって理解ができると思います。現に僕は、Angular JSを使いますが、今はReactを勉強していて、今のところReactが難解で分からない、ということはないです。これは僕の意見ですが、フレームワーク1つだけを知るというのは完全に型にはまった行動なので、僕は他も積極的に知るべきだと思います。それこそ、型にはまった頭になると、上記の主張のように、凝り固まった変化のできない人材になってしまいます。
以上より、決め付けの理論で技術を他へ転用できないというのはいうことはやめるべきです。新しいフレームワークを学習する・しないによりもちろん個人差も出てきますし、決め付けの理論は無駄だと思います。
最後に、JavaScriptのフレームワーク論争は、プログラミング言語の論争とたいして変わらないと思っています。ですので、純粋にJavaScriptを学びたい！という気持ちでここは一歩踏み出して、まずはここで挙がっているモダンフレームワークのどれか1つにトライしてみることをお勧めします。僕が挙げたフレームワークの中では、最初に学習するフレームワークとして選択するものはVue.jsがとっつきやすいと思います。Reactができると今後の人材市場でかなりポイントが高いと思いますが、僕はデータバインド以外にテンプレート向け構文があるなど、ある程度の機能がまとまっているVue.jsを標準として覚えていったほうが、今後JS好きさんが他のフレームワークを学ぶにあたり良い軸になるのではないかと思っています。
ここまで、自分が使ったことのないVue.jsをお勧めしておいて、このまま投げっぱなしも嫌なので、リクエストがあれば、責任を持ってチュートリアルか何かの記事を書くことをお約束します(もちろん、Reactでもいいですが)。
お返事ありがとうございます。
Vanila jsというジョークについて記載があります。アメリカンジョークってやつでしょうね。
https://blogs.msdn.microsoft.com/chack/2013/01/16/vanilla-js-javascript/
＞＞＞
jQueryについてですが、今後についてはなんとも言えません。僕はJavaScriptを知る上で、jQueryというライブラリは必須だと思っています。例えば、ブラウザのエンジンが急激に進化をして、DOM操作のコストが圧倒的に低くなったら、またそれなりに注目をされると思いますし(現状では、複雑なDOM操作時の変更コストが高いので、ReactのようなDOMをより抽象化したレイヤーで操作して見た目を変更するフレームワークが流行っていると認識しています)。それに、なんといっても、JavaScriptの見た目上の操作の基本を知る上でこれ以上に簡単に操作ができ、安定した、長くメンテナンスもされ続けているライブラリは他にないと思います。個人的には、jQueryはいつの時代も存在する、初心者から中級者に好んで使われるという技術というポジションは今後もゆるがないと思っています。ただ、現状だとあまりにDOMの描画コストが高いので、中級者、上級者はReact、Angular JSなどのフレームワークに移り、低コストなDOMのレンダリングに慣れたほうが良いと考えています。
jQueryオワコンではなかったのですね！！！
むしろIE8が切り捨てられた後も残り続けるので、必須の知識ということなのですね。
そうであれば、せっかくある程度やってしまったので、まずjQueryでガリガリパララックス、スライドショーなどを自分で作成できるようになり、
小規模WEBサイト制作の仕事を請けている段階ではとりあえずこちらでよいのかもしれないですね。
おそらくView、Riotよりもこれ以上ないくらい簡単だが、必須の知識なんでしょうから。
そして、その後、大規模サイト制作にかかわったり、将来はハイブリットアプリ制作もしたいと思っているので、
この段階でView、Riot、Reactなりを始めるとよいのかもしれないと思いました。
jQueryは消えてしまうので、学んでも経験積んでも時間の無駄かと思っていたのが、見当違いだったようです。
教えていただいてありがとうございます。
＞＞＞
それから、諸々、技術の比較がでていますが、「JavaScriptは書いているうちに覚える」が基本だと思っています。やっぱり、学習はなんでもそうですが、実践でやってみることが一番です。JavaScriptをフレームワークやライブラリを使わず素の状態だけでやれ、は正直僕もブラウザで使えるAPIを把握していないので、できるとは思いますが、かなり辛いです。僕もJavaScriptは、フレームワークを使った開発を通して覚えている節があります。実際の開発の場においても、素のJavaScript縛りというのは、かなり珍しいパターンだと思います。ですので、まずは、フレームワークの学習と同時に必要なJavaScriptの文法を理解していく、で良いのではないかと思います。
素のJSはbabelを使ったとしても、まだ、ブラウザ間の差があったり、問題が起きることがIE9以降でもあるのですね。
大変さも難易度も、クロスブラウザの問題もbabelを使ってもありすぎるので、ライブラリを使ったWEBアプリ制作が、現場でもほぼ主流ということですね。
おそらく今はjQueryで将来はReactが中心になるのでしょうね。
またjQueryなどのライブラリを使ってWEBアプリを作っていると、JSの本質がわからないままになるということはないのですね。
結局ライブラリもJSがベースなので。
＞＞＞
まず、JavaScriptフレームワークはこれまでの歴史の中を振り返っても、これだ！と決まったことは一度もありません。
今後も何かに落ち着くことはほぼ考えられないのですね。
このカオスがずっと続くということですね。
＞＞＞
ここまで、自分が使ったことのないVue.jsをお勧めしておいて、このまま投げっぱなしも嫌なので、リクエストがあれば、責任を持ってチュートリアルか何かの記事を書くことをお約束します(もちろん、Reactでもいいですが)。
お忙しい中大変ありがとうございます。その時はどうぞよろしくお願いいたします。
>>JS好きさん
こんばんは、mmiyauchiです。
補足の内容がありますので、下記にコメントします。
Vanila JSですが、Reactのドキュメントを読んでいたら、「vanilla JavaScript」なる記述を見つけました。
Getting Started | React
https://facebook.github.io/react/docs/getting-started.html
どうやら確かに、文脈からして「素のJavaScript」を指すようです。Vanilla JavaScriptは、現在でも使われるスラングということです。勉強不足で妙なコメントを書いてしまい、失礼致しました。
それから、jQueryについてです。
jQueryライブラリはオワコンでは全くなく、そもそも本質的にはフレームワークとは比較してはいけないものだという認識です。ReactやAngular JSはフレームワークであり、jQueryはライブラリです。フレームワークとライブラリはそもそも性質が異なります。ライブラリとフレームワークの違いについては、Webに多くの知見がありますから説明は省略しますが、とにかく分類が異なりますので、よく混同はされますが、厳密にはjQueryとReactやAngular JSとは比較はできないもの同士になります。
jQueryはJavaScriptのライブラリの中では、JavaScriptのこれまでの歴史を見ても廃れず長期にわたって初心者から中級者に特に親しまれるもので、これはJavaScriptフレームワーク全盛時代の今においても、他のJavaScriptライブラリには今後も到底崩せないほどの圧倒的シェアがあると思います。また、2番手のDOM操作が得意なJavaScriptライブラリの名前すら出てこないので、今後もおそらく「JavaScriptのライブラリといえばjQuery」というポジションは揺るがないだろう、という予想です。
jQueryを使った開発についてですが、jQueryのみで開発をしていると、いずれDOMのレンダリングコストについてストレスを感じたり、DOM操作だけがしたいのに、なぜHTMLファイルへclassやidの記述を積極的に行わないといけないのか？、など開発が大きくなっていくほど、jQueryのみで開発を行う事への疑問が出てくると思います。人それぞれ技術的な疑問を感じる点が異なるとは思いますが、jQueryのパフォーマンスや、開発上の疑問や課題が出てきたら、それはjQueryのみの開発からのステップアップのタイミングであり、初級者・中級者を脱し、JavaScriptフレームワークを実践する段階だと思います。
jQueryは、Webデザイナーの方、JavaScriptの初級者や中級者が、フロントエンド技術を学び、実力を付けるための良いライブラリであることは間違いないです。ですが、僕はフロントエンド技術がjQueryのみというのは、スケールさせる開発には向いていない構成だと思っています。
最初はjQueryをじっくり学習されて、jQueryを使いこなせる技量を目指すのが良いかと思いますが、ぜひステップアップのタイミングがきた際には、フレームワークにも挑戦してみてください。JS好きさんの先のコメントにも、まずは、jQueryから入り実力を付け、いずれ大規模サイト制作をするようなタイミングにて、フレームワークに挑戦したいという事を書かれていますが、全くその通りで、僕もベストな考えだと思います。
お返事ありがとうございます。
jQueryはReactのように不動の地位を占めているので、WEBの仕事がなくなるまで、ずっと残り続け、
知らないことは許されず、WEBデザイナーが、小規模サイト制作をするくらいなら、これで十分そうですね。
しかもJS初心者の学習にはvue、react、riotよりよいのであればまずこれでガリガリ、パララックス、スライドショーなどを自分で作れるようになり、
数年後余裕が出て、ハイブリットアプリ制作がしたくなった時にvue、react、riotなどを学べばよさそうですね。
http://d.hatena.ne.jp/tomoya/20160403/1459665374より
個人的には、これからJavaScriptを覚えたいという人は、最初からES2015で覚える方が良いでしょう。
上記サイトにありますが、もうすでに最初からES2015で覚えて問題ない時代に入っているようなので、
jQueryをES2015で書けるなら、そのように学習をしていくのが、私の場合ベストかもしれないですね。
Airbnb JavaScript Style Guideで文法チェックをしていけばES2015をいつの間にかできるようになるようですね。
サブライムを使っている私がこのような環境をどう導入していくかをこれから調べていかないといけないですが、
おそらくこればベストプラクティスなのかなと現段階で考えています。
ESLint + Airbnb JavaScript Style Guideの組み合わせ難しそうですね。
gulpでCSSLintなどをうまく導入できないレベルの私には難しいですかね。
お忙しい中大変恐縮ですが、もしご迷惑でなければ、gulpのソースを記載させていただきますので、
どこに問題があるかご解説いただくことは可能でしょうか？
色々とすいません。
>>JS好きさん
こんばんは。
難しいところですが、JavaScriptフレームワークはわりといつも戦国時代なので、Reactは不動ではない可能性があります。ライブラリのjQueryは、それこそ昔から「JavaScriptライブラリといえばjQuery」という地位が変わってないので、今後も不動なのではないかという予想です。
ES 2015(ES6)ですが、もしも分かりにくい場合は、最初はそれ以前のシンタックスで勉強されるのが良いかと思います。
実際のところ、現状僕も完璧にES2015のシンタックスを網羅してコードを書いてはいないです。もしES2015のシンタックスの勉強されるのなら、最初の教材としてはこちらがオススメです。
Amazon.co.jp: 速習ECMAScript6: 次世代の標準JavaScriptを今すぐマスター！ 電子書籍: 山田祥寛: Kindleストア
https://www.amazon.co.jp/gp/product/B014MS5XWK/
こちらの本は、67ページと短いので、サクッと代表的なシンタックスを学ぶ事ができます。
gulpは僕は普段使わないのですが、僕で良ければ調べてみてレビューすることは可能ですよ。
お返事いただいていたのですね。
gulpのレビューを頂けるということで、大変ありがとうございます。
私は下記のようにgulpを使っています。
//gulpfile.js
var gulp = require(‘gulp’); //gulpをインポート
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’); //gulp-postcssをインポート
var cssnext = require(‘postcss-cssnext’); //cssnextをインポート
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(“postcss-custom-properties”);
var customMedia = require(“postcss-custom-media”); //うまくいっていない。カスタムメディアクエリーズが使える
gulp.task(‘css’, function () { //”css”タスクを登録
var plugins = [
postcssimport,
cssnext, //一旦空の配列を作成
nested,
calc,
csswring,
customProperties,
customMedia
];
console.log( Array.isArray(plugins) );//pluginsの定義の後で、 !Array.isArray(plugins)の値がどうなってるかをログを取る為
return gulp.src(
[‘./src-before/*’ , ‘./src-before/*/*’],
{ base: ‘src-before’ }) //src-before下にある.cssファイルを指定
.pipe(postcss(plugins)) //PostCSSにファイルを処理してもらう
.pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
});
//以下gulp-watch
gulp.task(‘watch’, function(){
gulp.watch([‘src-before/*’ , ‘src-before/*/*’ , ‘src-before/*/*/*’], [‘css’]);//監視したいファイルの相対パス
});
・postcss-custom-mediaがうまくいっていません。ただプラグインをインストールして、上記のように記載すればよいということではないのでしょうか？
そうでないものは、どんな作業がさらに必要なのでしょうか？
・下記も同じようにやったのですがうまく行きませんでした。削除してあります。
var cssComb = require(‘gulp-csscomb’);
var csslint = require(‘gulp-csslint’);
var plumber = require(‘gulp-plumber’);
>>JS好きさん
こんばんは。
gulpfile.jsのレビューの件、お待たせしました。
動作確認がとれたコードができたので、gulpで実行できるgulpfile.jsの最小のコードを共有します。
gulpfile.js
const gulp = require('gulp');const postcss = require('gulp-postcss');
const customMedia = require('postcss-custom-media');
gulp.task('default', () => {
const processors = [
customMedia(),
];
return gulp.src('public/css/postcss/*.css')
.pipe(postcss(processors))
.pipe(gulp.dest('public/css'));
});
ES6の話題によくなっていると思ったので、ES6の文法で書いてみました。もし読みにくい場合はBabel公式にあるこちらで変換して見てみてください。今回、エラーから調べ出し、遠回りしましたが、最終的にはGithubのgulip-postcssとpostcss-custom-mediaの2つのページが最も参考になりました。
あとは、つまらないものですが、gulpなしでpostcss-custom-mediaが動くものも書きました。
postcss_custom_media.js
const postcss = require('postcss');const customMedia = require('postcss-custom-media');
const fs = require('fs');
const inputCss = fs.readFileSync('public/css/postcss/input.css', 'utf8');
const outputCss = postcss()
.use(customMedia())
.process(inputCss)
.css;
fs.writeFileSync('public/css/input.css', outputCss, 'utf8');
//console.log(inputCss);
//console.log(outputCss);
というのも、Githubのpostcss-custom-mediaのページの更新状況を見て、パッケージがメンテナンスされてるか少し怪しいなあと思ったからです。上記コードは、Githubのpostcss-custom-mediaにあるサンプルコードに少し手を加えたものですが、Node.js v6.6.0で動作確認が取れているコードとなります。postcss-custom-mediaは問題なく動くようですね。
最後に、JS好きさんのコードでのパッと見のエラーの原因ですが、おそらくはpostcssへ渡すタスクの配列の「plugin」の中身が問題だと思います。この配列は、postcssが実行していくための関数を羅列したものになりますので、正しい記述はcustomMediaではなく、customMedia()になります。
どうでしょうか？
お忙しいと思いますので、いつでも良いですが、レビューができたら教えてください。
楽しみにしています。
もっと必要な情報があればお伝えください。
ES6はcssでいうSASSのように、ほとんどのプロがすでに使ている、ないしは今後すぐに使うようになるわけではなく、ほんの一部のバリバリのプログラマーだけが、使い始めている程度なのですね。
WEBデザイナーならおそらく99%使っていないでしょうね。
jQueryでもES6で記載することができると考えてよいですかね。
教えていただいた本をざっと見て、これは便利だなというものだけを取り入れるくらいで始めるといいかもしれないですね。
あまりにたくさんあるので、すべてをはじめから取り入れる、覚えるというのはとても無理そうですね。
POSTCSSと同じようにいいと思ったものだけにしてみます。
本の内容は下記のようなサイトと同じですかね？それとももっと詳細な解説があり初心者にもわかりやすくなっているのですかね？
下記を見ただけでは難しいですね。
http://qiita.com/takeharu/items/cbbe017bbdd120015ca0
>>JS好きさん
こんばんは。
申し訳ないですが、gulpレビューの件、まとまった時間が確保できておらず進んでおりません。
レビューについては、もう少しお待ち頂ければと思います。
ES6のシンタックスについては、JavaScriptをそれこそ専門に扱う方は、ES6のブラウザの対応スピードをみても、今現状では積極的に取り入れるべきとは思います。一方で、JavaScriptにそれほど詳しくない方や、入門者が扱う場合には混乱するかもしれないので、慣れた頃のほうが良いと思います。
また、jQueryでももちろんES6のシンタックスは扱えます。JavaScriptの最新シンタックスの利用可能な条件は、フレームワークやライブラリ関係なく、ブラウザやNode.jsなど、JavaScriptの動作環境が該当するシンタックスに対応しているか否かで決まります。
下記のサイトは、JavaScriptの最新シンタックスの対応表を掲載しているので、何かあれば参考にされると良いと思います。
ECMAScript 6 compatibility table
http://kangax.github.io/compat-table/es6/
それからコメントにあったES6解説記事ですが、基本的には、ソースコードの例文記載でまさにこういった感じで説明されていることが多いですので、紹介した書籍でもこういった感じです。
また、記事内容と書籍とでは、取り扱っているシンタックスの内容はほぼ同じと思います。
ただ、この記事だけだと、紹介した書籍よりもパッと見ですが、少し取り扱っている内容が少ないと思ったので、他の記事も併用して内容を補完していくと良いと思います(もっとも、書籍のほうもES6の全てをカバーしているわけではありませんが)。
こんばんは、
お忙しいと思いますので、いつでも構いません。
＞＞＞
ES6のシンタックスについては、JavaScriptをそれこそ専門に扱う方は、ES6のブラウザの対応スピードをみても、今現状では積極的に取り入れるべきとは思います。一方で、JavaScriptにそれほど詳しくない方や、入門者が扱う場合には混乱するかもしれないので、慣れた頃のほうが良いと思います。
前に添付したサイトにこれからやる人は初めからES6でよいと記載があったので、そのようにしたほうがいいのかと思ったのですが、
ES5より難しいので、ES5から始めたほうが良いということでしょうか？
ES6から始めたほうが一見無駄な時間を使わずに合理的なように感じてしまいますが、ES5の知識はトランスパイルするとしても、
かけなくてもよいが、他人が作ったものや、プラグイン、グーグルマップなどを使う際に読めないといけないので、
読む能力だけは、これからやる人にも必須なので、ES5から始めたほうが、良いということですかね？
＞＞＞
また、jQueryでももちろんES6のシンタックスは扱えます。JavaScriptの最新シンタックスの利用可能な条件は、フレームワークやライブラリ関係なく、ブラウザやNode.jsなど、JavaScriptの動作環境が該当するシンタックスに対応しているか否かで決まります。
下記のサイトは、JavaScriptの最新シンタックスの対応表を掲載しているので、何かあれば参考にされると良いと思います。
jQueryなどのライブラリ、reactなどのフレームワークすべて、ES6は問題なく使えるのですね。
トランスパイルすればどのブラウザでもOKということですね
ありがとうございます。
＞＞＞
ECMAScript 6 compatibility table
http://kangax.github.io/compat-table/es6/
それからコメントにあったES6解説記事ですが、基本的には、ソースコードの例文記載でまさにこういった感じで説明されていることが多いですので、紹介した書籍でもこういった感じです。
また、記事内容と書籍とでは、取り扱っているシンタックスの内容はほぼ同じと思います。
ただ、この記事だけだと、紹介した書籍よりもパッと見ですが、少し取り扱っている内容が少ないと思ったので、他の記事も併用して内容を補完していくと良いと思います(もっとも、書籍のほうもES6の全てをカバーしているわけではありませんが)。
書籍が一番多くのシンタックスがきさいしてありますが、WEB上の情報でも同じように学習は十分できるということですね。
上記サイトは正直、JSの学習を始めたばかりの私には、説明が、専門的過ぎて、端的過ぎて理解が難しかったです。
もし初心者でもわかりやすいサイトなどをご存知でしたら、お忙しい中恐縮ですが教えていただければ幸いです。
>>JS好きさん
おはようございます。
夜遅くだったので、コメントが小出しになってしまいました。
JavaScript初学者のES6の学習時期についてですが、人によってだいぶアドバイスの内容がぶれるかと思います。僕はあくまで現状日本語文献でも情報が揃っている、ES6以前のシンタックスのほうが分からなくなったときに理解しやすいので、JavaScript初学者が今後JavaScriptの学習をしてくのなら、まずはES5での学習を勧めます。
あと、ES6ができればそれ以前のES5のシンタックスが読めなくてよいか、という点ですが、それはもちろん読めないとダメだと思います。オープンソースソフトウェアのドキュメントでは、ES6のシンタックスで積極的に書かれているものはあまり見ない気がします。現実的に、JavaScriptを取り巻く周辺環境では、未だES5が多いですので、ES5の学習から入って何か困るということはあまりないのではないかと思います。僕もES6の全文法を把握してはいないので、なんとも言えないのですが、ES6のベースにあるのはこれまでのES5で、これまでのシンタックスより洗練した書き方に導いているのがES6だという認識です。あくまでJavaScriptの基礎はES5にあると思っています。
あとは、ES6シンタックスについて丁寧に解説されているサイトがあれば、ということですが、少し探してみましたが、見当たらないですね。解説のやり方が決まっていて、ES5のサンプルコードとES6のサンプルコードの対比という形式で、少しコメントがあれば良いくらいで、わりとどこもあっさりしています。基本的にES6を網羅したい場合は英語文献を積極的に当たっていく必要があると思います。丁寧さでいうと、少し前のコメントで紹介した下記の本が良いかもしれません。基本的にフォーマットが本ですので、解説内容は多いほうだと思います。
Amazon.co.jp: 速習ECMAScript6: 次世代の標準JavaScriptを今すぐマスター！ 電子書籍: 山田祥寛: Kindleストア
https://www.amazon.co.jp/gp/product/B014MS5XWK/
>>JS好きさん
こんにちは。
gulpのコードレビューの件ですが、最初に頂いたソースコードの下にコメントしました(※コメントが少し前のものに返してしまったので、分かりにくくて失礼しました)。
その後、いかがでしょうか。
もしサンプルのコードが動かないだったり、分からない箇所があったらコメントください。
お返事遅れてすいません。上の方にコメント頂いていたのですね。
気付かずにお返事遅れてすいませんでした。
早速確認させて頂きますので、少しお待ちください。
私のコードの一部に代入をすればいいのですね。
nodejsがよくわかないので見様見真似ですが下記のようにしたところ、ある程度まで行ったような気がします。
//gulpfile.js
var gulp = require(‘gulp’); //gulpをインポート
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’); //gulp-postcssをインポート
var cssnext = require(‘postcss-cssnext’); //cssnextをインポート
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(“postcss-custom-properties”);
var customMedia = require(“postcss-custom-media”); //うまくいっていない。カスタムメディアクエリーズが使える
// gulp.task(‘css’, function () { //”css”タスクを登録
// var plugins = [
// postcssimport,
// cssnext, //一旦空の配列を作成
// nested,
// calc,
// csswring,
// customProperties,
// customMedia
// ];
gulp.task(‘css’, function () {
var processors = [customMedia(),postcssimport(),cssnext()];
console.log( Array.isArray(plugins) );//pluginsの定義の後で、 !Array.isArray(plugins)の値がどうなってるかをログを取る為
return gulp.src(
[‘./src-before/*’ , ‘./src-before/*/*’],
{ base: ‘src-before’ }) //src-before下にある.cssファイルを指定
.pipe(postcss(processors))
.pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
});
// return gulp.src(
// [‘./src-before/*’ , ‘./src-before/*/*’],
// { base: ‘src-before’ }) //src-before下にある.cssファイルを指定
// .pipe(postcss(plugins)) //PostCSSにファイルを処理してもらう
// .pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
// });
// var gulp = require(‘gulp’);
// var postcss = require(‘gulp-postcss’);
// var customMedia = require(‘postcss-custom-media’);
// gulp.task(‘default’, function () {
// var processors = [customMedia()];
// return gulp.src(‘public/css/postcss/*.css’).pipe(postcss(processors)).pipe(gulp.dest(‘public/css’));
// });
//以下gulp-watch
gulp.task(‘watch’, function(){
gulp.watch([‘src-before/*’ , ‘src-before/*/*’ , ‘src-before/*/*/*’], [‘css’]);//監視したいファイルの相対パス
});
・ReferenceError: plugins is not definedと出てしまいます。プラグインの指定方法が間違っているのでしょうか？
C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト>gulp watch
(node:14796) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
[21:49:35] Using gulpfile ~\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js
[21:49:35] Starting ‘watch’…
[21:49:35] Finished ‘watch’ after 210 ms
[21:49:46] Starting ‘css’…
[21:49:50] ‘css’ errored after 3.41 s
[21:49:50] ReferenceError: plugins is not defined
at Gulp. (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js:27:28)
at module.exports (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\lib\runTask.js:34:7)
at Gulp.Orchestrator._runTask (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:273:3)
at Gulp.Orchestrator._runStep (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:214:10)
at Gulp.Orchestrator.start (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:134:8)
at Gulp. (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gulp\index.js:36:18)
at Gaze. (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\glob-watcher\index.js:18:14)
at emitTwo (events.js:106:13)
at Gaze.emit (events.js:191:7)
at Gaze.emit (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:129:32)
at C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:415:16
at StatWatcher._pollers.(anonymous function) (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:326:7)
at emitTwo (events.js:106:13)
at StatWatcher.emit (events.js:191:7)
at StatWatcher._handle.onchange (fs.js:1487:10)
コード届いているでしょうか?
お時間のある時で構いませんのでよろしくお願いします。
>> JS好きさん
こんばんは、mmiyauchiです。
ソースコードですね。
お問い合わせやこちらのコメント履歴を確認したのですが、JS好きさんからのソースコードは見当たりませんでした。
お手数ですが、もう一度こちらのコメントかお問い合わせフォームに内容を送って頂けますでしょうか。
うまく投稿できていなかったようですいません。
再度投稿します。
nodejsがよくわかないので見様見真似ですが下記のようにしたところ、ある程度まで行ったような気がします。
//gulpfile.js
var gulp = require(‘gulp’); //gulpをインポート
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’); //gulp-postcssをインポート
var cssnext = require(‘postcss-cssnext’); //cssnextをインポート
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(“postcss-custom-properties”);
var customMedia = require(“postcss-custom-media”); //うまくいっていない。カスタムメディアクエリーズが使える
// gulp.task(‘css’, function () { //”css”タスクを登録
// var plugins = [
// postcssimport,
// cssnext, //一旦空の配列を作成
// nested,
// calc,
// csswring,
// customProperties,
// customMedia
// ];
gulp.task(‘css’, function () {
var processors = [customMedia(),postcssimport(),cssnext()];
console.log( Array.isArray(plugins) );//pluginsの定義の後で、 !Array.isArray(plugins)の値がどうなってるかをログを取る為
return gulp.src(
[‘./src-before/*’ , ‘./src-before/*/*’],
{ base: ‘src-before’ }) //src-before下にある.cssファイルを指定
.pipe(postcss(processors))
.pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
});
// return gulp.src(
// [‘./src-before/*’ , ‘./src-before/*/*’],
// { base: ‘src-before’ }) //src-before下にある.cssファイルを指定
// .pipe(postcss(plugins)) //PostCSSにファイルを処理してもらう
// .pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
// });
// var gulp = require(‘gulp’);
// var postcss = require(‘gulp-postcss’);
// var customMedia = require(‘postcss-custom-media’);
// gulp.task(‘default’, function () {
// var processors = [customMedia()];
// return gulp.src(‘public/css/postcss/*.css’).pipe(postcss(processors)).pipe(gulp.dest(‘public/css’));
// });
//以下gulp-watch
gulp.task(‘watch’, function(){
gulp.watch([‘src-before/*’ , ‘src-before/*/*’ , ‘src-before/*/*/*’], [‘css’]);//監視したいファイルの相対パス
});
・ただし、ReferenceError: plugins is not definedと出てしまいます。プラグインの指定方法が間違っているのでしょうか？
C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト>gulp watch
(node:14796) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
[21:49:35] Using gulpfile ~\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js
[21:49:35] Starting ‘watch’…
[21:49:35] Finished ‘watch’ after 210 ms
[21:49:46] Starting ‘css’…
[21:49:50] ‘css’ errored after 3.41 s
[21:49:50] ReferenceError: plugins is not defined
at Gulp. (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js:27:28)
at module.exports (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\lib\runTask.js:34:7)
at Gulp.Orchestrator._runTask (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:273:3)
at Gulp.Orchestrator._runStep (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:214:10)
at Gulp.Orchestrator.start (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:134:8)
at Gulp. (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gulp\index.js:36:18)
at Gaze. (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\glob-watcher\index.js:18:14)
at emitTwo (events.js:106:13)
at Gaze.emit (events.js:191:7)
at Gaze.emit (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:129:32)
at C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:415:16
at StatWatcher._pollers.(anonymous function) (C:\Users\hoto\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:326:7)
at emitTwo (events.js:106:13)
at StatWatcher.emit (events.js:191:7)
at StatWatcher._handle.onchange (fs.js:1487:10)
投稿できていますか？
もしかして文字数制限やタグの制限があるのでしょうか？
うまく投稿できていなかったようですいません。
再度投稿します。
nodejsがよくわかないので見様見真似ですが下記のようにしたところ、ある程度まで行ったような気がします。
//gulpfile.js
var gulp = require(‘gulp’); //gulpをインポート
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’); //gulp-postcssをインポート
var cssnext = require(‘postcss-cssnext’); //cssnextをインポート
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(“postcss-custom-properties”);
var customMedia = require(“postcss-custom-media”); //うまくいっていない。カスタムメディアクエリーズが使える
// gulp.task(‘css’, function () { //”css”タスクを登録
// var plugins = [
// postcssimport,
// cssnext, //一旦空の配列を作成
// nested,
// calc,
// csswring,
// customProperties,
// customMedia
// ];
gulp.task(‘css’, function () {
var processors = [customMedia(),postcssimport(),cssnext()];
console.log( Array.isArray(plugins) );//pluginsの定義の後で、 !Array.isArray(plugins)の値がどうなってるかをログを取る為
return gulp.src(
[‘./src-before/*’ , ‘./src-before/*/*’],
{ base: ‘src-before’ }) //src-before下にある.cssファイルを指定
.pipe(postcss(processors))
.pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
});
// return gulp.src(
// [‘./src-before/*’ , ‘./src-before/*/*’],
// { base: ‘src-before’ }) //src-before下にある.cssファイルを指定
// .pipe(postcss(plugins)) //PostCSSにファイルを処理してもらう
// .pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
// });
// var gulp = require(‘gulp’);
// var postcss = require(‘gulp-postcss’);
// var customMedia = require(‘postcss-custom-media’);
// gulp.task(‘default’, function () {
// var processors = [customMedia()];
// return gulp.src(‘public/css/postcss/*.css’).pipe(postcss(processors)).pipe(gulp.dest(‘public/css’));
// });
//以下gulp-watch
gulp.task(‘watch’, function(){
gulp.watch([‘src-before/*’ , ‘src-before/*/*’ , ‘src-before/*/*/*’], [‘css’]);//監視したいファイルの相対パス
});
>>JS好きさん
こんばんは。
コードを確認しました。
すみません、全てのモジュールをインストールしてどのモジュールでエラーが出ているか、一から検証というのはあまりやりたくないのですが(対象モジュール数が多いため)、今回ピンポイントで質問があったpostcss-custom-mediaモジュールについては解決したつもりですが、他のどのモジュールが動かせていないかを教えてもらえますか？
対象モジュールが分かれば、そのモジュールが動作するための最小のコードをpostcss-custom-mediaの例のように提供できるとは思います。
gulpを今回少し触った感覚値としては、基本的にNode.jsは環境構築とコード冒頭のrequire()くらいだと思っているので、あとは各モジュールのマニュアルを読んでモジュールの取り扱いに従ってやっていけばできると思いますよ。
Node.jsのAPIを使うシーンというのは、require()の他には基本的には無いような気がしています。
・ただし、ReferenceError: plugins is not definedと出てしまいます。プラグインの指定方法が間違っているのでしょうか？
C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト>gulp watch
(node:14796) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
[21:49:35] Using gulpfile ~\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js
[21:49:35] Starting ‘watch’…
[21:49:35] Finished ‘watch’ after 210 ms
[21:49:46] Starting ‘css’…
[21:49:50] ‘css’ errored after 3.41 s
[21:49:50] ReferenceError: plugins is not defined
at Gulp. (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js:27:28)
at module.exports (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\lib\runTask.js:34:7)
at Gulp.Orchestrator._runTask (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:273:3)
at Gulp.Orchestrator._runStep (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:214:10)
at Gulp.Orchestrator.start (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:134:8)
at Gulp. (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gulp\index.js:36:18)
at Gaze. (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\glob-watcher\index.js:18:14)
at emitTwo (events.js:106:13)
at Gaze.emit (events.js:191:7)
at Gaze.emit (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:129:32)
at C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:415:16
at StatWatcher._pollers.(anonymous function) (C:\Users\user\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:326:7)
at emitTwo (events.js:106:13)
at StatWatcher.emit (events.js:191:7)
at StatWatcher._handle.onchange (fs.js:1487:10)
やはり文字数制限があるようですね。
二度に分けたら投稿できました。
お返事大変ありがとうございます。
私はNodejsがわかっていないのですいませんが見様見真似で下記の書き方しかわかりません。
下記の書き方でカスタムメディアがうまくいっていないようなのですが、下記の書き方でどこが問題かご存じないでしょうか？
カスタムメディアは変更されないですが、他はうまくいっているようです。
・ソース
//gulpfile.js
var gulp = require(‘gulp’); //gulpをインポート
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’); //gulp-postcssをインポート
var cssnext = require(‘postcss-cssnext’); //cssnextをインポート
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(“postcss-custom-properties”);
var customMedia = require(“postcss-custom-media”); //うまくいっていない。カスタムメディアクエリーズが使える
gulp.task(‘css’, function () { //”css”タスクを登録
var plugins = [
postcssimport,
cssnext, //一旦空の配列を作成
nested,
calc,
csswring,
customProperties,
customMedia
];
console.log( Array.isArray(plugins) );//pluginsの定義の後で、 !Array.isArray(plugins)の値がどうなってるかをログを取る為
return gulp.src(
[‘./src-before/*’ , ‘./src-before/*/*’],
{ base: ‘src-before’ }) //src-before下にある.cssファイルを指定
.pipe(postcss(plugins)) //PostCSSにファイルを処理してもらう
.pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
});
//以下gulp-watch
gulp.task(‘watch’, function(){
gulp.watch([‘src-before/*’ , ‘src-before/*/*’ , ‘src-before/*/*/*’], [‘css’]);//監視したいファイルの相対パス
});
お忙しいと思いますので、いつでもいいですが、その後どうでしょうか？上記の書き方では難しいでしょうか？
>> JS好きさん
こんばんは。
お返事が遅れました。
以前のコメントですが、確認したところスパムコメントとして引っかかっていたみたいです。もしかしたら、JavaScriptソースコードが原因かもしれません。
※10月17日コメントのものは、最初のコードと同じような気がするので、15日コメントのものがレビュー対象として正しいと思うので、そちらのコードについてレビューします
コードのレビューですが、コメントで頂いているコードでは、return gulp.src()の内部のコードが自分が書いたコードの内容と異なっています。
また、タスク中にgulp.src()が2回出現しています(1回目でのみreturnしているので、2回目はもしかしたら特に実行上の意味はないかもしれません。しかし、2回目のほうが僕がレビュー後に共有した正常動作するコードです)。
あとは、gulpfile.jsには、基本的にはdefaultという名称のタスクが存在することが推奨されているようです。頂いているコードでは、cssという名称のタスクしかありませんでした。今回のソースコードでは、gulp.watch()のみでの動作を想定されているのかもしれませんが、基本的にはタスクが1つの場合はタスクの名称はdefaultと定義してgulpコマンドでデバッグして動作確認を取りつつコードを記述するのが良いのではないしょうか。
それから、新しくgulpfile.jsを記述しました。今回は、全てのモジュールが対象です。
参照しやすいようにGithubにアップロードしましたので、下記URLから内容をご確認ください。
samplecode/gulpfile.js at master · m-miyauchi/samplecode
https://github.com/m-miyauchi/samplecode/blob/master/gulpfile.js
全てのモジュールが正常動作しているかなどは確認できていないですが、gulpタスクの正常実行はdefaultタスクとgulp.watch()ともに確認できています。実行環境は、Node.js v6.9.1です。
今回のgulpタスクのソースコードですが、gulp-postcssを使用したものとなっていますので、より理解を得るためにもgulp-postcssの公式ドキュメントを今一度確認されてみてはいかがでしょうか。
お返事大変ありがとうございます。
下記のように自分の環境に合わせたのですが、gulpwatchが反応しません。
その前までは来ていると思います。おかげ様です。
var gulp = require(‘gulp’);
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’);
var cssnext = require(‘postcss-cssnext’);
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(‘postcss-custom-properties’);
var customMedia = require(‘postcss-custom-media’);
// 処理対象ディレクトリと出力先ディレクトリを指定
var targetDiretory = ‘./src-before/* , ./src-before/*/* , ./src-before/*/*/*’;
var outputDirectory = ‘./dest-after/css’;
gulp.task(‘default’, function () {
var plugins = [
postcssimport(),
cssnext(),
nested(),
calc(),
csswring(),
customProperties(),
customMedia()
];
return gulp.src(targetDiretory)
.pipe(postcss(plugins))
.pipe(gulp.dest(outputDirectory));
});
gulp.task(‘watch’, function() {
gulp.watch(targetDiretory, [‘default’]);
});
・実行結果
(node:6128) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
[15:50:46] Using gulpfile ~\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js
[15:50:46] Starting ‘watch’…
[15:50:46] Finished ‘watch’ after 36 ms
ここどまりです。
・
gulpfile.jsのカレントディレクトリにbefore、destフォルダがあるのであっているはずなのですが、nodejsの文法エラーでしょうか？
何度も大変恐縮ですがあと一歩なのでお願いします。
>> JS好きさん
こんばんは。
上記コードでは、targetDirectoryにおいて、複数ディレクトリの指定の仕方が間違っていますね。
こちらは、gulpのAPIの公式ドキュメントに書いてありますが、配列での指定で行います。
gulp/API.md at master · gulpjs/gulp
https://github.com/gulpjs/gulp/blob/master/docs/API.md#gulpsrcglobs-options
上記コードのtargetDirectoryの書き方だと、単に文字列なので、「./src-before/* , ./src-before/*/* , ./src-before/*/*/*」というディレクトリの指定になってしまいます。
それから、おそらく「src-before/*/*/*」のような形式で、ディレクトリ指定までワイルドカードを入れて指定するのはNGだと思われます。
正しいコードは下記になりますので、参照してください。
samplecode/gulpfile_mutiple_src.js at master · m-miyauchi/samplecode
https://github.com/m-miyauchi/samplecode/blob/master/gulpfile_mutiple_src.js
今回、ディレクトリ構造を維持したまま変換後のコードを得たかったので、gulp.src()でオプションを使用しています。
途中、csswringのみNode.js v6.9.1で正常動作せず、出力コードが何も無い空のファイルになってしまう現象に気付いたので、pluginsのcsswringの箇所はコメントアウトしてあります。
csswringが、単にNode.jsのバージョン差異により動かなかっただけの場合は、コメントアウトを解除してください。
何度もお忙しい中大変ありがとうございます。
下記のようにやってみましたが、まだうまくいきません。
自分でも調べてみます。
var gulp = require(‘gulp’);
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’);
var cssnext = require(‘postcss-cssnext’);
var nested = require(‘postcss-nested’);
// var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(‘postcss-custom-properties’);
var customMedia = require(‘postcss-custom-media’);
// 処理対象ディレクトリ
var targetDirectory = [‘src-before/*’];
// 出力ファイルのディレクトリ維持のため、階層構造のベースとなるルートのディレクトリを指定
var baseDirectory = ‘src-before’;
// 出力先ディレクトリの指定
var outputDirectory = ‘dest-after’;
gulp.task(‘default’, function () {
var plugins = [
postcssimport(),
cssnext(),
nested(),
calc(),
customProperties(),
customMedia()
//csswring() //Node.js v6.9.1では正常動作しない
];
return gulp.src(targetDirectory, { base : baseDirectory })
.pipe(postcss(plugins))
.pipe(gulp.dest(outputDirectory));
});
gulp.task(‘watch’, function() {
console.log(‘task watch’);
gulp.watch([‘src-before/*’ , ‘src-before/*/*’ , ‘src-before/*/*/*’], [‘css’]);//監視したいファイルの相対パス
});
gulp watch
(node:3744) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
[14:21:56] Using gulpfile ~\Desktop\images\gulp-folder\website\サイト\gulpfile.js
[14:21:56] Starting ‘watch’…
task watch
[14:21:56] Finished ‘watch’ after 362 ms
[14:22:08] Task ‘css’ is not in your gulpfile
[14:22:08] Please check the documentation for proper gulpfile formatting
またワイルドカードが使えないのではというお話でしたが下記で問題なく動いているので、おそらくそれはないのではないでしょうか？
//gulpfile.js
var gulp = require(‘gulp’); //gulpをインポート
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’); //gulp-postcssをインポート
var cssnext = require(‘postcss-cssnext’); //cssnextをインポート
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
// var comment = require(‘postcss-comment’);
var customProperties = require(“postcss-custom-properties”);
var customMedia = require(“postcss-custom-media”); //うまくいっていない。カスタムメディアクエリーズが使える
gulp.task(‘css’, function () { //”css”タスクを登録
var plugins = [
postcssimport,
cssnext, //一旦空の配列を作成
nested,
calc,
csswring,
// comment,
customProperties,
customMedia
];
console.log( Array.isArray(plugins) );//pluginsの定義の後で、 !Array.isArray(plugins)の値がどうなってるかをログを取る為
return gulp.src(
[‘./src-before/*’ , ‘./src-before/*/*’],
{ base: ‘src-before’ }) //src-before下にある.cssファイルを指定
.pipe(postcss(plugins)) //PostCSSにファイルを処理してもらう
.pipe(gulp.dest(‘./dest-after/css’)); //生成されたCSSをdest-after下に配置
});
//以下gulp-watch
gulp.task(‘watch’, function(){
gulp.watch([‘src-before/*’ , ‘src-before/*/*’ , ‘src-before/*/*/*’], [‘css’]);//監視したいファイルの相対パス
});
>> JS好きさん
こんにちは。
ディレクトリ指定にワイルドカードが通るということで、検証不足で失礼しました。
ファイル自体にワイルドカード指定するのはよく見かけますが、ファイルパスにおける中間のディレクトリでワイルドカード指定するのはあまり見かけないので、もしかすると通らないのでは？と思ってしまいました。
コードは後で参照しますが、Node.jsとgulpのバージョンを教えてもらえますでしょうか。
何度も大変恐縮です。
node -v
v6.7.0
gulp -v
[15:00:13] CLI version 3.9.1
[15:00:13] Local version 3.9.1
となっております。お忙しいと思いますので、お時間のある時で構いません。
>> JS好きさん
こんばんは。
ソースコードを確認しました。
Noded.js v6.7.0, gulp 3.9.1とJS好きさんと同じ実行環境で、正常動作するコードを記述しました。
下記をご確認ください。
samplecode/gulpfile_mutiple_src.js at master · m-miyauchi/samplecode
https://github.com/m-miyauchi/samplecode/blob/master/gulpfile_mutiple_src.js
JS好きさんのコードには、2箇所の間違いがあります。
まず1つめは、議論になった処理対象ディレクトリの「中間ディレクトリのワイルドカード指定」です。
中間ディレクトリまでワイルドカード指定をしてしまうと、ワイルドカード指定ではgulp.watch()が反応しませんでした。ディレクトリは明示的に指定し、ワイルドカード指定を使うのは、対象ディレクトリにおけるファイル名称のみに限ったほうが良さそうです。
2つめは、gulp.watch()のタスク指定間違いです。gulp.watch()のタスク指定に、cssとしてありますが、このcssというタスク名称のタスクはコード上に存在しません。ですので、cssという名称のタスクを作成する必要があります。
コードは上記2点の問題を解消したものになっています。
何度もお忙しい中ありがとうございました。
一応下記でfinishまで行きました。
commentなどがうまくいくか今後試していきます。
理由は難しくてわかりませんが、JS＞nodejsと学ばないとわからないのでしょうね。
var gulp = require(‘gulp’);
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’);
var cssnext = require(‘postcss-cssnext’);
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(‘postcss-custom-properties’);
var customMedia = require(‘postcss-custom-media’);
// 処理対象ディレクトリ
/*** 中間ディレクトリをワイルドカード指定にした場合、watchの動作確認がとれませんでした ***/
//var targetDirectory = [‘src-before/*’, ‘src-before/*/*’, ‘src-before/*/*/*’];
var targetDirectory = [‘src-before/*’ , ‘src-before/*/*’ , ‘src-before/*/*/*’];
// 出力ファイルのディレクトリ維持のため、階層構造のベースとなるルートのディレクトリを指定
var baseDirectory = ‘src-before’;
// 出力先ディレクトリの指定
var outputDirectory = ‘dest-after’;
// 通常はタスクが1つの場合、defaultという名称のほうががタスク名称としてふさわしいと思います
gulp.task(‘css’, function () {
var plugins = [
postcssimport(),
cssnext(),
nested(),
calc(),
customProperties(),
customMedia()
//csswring() //Node.js v6.9.1では正常動作しない
];
return gulp.src(targetDirectory, { base : baseDirectory })
.pipe(postcss(plugins))
.pipe(gulp.dest(outputDirectory));
});
gulp.task(‘watch’, function() {
gulp.watch(targetDirectory, [‘css’]);
});
>> JS好きさん
上記コードで動作確認が取れたということで、良かったです。
Node.jsはJavaScriptをサーバサイド向けにAPIを拡張した環境なので、一部ブラウザ向けAPIを除いて、ほとんどのネイティヴのJavaScriptのAPIを持っています。
なので、Node.jsをやることはJavaScriptの勉強に十分につながります。もし、サーバサイド開発のほうが、JavaScriptの勉強が捗りそうであれば、一度Node.jsの勉強を始めてみてはいかがでしょうか？
一方、フロントエンドでは現環境において、多くのフレームワークの中から、技術選定をする必要性があり、初心者には学習の敷居が高くなっているという認識です。
前述のような理由もあり、サーバサイドのNode.jsから学習するほうが現環境だともしかしたら良いかもしれません。
Node.jsを学び出すときは、だいたいExpressというフレームワークを使うので、フレームワークも決まってくる上に、Web上に知見も多いので、勉強はしやすいと思いますよ。
//csswring() //Node.js v6.9.1では正常動作しない
上記はnodeを7系か6系の最新にしないと使えないのですね。
>> JS好きさん
こんばんは。
モジュールが動かない場合はNode.jsのバージョンもそうですが、まずはそのモジュールの動かし方が正しいかを確認すると良いと思います。
それから、Node.jsのバージョン差異で動かない場合は、バージョンを上げるというより、むしろ下げるケースのほうが多いと思います。
csswringについては、おそらくですが、上記の使用方法が間違っている可能性があります。ですので、コード中に「動かない」とコメントしましたが、正しくは「この記述では動かない」という事になります。
csswringについては、ご自身でトライしてみてください。
すいませんやはりcommentはうまくいきませんでした。
お返事いただいたばかりなので、お返事は来月で構いません。
・インストール
npm i –save-dev postcss postcss-comment
[email protected] C:\Users\use\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト
+– [email protected]
`– [email protected]
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: [email protected]
npm WARN [email protected] No description
npm WARN [email protected] No repository field.
・gulp watch
(node:9620) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
[17:51:04] Using gulpfile ~\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js
[17:51:04] Starting ‘watch’…
[17:51:04] Finished ‘watch’ after 65 ms
[17:51:14] Starting ‘css’…
[17:51:17] ‘css’ errored after 2.93 s
[17:51:17] TypeError: comment is not a function
at Gulp. (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\gulpfile.js:31:5)
at module.exports (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\lib\runTask.js:34:7)
at Gulp.Orchestrator._runTask (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:273:3)
at Gulp.Orchestrator._runStep (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:214:10)
at Gulp.Orchestrator.start (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\orchestrator\index.js:134:8)
at Gulp. (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gulp\index.js:36:18)
at Gaze. (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\glob-watcher\index.js:18:14)
at emitTwo (events.js:106:13)
at Gaze.emit (events.js:191:7)
at Gaze.emit (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:129:32)
at C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:415:16
at StatWatcher._pollers.(anonymous function) (C:\Users\usr\Desktop\images\gulp-folder\website\postcssで作業をする時のデフォルト\node_modules\gaze\lib\gaze.js:326:7)
at emitTwo (events.js:106:13)
at StatWatcher.emit (events.js:191:7)
at StatWatcher._handle.onchange (fs.js:1487:10)
・ソース
var gulp = require(‘gulp’);
var postcssimport = require(‘postcss-import’);
var postcss = require(‘gulp-postcss’);
var cssnext = require(‘postcss-cssnext’);
var nested = require(‘postcss-nested’);
var csswring = require(‘csswring’);
var calc = require(‘postcss-calc’);
var customProperties = require(‘postcss-custom-properties’);
var customMedia = require(‘postcss-custom-media’);
var comment = require(‘postcss-comment’);
// 処理対象ディレクトリ
/*** 中間ディレクトリをワイルドカード指定にした場合、watchの動作確認がとれませんでした ***/
//var targetDirectory = [‘src-before/*’, ‘src-before/*/*’, ‘src-before/*/*/*’];
var targetDirectory = [‘src-before/*’];
// 出力ファイルのディレクトリ維持のため、階層構造のベースとなるルートのディレクトリを指定
var baseDirectory = ‘src-before’;
// 出力先ディレクトリの指定
var outputDirectory = ‘dest-after’;
// 通常はタスクが1つの場合、defaultという名称のほうががタスク名称としてふさわしいと思います
gulp.task(‘css’, function () {
var plugins = [
postcssimport(),
cssnext(),
nested(),
calc(),
customProperties(),
customMedia(),
comment()
//csswring() //Node.js v6.9.1では正常動作しない
];
return gulp.src(targetDirectory, { base : baseDirectory })
.pipe(postcss(plugins))
.pipe(gulp.dest(outputDirectory));
});
gulp.task(‘watch’, function() {
gulp.watch(targetDirectory, [‘css’]);
});
ありがとうございました。
1.As parser
2.Hook require
とプラグインのサイトに記載があるので、両方とも記載が必要なのでしょうね。
おそらく下記のことでしょうね。やってみます。
1.プラグインの読み込みのことでしょうか？
2.はpipeで行う部分のことでしょうか？