情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

Jact：JavaScript フレームワーク理解支援のためのプレイグラウンド型ツール
中島 望1,a)柗本 真佑1,b)

楠本 真二1,c)

受付日 2019年10月18日, 採録日 2020年7月7日

概要：JavaScript フレームワークとは，Web のフロントエンド開発を効率化するための枠組みである．大規模な Web アプリケーションを開発する際にはフレームワークの使用が一般的であり，開発者は使用するフレームワークを適切に選択する必要がある．しかし，適切なフレームワークの選択は開発者にとって容易ではない．フレームワークは記法等の実装面および処理時間等の性能面でそれぞれ特徴がある．またフレームワークは日々新しく誕生しており，改良されたものが継続的にリリースされている．そのため，フレームワークの単純な比較情報がすぐに古くなってしまい，正しい特徴理解の妨げになる可能性がある．
そこで本研究では，フレームワークの特徴理解を支援するのためのプレイグラウンド型ツール Jact を提案
する．Jact は各フレームワークの記法と処理時間を，Web 開発における典型的なタスクをベースに比較す
る機能を提供している．プレイグラウンドという性質により，Jact はブラウザ上でのタスクの実行，およびソースコードの編集と共有が可能となる．さらに，利用者による比較のためのタスクとソースコードのサーバへの投稿も可能にしている．比較用のタスクとソースコードを利用者自身が登録することで，Jactは各フレームワークの実装面および性能面の情報を継続的に提供できる．またフレームワーク理解における Jact の効果を評価するために，被験者を用いた評価実験を行った．
キーワード：JavaScript フレームワーク，Web アプリケーション，プレイグラウンド

Jact: A Playground Tool
Supporting Comprehension of JavaScript Frameworks
Nozomi Nakajima1,a)Shinsuke Matsumoto1,b)

Shinji Kusumoto1,c)Received: October 18, 2019, Accepted: July 7, 2020

Abstract: JavaScript framework (in short, JSF) is a skeleton for improving the eﬃciency of Web front-end
development. JSFs are generally adopted to develop large-scale web applications. Selecting the most appropriate JSF from various JSFs is critical but diﬃcult to achieve. Diﬀerent JSFs have diﬀerent characteristics
in terms of coding and performance. Also, a novel JSF has been often developed, and existing JSFs havebeen updated frequently. Therefore, comparison information of JSFs can quickly become obsolete. Outdated information may hinder understanding of JSF characteristics. In this paper, we present a playgroundtool named Jact to support comprehension of individual JSF characteristics. Jact enables users to compare
grammar and runtime performances of each JSF based on typical tasks in web development. By the conceptof playground, users can freely execute, edit, and share source code in their web browsers. Furthermore,users can submit tasks and source code to the server. By registering tasks and source code written by users
themselves, Jact can continuously provide information relating to JSF. In order to evaluate the eﬀectivenessof Jact, we conducted a subject experiment with 13 participants.
Keywords: JavaScript framework, web application, playgroundc 2020 Information Processing Society of Japan⃝1605

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

1. はじめにより，多数の実行環境が想定される．JSF は実行環境によらず一様に動作させるための Polyfill *1 を含んで実装されWeb 周辺技術の進化および爆発的な需要の増加にともているため [14]，JSF の性能は実行環境によって異なるとない，Web アプリケーションは複雑化の一途をたどっていいう指摘も存在する [6]．比較時には各 JSF の実行環境にる [9]．この複雑化を回避し，開発効率や保守性を向上する

よる性能面の違いを把握する必要がある．

ために，JavaScript フレームワーク（以下，JSF）を用い

3 つ目は，情報入手の難しさである．Web 技術は成長がた Web 開発が広く行われている [6], [14]．JSF の具体例と早く [4], [8]，JSF だけでなく実行環境であるブラウザも頻しては Vue.js や Angular が知られている．

繁にアップデートが行われる [2]．たとえば Google を中心

各 JSF は MVC（Model-View-Controller）や MVVMに開発されている JSF の Angular は，2018 年 5 月にバー

（Model-View-ViewModel）といった様々なアーキテクチャ

ジョン 6.0.0 がリリースされた後，5 カ月後の 10 月にバーパターンを採用しており [13]，開発者は JSF のパターンにジョン 7.0.0 がリリースされている [1]．リリース時には基づいてアプリケーションを構造化する [7]．またアプリ

JSF の記法の変更やパフォーマンスの改善が行われること

ケーションの開発時に必要とされる機能があらかじめ関が多く，利用したい条件での情報を得ることは難しい．

数として用意されており，それらを利用することでソース

本稿では開発者に対する JSF の理解と選択の支援を目的

コードを簡略化できる [7], [14]．開発者は JSF を適用するとして，JSF を実装面および性能面で比較するプレイグラ

ことで，高品質なソースコードを効率的に開発できる．

ウンド型ツール Jact を提案する．Jact は 1 つ目の課題に

JSF の採用はアプリケーションの開発面では有益な反対応するためにソースコードの比較機能とプレイグラウン

面，パフォーマンスの低下や消費電力の増大といった実行

ドを，2 つ目の課題に対応するためにオンデマンドな処理面での負の効果が避けられない [11]．これは JSF 利用によ

時間計測機能を持つ．またプレイグラウンドによって JSF

り様々な機能が付与されることによる副作用といえる．そについての情報を共有可能にし，3 つ目の課題に対応する．

して適用する JSF の選択においては，プログラミング言語

なお，Jact は現在公開サーバにデプロイ済み*2 であり，実やパラダイムの選択と同様に正解は存在しない．開発する際に利用することが可能である．評価実験として Jact に

アプリケーションの特性や，開発者達の好み，スキル等のよる JSF の記法および処理時間の理解における有用性を評

条件に合うものを選ぶ必要がある [14]．また機能を提供す

