高橋操と申します
HTML5とはちょっと違うかもしれませんが
QRコードのデコードライブラリをJavascriptで作成しているのですが
ライブラリのようなものがないか探しています
多言語処理、Canvasでの画像処理、RS符号化などなど
多くのものがサーバー側に処理を投げている状況なのは
たぶんそういったものはサーバ側のライブラリを使いたいとかの制約なのかなぁと思ったりします
ライブラリのキャッシュ、オフライン処理を考えるとどうしてもJavaScriptで完結させたいと思っています
(いまはChromeExtension、jQueryから使えるようにしているので)
そうなると、lib~ようなライブラリのレベルがJSにも必要になるんじゃないのかなぁと思っています
CommonjsやNpmのような動きも今のところ存在くらいしか知りませんが
ちょっと見た感じだと表層のレイヤーのUtiltyくらいのものが多いのかなと感じます
なかなかまとまった情報を見つけられず、かつ今の状況で公開されているJSを信用してライブラリとして使ってよいものなのか...
仕事で使っているものも、そうでないものも年代的になのかメンテナンスされていない、サーバ閉鎖なんてケースも多いので・・・
HTML5+(CSS)+JavaScriptで出来ることが大幅に増えた分やりたいことも増えるはず?
大規模なプロジェクトも多数ある状況なので私が調べきれていないのだと思うので
(HTML5+CSS+)JavaScriptの情報をお持ちでしたらお教えください
よろしくお願いします
使ったことは無いのですが、「JSAN( http://openjsan.org/
)」のような、他の方がアップロードしたライブラリを簡単に開発中の環境にも配備できそうなものでしょうか。
webブラウザで実行するJavaScript用のライブラリリポジトリは、正直、「微妙」です。
読み込むライブラリ(JavaScriptファイル)のコード量や、サーバーへのリクエスト数がネックになって「閲覧者が体感するパフォーマンスに影響する」ため。
トリッキーな開発がラクになっても、閲覧がしんどいものになったのでは本末転倒ですよね。
結局、何か1つのフレームワークを選び、そのフレームワーク専用のプラグインを書いたり、他の方が書いたプラグインをそのまま利用させてもらうスタイルになっているのがブラウザで稼動するJavaScriptアプリケーションだと思います。
有名なフレームワークは、それぞれ独自のCDNサービスを提供していますし、CDNが許容されるなら、そのインストールはサーバーに配備しなおす必要もありません。
オフライン処理という言葉がでてきたので、ブラウザ側のJavaScriptについて書きましたが、ライブラリリポジトリよりも、フレームワーク+プラグインが正解だと思います。
一方で、CommonJSやNpm は、サーバー側JavaScript用途かなぁと。
自身で用意したサーバーに配備する必要がある場合、パッケージマネージャを利用して、ライブラリリポジトリから、依存関係も解決しながらインストール(FTPでのコピー作業)する形です。
Node.js では、GitHub をライブラリリポジトリとして利用している方が多いようです。
余談ですが、
O3Dで遊んでた頃、GoogleのClosure library をベースにしたAPI実装だったのですが、*.js
ファイルの配備方法は、名前空間(オブジェクト階層)に対応したディレクトリ階層とする規則でした。
また、開発基盤ともいえる base.js に実装された require() を活用して、高速に読み込む工夫もありました。
「ライブラリで個別のファイルにして管理したほうがラクだよね」という開発者寄りのフレームワークはGoogleのClosureかなぁと思います。ただ、これは随分古い話となりますので、Closure
Ribrary についてはあくまでも参考としてください。
2011年11月30日12:44 かずくん <kazu.kt...@gmail.com>:
> --
> このメールは Google グループのグループ「html5j.org」の登録者に送られています。
> このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
> このグループから退会するには、html5-developer...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/html5-developers-jp?hl=ja からこのグループにアクセスしてください。
>
On 11月30日, 午後1:19, Akitoshi Manabe <akitoshi.man...@gmail.com> wrote:
> はじめまして
> 眞鍋彰利と申します。
>
> 使ったことは無いのですが、「JSAN(http://openjsan.org/
> )」のような、他の方がアップロードしたライブラリを簡単に開発中の環境にも配備できそうなものでしょうか。
>
> webブラウザで実行するJavaScript用のライブラリリポジトリは、正直、「微妙」です。
> 読み込むライブラリ(JavaScriptファイル)のコード量や、サーバーへのリクエスト数がネックになって「閲覧者が体感するパフォーマンスに影響する」た め。
> トリッキーな開発がラクになっても、閲覧がしんどいものになったのでは本末転倒ですよね。
>
> 結局、何か1つのフレームワークを選び、そのフレームワーク専用のプラグインを書いたり、他の方が書いたプラグインをそのまま利用させてもらうスタイルになって いるのがブラウザで稼動するJavaScriptアプリケーションだと思います。
>
> 有名なフレームワークは、それぞれ独自のCDNサービスを提供していますし、CDNが許容されるなら、そのインストールはサーバーに配備しなおす必要もありませ ん。
>
> オフライン処理という言葉がでてきたので、ブラウザ側のJavaScriptについて書きましたが、ライブラリリポジトリよりも、フレームワーク+プラグインが 正解だと思います。
>
> 一方で、CommonJSやNpm は、サーバー側JavaScript用途かなぁと。
> 自身で用意したサーバーに配備する必要がある場合、パッケージマネージャを利用して、ライブラリリポジトリから、依存関係も解決しながらインストール(FTPで のコピー作業)する形です。
> Node.js では、GitHub をライブラリリポジトリとして利用している方が多いようです。
>
> 余談ですが、
> O3Dで遊んでた頃、GoogleのClosure library をベースにしたAPI実装だったのですが、*.js
> ファイルの配備方法は、名前空間(オブジェクト階層)に対応したディレクトリ階層とする規則でした。
> また、開発基盤ともいえる base.js に実装された require() を活用して、高速に読み込む工夫もありました。
>
> 「ライブラリで個別のファイルにして管理したほうがラクだよね」という開発者寄りのフレームワークはGoogleのClosureかなぁと思います。ただ、これ は随分古い話となりますので、Closure
> Ribrary についてはあくまでも参考としてください。
>
> 2011年11月30日12:44 かずくん <kazu.ktz.tam...@gmail.com>: