普段思ったことや、雑記。

Menu & Search

Meteorアプリケーション(Blaze)の運用をしてみてハマったこと

2017年4月14日

※前提…Meteor v1.3.3

フロントエンドのフレームワークにBlazeを選んだ場合、headタグのプロパティの動的なハンドリングに悩まされる

Blazeは、基本的にはHTMLでいうbodyタグの部分を管理し、標準的な記法ではheadタグはほとんど意識しない。もちろん明示的にheadタグを記述することもでき、静的なheadタグの記述についてはBlazeは対応はしている。しかし、動的にheadタグをハンドリングする場合は状況が変わってくる。Blazeは動的なheadタグのハンドリングはそれ単体ではおこなうことができず、パッケージを別途追加して、機能をフォローしてやる必要がある。

基本的には、インターネット上に公開を前提とする製品レベルのWebアプリケーションを作る際、metaタグのハンドリングは、サーバサイドのテンプレートエンジンを利用するなどし、意図するように操作を行いたい。だが、Blazeについては仕様上headタグの扱いが致命的に弱く、それ単体ではheadタグの動的なハンドリングができないことが開発中に判明した。headタグを明示的に記述し、ヘルパー関数を使って動的に値をセットしようとしてもできないのだ。この致命的な仕様により、例えばSEO的観点で正しい記述内容だったり、SNSへの遡及を促すボタンの設置が難航した(※解決はしそうだが、意図するような挙動にならず、リプレースを検討した)。

Blazeでmetaタグをハンドリングするには環境に応じてパッケージを追加してやる

見出しの通りだが、Blazeでmetaタグをハンドリングする場合、別途パッケージを追加してやる必要がある。例えば、routerのレイヤーでハンドリングを行う場合、

iron router ならms-seo、flow router ならMeteor-flow-router-metaのようになっている。テンプレートなら、blaze-metaパッケージだろう。パッケージを紹介しておいてなんだが、Meteor界隈はパッケージのメンテナンス頻度があまりよくない気がしている。前述のパッケージがメンテナンスされているか、duplicatedになっていないかは使用前に確認を推奨する。

たかが、headタグ、されどheadタグ。SEOを考える必要があるアプリケーションであるのなら、Blaze以外のほうがよさそう

Blazeは当初Meteor公式が開発し、推していたフレームワークでもある。当ブログでも、Meteor v1.2世代のBlazeベースの公式チュートリアルを紹介していた。しかし、本投稿で取り上げているSEOの問題もあるが、現状のBlazeを取り巻く状況が変わってきているので、紹介したい。

BlazeはMeteor公式から独立したが、人気はAngularやReactに圧倒的に劣る

Githubのスター数を見ると、BlazeAngular-meteorreact-meteorに圧倒的に差をつけられている。2017年4月13日現在のMeteorのフロントエンドフレームワークのスター数でいうと、下記のようになっている。

  1. Angular-meteor 2139
  2. react-meteor 997
  3. Blaze 306

BlazeはMeteor公式から独立したものの、Githubのスター数から見る注目の度合いでいうと、他フレームワークと比較して、かなり低いように思える。個人的な印象としては、公式から独立したというよりかは、よりマイナスな見方をしており、「公式から切り離された」という認識でいるのが正しいと思っている。理由は、今回のmetaタグのように、本来フレームワークが扱えるべき領域が当然のようにサポートされていない仕様であること(プラス、他にもこのような仕様がありそうと予想すること)。あとは、Githubのスター数から垣間見ることができるそもそもの人気の度合いの低さから、決して注目度が高いとはいえないと思ったからだ。

Meteorで製品レベルのアプリケーションや、しっかりしたアプリケーションを作ろうとする場合、Blazeを選択しないほうが良いのかもしれない

Blazeは学習コストの低さが魅力かもしれないが、後々変なところで苦労しそうな罠が待っているフレームワークと捉えている。最近のJavaScriptフレームワークは、本当にいろいろなフレームワークがあるし、開発が盛んである。Meteorに限ることなく、そのJavaScriptフレームワークの界隈をリードしているGoogleやFacebookがバックボーンであるAngularやReactなどのフレームワークと、突然パッと出てきたようなBlazeを比較するのは少し酷な話だったのかもしれない。Blazeは、実際にはMeteorの基本を理解するために、シンプルに実装してあるというフレームワークなだけで、製品の開発で使ってみて別段これといった機能面での優位性は感じなかった。Blazeの使い道としては、Meteorを理解するための道具として使う程度が個人的には良いのではないかと思っている。真面目にMeteorアプリケーションを構築しようとする人は、Blazeは積極的には選ぶ必要はあまりないのではないかと個人的には思っている。

Article Tags
mmiyauchi

プログラムを書きながらTranceを聴くのが良いですね。みなさんも聴いたほうがいいですよ、Trance。EDMよりハードトランスでしょ。

Related article
React Native開発のつらい点まとめ

React Native開発のつらい点まとめ

React Nati…

Meteorのブームが来るか来ないと言われれば、来ないと思ってしまった件

2016年秋頃から、…

DockerでJavaScriptシェル(Node.js実行環境)をつくる

JavaScript…

Discussion about this post

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Type your search keyword, and press enter to search