価する被験者実験を行った．実験の結果，JSF の理解におるライブラリは特定の機能を別ライブラリと容易に差し替

いて Jact の利用が有効であることが確認できた．

えられるが，全体の構造を規定する JSF は開発途中での変更が容易ではない．よって高品質なソースコードと高機能なアプリケーションを実現するためには，JSF の実装面お2. 準備
2.1 プレイグラウンド

よび性能面の特徴を把握し，開発するアプリケーションに応じた適切な JSF の選択が重要である [7]．

ブラウザ上でソースコードの編集，実行および共有が可能なサービスをプレイグラウンドと呼ぶ．代表的な一方で適切な JSF の選択は容易ではない．JSF の選択を

JavaScript のプレイグラウンドとしては，JSFiddle *3 があ難しくする要因として，以下の点があげられる．1 つ目は，げられる．利用者は実行環境を準備する必要がないため，

JSF の選択肢の豊富さである．同じアーキテクチャパター

ソースコードの編集や動作確認をブラウザ上で手軽に行うンを採用している JSF が複数存在しているため，採用したことができる．また URL を経由してソースコードとそのいアーキテクチャパターンから 1 つの JSF を選び出すこと実行環境を共有することも可能である．

は難しい．たとえば MVVM というアーキテクチャパターンを採用している JSF には Vue.js や Knockout.js 等があ

2.2 JavaScript フレームワーク

げられる．同じアーキテクチャパターンを採用する JSF で

JavaScript フレームワーク（JSF）とは，Web のフロン

もそれぞれ記法は異なるため，比較時には各 JSF の記法のトエンド開発を効率化するために使用されるソースコー

違いを把握する必要がある．

ドの枠組みである．一般にソースコードに対して部分的に

2 つ目は，実行環境の多様さである．Web アプリケー

機能を付与するために利用されるライブラリとは異なり，ションの特性上，Google Chrome や Firefox といったブラ

フレームワークはソースコード全体に MVC 等のアーキテ

ウザ，スマートフォンや PC といったデバイスの組合せにクチャを付与する目的で利用されている [21]．JSF はアー
キテクチャパターンだけでなく，記法や利用できる関数に

1

a)
b)
c)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology,
Osaka University, Suita, Osaka, 565–0871, Japann-nakajm@ist.osaka-u.ac.jp
shinsuke@ist.osaka-u.ac.jp
kusumoto@ist.osaka-u.ac.jp

c 2020 Information Processing Society of Japan
⃝

*1
*2
*3

ブラウザ間の仕様の違いに対応するために埋め込まれるソース
コードを指す．
Jact のデモページ：http://13.231.18.92/
https://jsfiddle.net/

1606

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

それぞれ特徴がある．JSF の利用によってソースコードを構造化したり，あらかじめ定義されている様々な関数を利用したりすることができるため，コード品質の向上や開発の効率化が期待できる [14]．JSF の利用例として，同一の機能を実現する JavaScript のソースコードと Vue.js を用いたソースコードを図 1 に示す．図 1 は Web ページ内の文字列 “World” を “JS” に書き換えるソースコードである．Vue.js は MVVM というアーキテクチャパターンを採用している．MVVM は画面上の表示（以下，View）とア
プリケーションのデータ（以下，Model）を紐付ける．通常 JavaScript では View もしくは Model の一方が変更された際，もう一方に変更を反映させる処理が必要になる．

MVVM は View と Model の紐付けによって，変更の反映
処理が不要になる．これによって，開発者はインタラク
ティブなインタフェースの作成を容易に行うことができる．

図 1 同機能の実装に対する JSF の記法の違い

Fig. 1 Diﬀerence of implementation with and without JSF.

ても Web 技術の進化は早く [4], [8]，実装方法や性能の比較情報の寿命は短いといえる．実際に開発者が JSF の比2.3 フレームワーク選択における課題

較を行う際には比較情報が古くなっている場合が多く，自JSF の利用は開発者にとって様々なメリットがある一方分が利用したい条件での情報を得ることが難しい．そしてで，適切な JSF の選択は容易ではない [6], [7], [14]．JSF

JSF に関する古い情報を利用することが，間違った JSF のの選択における課題点として，以下の点があげられる．

性質理解につながる可能性もある．

2.3.1 P1 ：選択肢の豊富さ
JSF によって採用しているアーキテクチャパターンは様々であり，例として MVC や MVVM があげられる．同

3. 提案手法：Jact
3.1 概要じアーキテクチャパターンを採用している JSF は複数存

本稿では前章で述べた課題の解決を目的としたタスク

在するが，ソースコードの記法は JSF によって異なる．

ベースの JSF 理解支援ツール Jact を提案する．Jact はソー例として MVVM をアーキテクチャパターンに採用してスコードの比較，オンデマンドな処理時間計測，プレイグ

いる Vue.js と Knockout.js をあげる．図 1 に示したとおラウンドという 3 つの性質を持つ．また利用者は Jact かり，Vue.js では HTML タグで変数を囲んでいる．一方

らタスクおよびソースコードを投稿できる．投稿機能の実

Knockout.js では，HTML タグの属性に紐付けるデータを現のために，Jact はソースコードのテスト機能を持つ．こ明示する必要があり，Vue.js とは記法が異なる．このようれらの性質と課題 P1 〜P3 の対応を表 1 に示す．表の列に，開発者はアーキテクチャパターンを選択すれば JSF をは Jact の性質を，行は課題 P1 〜P3 を示す．Jact の利用決定できるのではなく，それぞれの JSF の記法を把握してによって JSF の実装面および性能面の特徴が比較可能に比較する必要がある．

なり，開発者の JSF の理解や選択に対する支援が期待で

2.3.2 P2 ：実行環境の多様さ

きる．

アプリケーションの処理性能は開発者，利用者どちらにも重要である [18]．特に Web アプリケーションは実行環

3.2 特徴境が使用するブラウザ，デバイスによって構成されるた

3.2.1 タスクベース

め，様々な環境で利用されることを考慮する必要がある．

Jact では JSF の実装面，性能面の比較をタスクという単

Gizas らの研究 [6] 等で示されるとおり，JSF の性能は実行位で実施する．ここでのタスクは Web アプリケーション

環境によって大きく異なる．

を実装する際に用いられる汎用的な機能を意味しており，

2.3.3 P3 ：情報入手の難しさ

DOM 操作や Ajax 通信等が該当する [6]．

JSF そのもの，そして実行環境であるブラウザも頻繁に

タスクベースの JSF 比較は，JSF の特徴を理解するといアップデートが行われる．JSF の 1 つである Angular はわう大きな目標を小さく分割し，段階的な JSF の理解を促す

ずか 5 カ月で新たにメジャーバージョンがリリースされ，狙いがある．短く簡潔なソースコードの方が，複雑なソー

新機能の追加やパフォーマンスの改善が行われている [1]．

スコードよりもプログラム理解においては有効であること

また Baysal らの研究 [2] によると，Google Chrome は 2 カを示す研究も存在する [19]．実際に，プログラミング言語

月半ごと，Firefox は 10 カ月ごとにメジャーバージョンがのドキュメントや教本には，単純な機能を実現するためのリリースされている．他のソフトウェア開発技術と比較し数行のソースコードが掲載されていることが多い．このよc 2020 Information Processing Society of Japan⃝1607

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

表 1 Jact の各性質と課題 P1 〜P3 の対応

Table 1 Features of Jact corresponding to the three problems.
性質

P1

ソースコード比較◯

処理時間計測プレイグラウンド

P2

P3

◯
◯

◯

利用者による投稿◯

ソースコードのテスト△*4

うに，JSF の全体像を把握するために最初から巨大で複雑なアプリケーションを提示されるよりも，アプリケーショ

図 2 Jact の利用の流れ

ンを分割し，機能単位でソースコードを提示される方が理Fig. 2 Architecture of Jact and its usage flow.

解の助けになると考えられる．また，簡単なソースコード
例をもとに記法を理解する手法は開発者にも用いられておコードの共有が可能だが，類似した機能の実装をまとめて

り [14]，実際の開発現場においても有効な手段だといえる．

表示する機能等は提供されていない．Jact では各タスクご

タスクの粒度については，単体テストの対象となるようとにソースコードを共有し，同じ条件下での JSF の比較をな単一の意味を持った処理を想定している．たとえば図 1可能にすることで，リアルタイムな JSF の情報を提供可能に示すような，特定の ID を持つ DOM 要素を選択し，そにする．

の要素の内部テキストを書き換える，というような処理が3.2.5 利用者による投稿該当する．この例では，DOM 選択と DOM 書き換えの 2

Jact のプレイグラウンド化を実現するための性質であつの操作が必要であり，手続き的に行うか（図 1 左），宣る．事前に定義されたタスクやソースコードのみでは，新言的に行うか（図 1 右）という 2 つの記法の差が明確に表しい情報への対応や十分な情報の提供は難しい．そこで，れている．フロントエンド開発はこのような小さな機能の登録されていないが開発時に必要となるタスクや，同じ組合せで実現される．よって，ある単一の機能がどのよう

JSF を用いた別のソースコード，そして別の JSF を用いたに実現されているかを複数 JSF 間で比較することにより，ソースコードの投稿を可能にした．利用者自身が情報を追各種 JSF の違いの理解支援が実現できると考えられる．

加できる性質により，新しい情報や不足している情報を補

3.2.2 ソースコードの比較

うことができる．

あるタスクを実装した各 JSF のソースコードを比較する

3.2.6 ソースコードのテストことで，課題 P1 ：選択肢の豊富さに対応する．ソースコー

ソースコードの投稿を実現するために，ソースコードのドを比較することで，JSF の実装面の特徴である記法を比テスト機能が追加されている．投稿されたソースコード

較できる．

が，タスクを実現するための条件を満たしているかテスト

3.2.3 オンデマンドな処理時間計測を行う．この機能により，タスクを実現するための条件をまた Jact は課題 P2 ：実行環境の多様さに対応するためすべて満たしたソースコードのみの登録を実現する．

に，各 JSF の性能面の比較を実現する処理時間計測機能を持つ．選択したタスクに登録されている各 JSF のソース

3.3 利用の流れ

コードを実行して処理時間をオンデマンドに計測し，グラ

Jact の利用の流れを図 2 に示す．Jact は 3 種類の利用

フで表示する．様々な環境で本機能を用いることで，JSF者を想定しており，利用者によって利用の流れは異なる．

の性能面の特徴である処理時間を比較できる．

JSF 検討者：Jact を利用することで自分が使用する JSF

3.2.4 プレイグラウンドを検討したり，JSF の特徴を把握する利用者である．

ソースコードの比較機能とともに，課題 P1 ：選択肢の豊JSF 検討者は図 2 において A1〜A6 の矢印で示される

富さに対応する性質である．JSF の理解においては，実際

ように，Jact に示されたタスクから自分の利用したいにソースコードを動作させることが有効である [14]．ツー

タスクを選択し，そのタスクを実現するソースコード

ルをプレイグラウンド化することでブラウザ上でのソースを比較できる．また処理時間計測を実行することで，コードの編集や動作確認が可能になり，JSF の理解を深め

自分の環境下での各 JSF の処理時間を計測できる．

ることができる．

タスク投稿者：Jact に用意されていないタスクを追加で投Jact のプレイグラウンド化は，課題 P3 ：情報入手の難稿する利用者である．タスク投稿者は図 2 においてしさにも有効である．既存のプレイグラウンドではソース

B1，B2 の矢印で示されるように，タスクの情報を Jact*4

ソースコードのテストは利用者の投稿を実現するための機能であり，直接的に P3 に対応しているわけではない．

c 2020 Information Processing Society of Japan⃝に投稿する．
ソースコード投稿者：Jact で用意されているタスクに対

1608

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

して，自作のソースコードを投稿する利用者である．

表 2

Jact で使用されるタスクの例

ソースコード投稿者は図 2 において C1〜C4 の矢印でTable 2 Examples of typical tasks used in Jact.

示されるように，自作のソースコードを Jact に送信す

タスクカテゴリ

タスク名
テキストの変更

る．ソースコードに対してテストが行われ，成功すればソースコードとして登録される．またテストの結果

DOM 操作がどちらであっても，投稿者に通知される．

複数テキストの色の一括変更
クラスの追加クラスの削除

4. 実装

Ajax 通信4.1 概要

コールバック

Jact は JavaScript によって実装された Web アプリケー

JSON の取得
JSON の送信
取得データによるページの書き換え
入力のバリデーション

ションである．ユーザインタフェースの実現のために，

Vue.js を使用している．またエディタのシンタックスハ
イライトのために CodeMirror を使用している．Jact はREST API を経由してサーバからデータベースに保存さて計測を行った．

( 2 ) iframe のソースを API から取得
iframe の src 属性に URL を指定することで，当該フれたタスク，ソースコードおよびテストの情報を取得してレーム内に Web ページを埋め込むことができる．Jact

いる．API サーバには Node.js を，REST API の作成にはでは REST API を使用することでソースコードが取得

Node.js のフレームワークである Express を使用している．

できるように設計しているため，その URL を iframe

タスクおよびソースコードの情報を保持するデータベース
として MongoDB を使用している．開発期間は約 6 カ月，
コード行数は約 1,200 行である．

の src 属性に指定している．

( 3 ) 監視対象の DOM 要素を指定
イベントの発火による DOM 要素の変更を検知する
ために，MutationObserver *5 を用いた．MutationOb-

4.2 ソースコード比較

server を利用するための準備として，変更を監視すべ

図 3 に Jact のソースコード比較画面を示す．JSF 検討
者は図 3 に示される画面でソースコードの比較を行う．画
面は左側のバーと右側のエリアに分割されている．左側のバーではタスクおよびソースコードの選択，タスク投稿画面への遷移が可能である．右側の 5 分割されたエリアで

き DOM 要素を指定する．

( 4 ) 計測を開始
計測開始時の時間を記録し，イベントを発火する．

( 5 ) DOM 要素の変更を検知
イベント発火による DOM 要素の変更が検知された時は，それぞれ選択したソースコードの表示，選択したソー間を記録する．計測開始時間との差分を取り，処理時

スコードのコピーや投稿用ソースコードの編集，ソース
コードのプレビュー，テスト情報の確認・実行，処理時間
計測情報の確認・実行が可能である．

間を記録する．

( 6 ) 100 回の処理時間を合算( 3 )〜( 5 ) を 100 回直列実行し，処理時間を合算する．

Jact に登録される典型的なタスクの例を表 2 にあげる．
表 2 にあげられる DOM 操作や Ajax 通信，コールバック
は，Web フロントエンド開発における基本的な操作である．タスクを基本的な操作に設定することで，開発者は自分が実現したい機能に近いタスクを比較できる．

4.3 処理時間計測
処理時間計測時には，JSF 検討者が選択したタスクに対して各ソースコードがイベント発火から処理を完了するまでに要する時間を計測する．各ソースコードはそれぞれ100 回実行され，100 回分の処理時間を合計して出力する．
処理時間計測は，iframe と REST API を用いて各ソース
コードごとに以下の手順で行われる．

以上の手順をタスクに登録されたすべてのソースコード
に対して直列実行する．すべてのソースコードの計測が終了したら，グラフで表示する．計測結果の表示画面を図 4に示す．計測結果の表示画面では計測したタスク名，各
ソースコードの処理時間のグラフ，実行環境が表示される．

4.4 タスクの投稿
タスクの投稿時にはタスクの情報としてタスク名，投稿者名，サンプルのソースコードとその名称の 4 つの基本
項目が必要になる．それらの基本的な情報に加え，ソース
コードのテストを行うための以下の情報も要求される．

Pre：ページ上の要素のうち，変更のターゲットとなる
DOM 要素の初期状態を表す．ソースコードの振舞い( 1 ) iframe を 100 個生成を確認する際の事前条件に該当する．

同じ iframe を使用して実験を行う場合，キャッシュが適用されて正しく計測できない可能性がある．これを回避するために 100 回それぞれ別の iframe を利用し

c 2020 Information Processing Society of Japan⃝*5

JavaScript に用意されている API の 1 つで，監視対象とした
DOM 要素が変更されたときに指定したコールバック関数を実行することができる．

1609

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

図 3

ソースコード比較画面

Fig. 3 Screenshot of Jact.

図 4 処理時間計測結果の表示画面

Fig. 4 Screenshot of the result of runtime performancemeasurement.

図 5 タスクの登録画面

Fig. 5 Screenshot of the task registration form.

Trigger：ボタンのクリック等，ソースコードにおける
JavaScript イベントの発火方法を指す．

ソースコードとしてテキストで指定する．よって，Jact をPost：イベント発火後のターゲットの期待値を指す．ソー

通じて実行されるタスクの処理に限らず，Jact 自体が提供

スコードの振舞いを確認する際の事後条件に該当する．

するタスクのテスト処理自体も JavaScript で実行される．

タスク投稿者は 4 つの基本項目と 3 つのテスト項目を送信

これはプレイグラウンドの考えに基づいた実装であり，すすることで，タスクを投稿できる．

べての振舞いがブラウザ上で実現されるため，高い可搬性

具体的なタスクの登録画面を図 5 に，タスク定義のを持つシステムの提供が可能となる．また，プレイグラウ

JSON データ構造を図 6 に示す．この例は図 1 の DOM

ンドという性質から，cookie や localStorage，ページ遷移，書き換えを題材としている．すべての定義項目の要素はテ

サーバ通信といったブラウザ上で実現可能な機能もタスク

キスト形式で指定できる．サンプルソースコードやテス

内で利用することができる．

ト項目等の処理にかかわる項目に関しても，JavaScript のc 2020 Information Processing Society of Japan⃝1610

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)は成功となる．一方でも false となった場合や，イベント
が正しく発火されなかった場合にはテストは失敗となる．

5. 評価実験
5.1 概要本実験の目的は，JSF の記法と処理時間の理解において，Jact がどの程度有用であるかを確認することである．このために，被験者に実際に Jact を利用してもらい，各 JSFの記法の違い，およびそれらの処理時間の違いについてどの程度正しく理解できるかを確認する．また Jact のユー
ザビリティを確認するために，Jact を使用した印象やコメントを収集する．JSF の特徴把握のためのタスクには，著者らが作成した 4 つのタスクを利用する．理解対象のJSF としては jQuery と Vue.js の 2 つを採用する．jQueryの採用理由は利用率の高さである．jQuery は世界中の全サイトのうち 74%で利用されており，非常に利用率の高い

JSF *6 といえる．また Vue.js は開発者からの関心度が最も
図 6 タスク定義のデータ構造

高い JSF として採用している．Vue.js の GitHub リポジ

Fig. 6 Data structure of task definition.

トリは現在，JSF のなかで最も多くのスターを獲得している [3]．本実験では 2 つの JSF の他に，JSF を利用しない

4.5 ソースコードの投稿
ソースコードの投稿時には，後に記述するテストが実行

JavaScript のみの実装（以降，vanilla）を JSF 比較の基準として用いる．

される．テストに成功した際にはモーダルウィンドウを表示し，登録するソースコード名，ソースコードの特徴を示

5.2 被験者すタグ，投稿者名を要求する．登録ボタンを押すとソース

被験者は大阪大学大学院情報科学研究科に所属する修コードと入力された情報を登録し，ソースコード一覧に反士の学生 9 名，同研究科所属の教員 1 名，大阪大学基礎

映する．

工学部の学部生 3 名の計 13 名を対象とした．被験者のJavaScript，jQuery および Vue.js の使用経験を図 7 に示
4.6 ソースコードのテスト

す．被験者のうち 5 名は JavaScript を使用した経験がな

ソースコードの投稿機能を実現するためにソースコード

い．また半数の被験者は jQuery および Vue.js を使用したのテスト機能が実装されている．ソースコードのテスト時経験がない．本実験では言語の使用経験がない被験者でもには，各タスクに登録された Pre，Trigger，Post を使用

ソースコードを理解できるよう，タスクを基本文法レベル

する．テストには処理時間計測時と同様に iframe を使用に設定し，ソースコード中にはコメントを挿入した．

する．テストの手順は以下のとおりである．

( 1 ) iframe の更新

5.3 登録タスク
本実験用に以下の 4 つのタスクを Jact に登録する．

テストを実行するために，iframe のソースコードをテ
スト対象のソースコードに変更しておく．

要素の選択：HTML 中の DOM 要素を id 名，および class
名で指定するタスク．

( 2 ) iframe に対して Pre を実行
Pre として登録されたソースコードを実行し，ソース

単一要素の書き換え：HTML 中の DOM 要素を id 名で指定し，単一の DOM 要素を書き換えるタスク．

コードの事前条件を確認する．

( 3 ) iframe に対して Trigger を実行

複数要素の書き換え：HTML 中の DOM 要素を class 名でソースコード内のイベントを発火させるために，Trig-

指定し，すべての DOM 要素を書き換えるタスク．

ger として登録されたソースコードを iframe に対してイベントの割り当て：ボタン要素を指定し，クリックイベ
ントおよびマウスオーバイベントの割当てを行うタス

実行する．

( 4 ) iframe に対して Post を実行
Post として登録されたソースコードを実行し，ソース
コードの事後条件を確認する．

( 2 ) と ( 4 ) の実行に対して true が得られた場合，テスト

c 2020 Information Processing Society of Japan⃝*6

jQuery は厳密には JSF ではなくライブラリであるが，本実験では JSF の 1 つとして採用する．なお，JavaScript においてはライブラリとフレームワークの境界が曖昧だという指摘も存在す
る [21]．

1611

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

ような感想を抱いたかを記述式で回答する．

5.4.3 ユーザビリティ評価
上記 2 つの実験課題の実施後，被験者に以下のアンケー
トを答えてもらい，Jact の各機能および全体の有用性を 5段階評価で確認する．

• ソースコードの比較機能により，JSF の記法の違いを理解できたか• プレイグラウンド機能は JSF の記法の理解に有用か• 処理時間計測機能により，JSF の処理時間の違いを理
図 7

被験者の JavaScript 使用経験

Fig. 7 Usage experience of participants.

解できたか• 処理時間計測のオンデマンド性は JSF の処理時間の理解に有用か

ク．このタスクは上記 3 つのタスクの内容を含む．

• Jact は JSF の理解に有用か
また，その他 Jact に対する意見を自由記述で確認する．

5.4 実験課題
実験課題として各 JSF（jQuery と Vue.js）に対して，ソースコードの記法の理解，および処理時間の理解の 2 つを行う．

5.4.1 記法の理解実験
5.3 節に述べた 4 つのタスクについて，Jact のソースコー

5.5 実験結果
5.5.1 記法の理解
記法の理解実験で被験者から得られた回答を抜粋する．
各タスクへの回答のうち，jQuery については以下のような回答を得られた．

ド比較機能とプレイグラウンドを利用する．vanilla と比較

対象要素の書き換えは vanilla では代入だが，jQuery では

して jQuery，Vue.js の記法にどのような特徴が見られたか関数の呼び出しによる書き換えとなっている．

を各タスクごとに記述式で回答する．

5.4.2 処理時間の理解実験
Jact が提供する性能比較機能により，被験者が各 JSF の性能差を正しく理解できるかを確かめる．実験では vanilla

jQuery では$を使うことで指定した ID(クラス) をもつ
DOM 要素を取得できる．$の引数が “.” から始まる時はクラス，“#” から始まる時は ID になる．

を基準として，jQuery，Vue.js の処理時間にどのような特徴が見られるか，Jact の処理時間計測機能を用いて調査しvanilla は “eventListener” を追加している．引数の 1 つ

回答する．5.3 節に述べたイベントの割当てタスクの処理

目がどんなアクションかで，2 つ目が 1 つ目のアクション

時間を 2 種類以上のブラウザで計測し，以下の観点でどのが行われたときの処理 (関数) である．jQuery ではこのアような特徴が見られたかを記述式で回答する．

クションごとにメソッドが定義されているため，引数と• vanilla と比較した各 JSF の特徴

して処理内容を与えることでアクションを追加できる．

• 各 JSF のバージョンごとの特徴• 記法/API ごとの特徴

これらの回答から，jQuery の特徴である$関数による• ブラウザごとの特徴

DOM 要素の指定方法を理解できていることが分かる．ま

各観点には，著者らが事前に確認しておいた性能差特徴のた DOM 要素の操作やイベントの割当てを関数で行うとい

解（期待値）が設けられている．たとえば，vanilla とのう vanilla との違いに言及する回答が多く見られた．

比較においては，どの JSF でも vanilla と比較して 10%〜200%の速度低下が見られる，という解釈が解となる．ま次に Vue.js の記法の特徴について得られた回答を，以下に抜粋する．

た，JSF バージョンの比較においては，Vue.js の ver.2.5 とVue.js ではインスタンス生成時にメソッドを定義するこ

ver.2.6 を比較すると，ver2.6 で 200%の速度改善が確認でとができる．定義や処理を別々に宣言することで，見やきる．これは Vue.js の ver.2.6 で適用された，レンダリン

すくなると思った．

グ処理のパフォーマンス改善*7 によるものである．これら
解と被験者らの回答を比較し，その一致率を性能理解の正Vue.js では，HTML において同じデータを参照する部分答率とする．また，これら 4 つの観点に注目した処理時間に同じプレースホルダーを書けば，対応するプレースホ

計測結果をふまえ，JSF の処理時間の特徴についてにどのルダーのデータに再代入するだけでその部分が同時に書*7き換えられる．

https://medium.com/the-vue-point/vue-2-6-released66aa6c8e785e

c 2020 Information Processing Society of Japan⃝1612

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

Vue.js では対象要素を事前に「変数」としてバインディ
ングを行う．コンポーネント内の data でその値に代入を行うことで書き換えを行う．

Vue.js については，インスタンスの HTML との紐付けが必要であるという Vue.js の持つ特徴への言及が見られた．また，インスタンスにおいて変数やメソッドを宣言できることに着目した被験者も複数いたことが分かる．

5.5.2 処理時間の理解
処理時間の理解実験における，各比較の観点での正答率の結果は以下のとおりとなった．vanilla と比較した各 JSFの特徴：100%，各 JSF のバージョンごとの特徴：92%，記法/API ごとの特徴：85%，ブラウザごとの特徴：100%．
どの観点においても 80%以上の正答率が得られており，被験者が正しく性能差を理解しているといえる．いくつか誤答も見受けられたが，いずれの誤答も 10%程度の性能差を，差ありととらえるか否かという解釈の違いによるものであった．さらに，本実験で得られた自然言語での感想を以下に抜粋する．
全く同じ機能を実装しているのにも関わらず，これだけの差があるということは知らなかった．また，Web アプリを開発する際にこれらのことを考えるのは面倒だと思っ
図 8 アンケート結果

た．その点で，Jact はその性能差を目で見て気軽に確認できるので良いツールだと思った．

Fig. 8 Results of usability questionnaire.

数倍程度も差があるとは想像していなかった．処理速度

記法の差と性能差がこんなに手軽に知れるのは非常に良を重視するようなプロジェクトでは，使用する JSF の選

い．実際に使用したい．

択も重要になると感じた．
登録されているコードと自分のコードを比較しながら作簡潔に書けるもの程，実行処理にかかる時間が長くなる
印象を受けた．

処理時間計測によって JSF の選択に対しての性能の認識が変わったという感想を得られており，被験者は各 JSF の処理時間に大きな差があることを理解できたといえる．その処理時間の差は記法の簡潔さとのトレードオフであることに気づいた被験者もいた．

業できるのが非常に便利そうだと感じた．処理時間計測
は性能を知るのにすごく便利な機能だと感じた．

一方で，Jact の改善点に関する意見も見受けられた．
差分がないところは色を薄くする等，JSF 間のソースコー
ドの差分を強調表示してほしい．

AltJS（TypeScript 等のコンパイルが必要な JavaScriptの代替言語）にも対応してほしい．

5.5.3 ユーザビリティ評価
ユーザビリティ評価のアンケートによって得られた Jact
に対する意見を図 8 に示す．この結果から，本実験におい5.6 考察て与えたタスクにおいて Jact を利用することで，JSF の被験者実験の結果より，Jact の使用は JSF の理解に有用

記法および処理時間の特徴を理解できたことが分かる．まであると結論づけることができる．記法と処理時間の差をた，記法および処理時間の理解において Jact のソースコー

知る手段としての手軽さへの言及が複数見られた．また，

ド比較，処理時間計測，プレイグラウンドは有用であるこ

実際の開発時に利用したいとの声も得られたことから JSFとが分かる．Jact が JSF の理解に有用であると感じた被の利用を検討する開発者の利用も期待できると考えられる．

験者は 13 名中 12 名であった．

実際の開発現場では，本実験での設定とは異なり，最終

Jact に対する意見として収集した自由記述の回答を抜粋

的に導入する JSF を検討して選択する必要がある．そのする．好意的な意見としては，以下のような意見があった．

際，記法の分かりやすさや導入しやすさや処理時間等，優c 2020 Information Processing Society of Japan⃝1613

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

先すべき特徴は場合によって異なるうえに，表 2 に示した

表 3 Jact と類似ツールの比較

ような，DOM 操作や Ajax 通信といった本実験のタスクよ

Table 3 Features of Jact corresponding to the three problems.

りも複雑な実装が要求される．そのような状況下では JSF

性質

Jact

TodoMVC

js-fw-benchの性質が開発するソフトウェアに大きく影響するうえ，比ソースコード比較◯◯◯

較したい条件での記法と性能の情報が必要になる．よってJact のソースコード比較機能や処理時間計測機能の手軽さ
が，さらに JSF の理解に効果を発揮できると考えられる．

処理時間計測◯プレイグラウンド◯◯◯

利用者による投稿◯△*11

ソースコードのテスト

◯

△*11

6. 妥当性の脅威
本研究で実施した評価実験の被験者のうち，半分以上ケーションの実装に対する JSF の性能差を比較している．

が JSF を利用した経験がなかった．Jact は JavaScript や

このほかにも，セキュリティ面での JSF の比較研究 [15] やJSF の利用経験を持つ開発者からの利用を想定している．

特定の JSF の性質についての調査研究 [16], [17] が実施さ開発者による Jact の利用効果および評価は，評価実験のれているが，継続的に JSF の情報を収集し，提供すること

結果とは異なる可能性がある．

を目的とした研究は我々の知る限り存在しない．

また，評価実験による Jact の評価はすべて被験者からの

JSF の比較によって JSF の理解支援を試みるツール

回答に基づくものであり，その内容は被験者の主観に強くも複数存在している，既存の JSF 比較ツールとしては，依存している．そのため，設問内容や回答の方法等によっ

TodoMVC *9 や js-framework-benchmark *10 があげられる．

て実験結果が変わる可能性がある．理解に要する時間の計

TodoMVC は，様々な JSF を用いて実装した Todo 管理ア

測や，回答内容の正誤に基づく評価といった，定量的かつプリケーションを提供している．ホームページではアプリ

客観的な制御実験による Jact の評価は今後の課題である．

ケーションを実際に利用可能で，ソースコードは GitHub

7. 関連研究

リポジトリにて公開されている．js-framework-benchmark
は，JSF の性能を測定できるベンチマークである．GitHub

本研究で採用した典型的なタスクに基づく比較という手

リポジトリで公開されているソースコードをクローンし，法は，プログラミング言語間やアプリケーション間の比較

ローカル環境で実行することで，実行環境下での各 JSF のでも広く用いられている [5], [10], [12]．これらの言語比較

性能情報を入手できる．これら JSF 理解支援を目的とすにおいては，同じタスクの様々な言語での実装を公開してるツールと提案手法の比較を表 3 に示す．Jact はこれら

いる Rosetta Code *8 が利用されている．このようなタスのツールにはないプレイグラウンドを性質に加えており，

クに基づいた比較は，対象の特徴を俯瞰的に列挙して比較

ブラウザ上で動作させられる．そのため，環境構築をせずするトップダウンな方法とは異なり，具体的なコードの視にソースコードの編集や動作確認ができるほか，処理時間点から比較するボトムアップな方法ととらえられる．本研の計測も様々なブラウザで容易に試すことができる．そし究で提案する Jact はボトムアップな JSF の比較支援技術て利用者からの投稿によって JSF の情報を随時取り入れ，であり，トップダウンな比較情報の補完として活用できる

JSF の比較に使用できる．また比較の基準を汎用的なタス

効果的な方法であるといえる．

クとし，小さな単位での比較とすることで，ボトムアップ

本研究と同様，JSF の理解や選択の支援を目的とした研な JSF の性質理解が可能になっているほか，さらに複雑な究もいくつか行われている．Pano らの研究では，JSF の機能を実装する際の拡張を容易にしている．

選択における意思決定要因について調査している [14]．こ8. おわりにの調査によって，JSF のドキュメントには一般的なタスクを実装するためのコード例を含むべきであることや，開発

本研究では JSF の選択における課題を解決するために，者達が実際に小さなタスクを実現するコード例を作成し，JSF の記法および処理時間を比較し，開発者の JSF 理解を

JSF の理解に役立てていることが明らかになっている．本

支援するプレイグラウンド型ツール Jact を提案した．ま

研究では，そのような開発者達が利用している実用的な手た評価実験として Jact を用いた JSF の理解支援に関する法を JSF の比較に採用している．また JSF の比較は，性被験者実験を行った．実験では，JSF の記法および処理時能の観点でも行われている [6], [20]．Gizas らの研究 [6] で間の特徴把握のタスクに対して Jact が有効であることをは，JSF のソフトウェアメトリクスや実行時パフォーマン

示した．また複数の被験者から Jact に好意的な意見を得スを計測することで，JSF を比較している．Zochniak らのることができた．

研究 [20] では，後述する TodoMVC を用いて，同じアプリ*9

http://todomvc.com/
https://github.com/krausest/js-framework-benchmark*11 GitHub へのコミット push により投稿自体は可能だが専用の UIは設けられていない．
*10*8

http://www.rosettacode.org

c 2020 Information Processing Society of Japan⃝

1614

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

今後の課題として，利用者による投稿機能の評価があげ[14]

られる．本稿で実施した JSF 理解の実験は JavaScript の利用経験がなくても取り組める内容であったが，投稿機能の利用には JavaScript や JSF の利用経験が必要となる．

[15]

今回の実験で得られた回答をもとに被験者を決定し，投稿機能に対しても評価を行うことで，投稿機能の有用性に関する評価や改善点についての意見を得ることができる．

[16]

謝辞 本研究の一部は，日本学術振興会科学研究費補助
金基盤研究（B）（課題番号：18H03222）の助成を得て行

[17]

われた．
参考文献
[1]
[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

Angular versioning and releases, available from ⟨https://
angular.io/guide/releases⟩ (accessed 2019-07-22).
Baysal, O., Davis, I. and Godfrey, M.W.: A Tale of
Two Browsers, Proc. 8th Working Conference on Mining Software Repositories, pp.238–241 (2011).
Collection: Front-end JavaScript frameworks, available from ⟨https://github.com/collections/front-endjavascript-frameworks⟩ (accessed at 2019/7/22).
Deshpande, Y. and Hansen, S.: Web engineering: Creating a discipline among disciplines, IEEE MultiMedia,
Vol.8, No.2, pp.82–87 (2001).
Georgiou, S., Kechagia, M., Louridas, P. and Spinellis,
D.: What Are Your Programming Language’s Energydelay Implications?, Proc. 15th International Conference on Mining Software Repositories, pp.303–313(2018).
Gizas, A., Christodoulou, S. and Papatheodorou, T.:
Comparative Evaluation of JavaScript Frameworks,
Proc. International Conference on World Wide Web,
pp.513–514 (2012).
Graziotin, D. and Abrahamsson, P.: Making Sense Outof a Jungle of JavaScript Frameworks, Proc. ProductFocused Software Process Improvement, pp.334–337(2013).
Lei, K., Ma, Y. and Tan, Z.: Performance Comparison and Evaluation of Web Development Technologies
in PHP, Python, and Node.js, IEEE 17th International
Conference on Computational Science and Engineering, pp.661–668 (2014).
Murugesan, S., Deshpande, Y., Hansen, S. and Ginige,
A.: Web Engineering: A New Discipline for Development of Web-Based Systems, pp.3–13, Springer Berlin
Heidelberg (2001).
Nanz, S. and Furia, C.A.: A Comparative Study of Programming Languages in Rosetta Code, Proc. 37th International Conference on Software Engineering, pp.778–
788 (2015).
Obbink, N.G., Malavolta, I., Scoccia, G.L. and Lago, P.:
An Extensible Approach for Taming the Challenges of
JavaScript Dead Code Elimination, IEEE 25th International Conference on Software Analysis, Evolution andReengineering, pp.291–401 (2018).
Oliveira, W., Oliveira, R. and Castor, F.: A Study on the
Energy Consumption of Android App Development Approaches, Proc. 14th International Conference on Mining Software Repositories, pp.42–52 (2017).
Osmani, A.: Learning JavaScript Design Patterns – A
JavaScript and jQuery Developer’s Guide, O’Reilly Media (2012).

c 2020 Information Processing Society of Japan
⃝

[18]

[19]

[20]

[21]

Pano, A., Graziotin, D. and Abrahamsson, P.: Factors and actors leading to the adoption of a JavaScript
framework, Journal on Empirical Software Engineering,
Vol.23, No.6, pp.3503–3534 (2018).
Peguero, K., Zhang, N. and Cheng, X.: An Empirical Study of the Framework Impact on the Security of
JavaScript Web Applications, Companion Proc. Web
Conference 2018, pp.753–758 (2018).
Ramos, M., Valente, M.T. and Terra, R.: AngularJS
Performance: A Survey Study, IEEE Software, Vol.35,
No.2, pp.72–79 (2018).
Ramos, M., Valente, M.T., Terra, R. and Santos, G.:
AngularJS in the Wild: A Survey with 460 Developers,
Proc. 7th International Workshop on Evaluation andUsability of Programming Languages and Tools, pp.9–
16 (2016).
Ratanaworabhan, P., Livshits, B. and Zorn, B.G.: JSMeter: Comparing the Behavior of JavaScript Benchmarks
with Real Web Applications, Proc. 2010 USENIX Conference on Web Application Development, p.3 (2010).
Sillito, J., Maurer, F., Nasehi, S.M. and Burns, C.: What
Makes a Good Code Example?: A Study of Programming Q&A in StackOverflow, Proc. 2012 IEEE International Conference on Software Maintenance (ICSM ),pp.25–34 (2012).
Zochniak, A. and Walkowiak, T.: Performance Comparison of Observer Design Pattern Implementations in
JavaScript, Reliability and Statistics in Transportation
and Communication, Springer International Publishing,pp.466–475 (2018).
掌田津耶乃：JavaScript フレームワーク入門，秀和シス
テム (2016).

中島 望
2018 年大阪大学基礎工学部情報科学科中退．2020 年同大学大学院情報科
学研究科コンピュータサイエンス専攻
博士前期課程修了．在学時プログラム
理解やソースコード分析に関する研究に従事．

柗本 真佑 （正会員）2010 年奈良先端科学技術大学院大学
博士後期課程修了．同年神戸大学大学院システム情報学研究科特命助教．

2016 年大阪大学大学院情報科学研究科助教．博士（工学）．エンピリカル
ソフトウェア工学の研究に従事．

1615

情報処理学会論文誌

Vol.61 No.10 1605–1616 (Oct. 2020)

楠本 真二 （正会員）
1988 年 大 阪 大 学 基 礎 工 学 部 卒 業 ．
1991 年同大学大学院博士課程中退．
同年同大学基礎工学部助手．1996 年
同講師．1999 年同助教授．2002 年同大学大学院情報科学研究科助教授．

2005 年同教授．博士（工学）．ソフト
ウェアの生産性や品質の定量的評価に関する研究に従事．
電子情報通信学会，IEEE，JFPUG，PM 学会，ソフトウェ
ア技術者協会各会員．

c 2020 Information Processing Society of Japan⃝

1616