ジーンコードの変換は、更新ではなく、再構成です。
HTMLやXMLの変換に利用されるDOM APIによる変換処理（JQueryもその仲間）は、元の木構造の特定の要素を外したり追加したりして、元の木構造自体を変化させていくことから、更新（updateまたはmodify）と言えます。
例えば、下図の状態１から状態２のツリーに変換したい場合、次のような手順を踏みます。
- bの親にMを加える
- aの親にLを加える
- dを削除する
- dをMの長男に加える
- eを削除する
- cを削除する
- aを削除する
一方、一般的なデータ変換（画像フォーマットやCSVソートや表の組換え）などでは、元のデータには変化させずに、別にデータを再構築（reconstruction）するのが通常です。ツリー変換でも、ツリーはそのままに、別にツリーを作る方法を採ることもできます。この場合の手順は以下のようになります。
- Lをルートとして作ります
- Lの長男にMを加えます
- Mにノードを追加し、dのデータをコピーします
- Mにノードを追加し、bのデータをコピーします
- Lにノードを追加し、fのデータをコピーします
ジーンコードは、後述の再構築方式を採っています。このことが、最終的に制作するコンテンツに大きな影響を与えることになります。再構築方式では、更新方式と比較して、PCサイトから影響を受けにくいのが特徴です。元PCデザインの影響を極力排して、スマ－トフォンライクでよりフィットしたUIを提供することができます。
再構築方式では、まず出力のスマートフォンのツリーの形が決まります。その形はPCサイトでのツリー構造に拘束されません。確定した出力構成にデータが注入されるだけです。元のツリーによっては、意図したデータが取得できない場合でさえ、出力ツリー構造は不変です。この、出力ツリーの安定化が再構築方式を採用している最大の目的です。出力ツリーが決まれば、CSSやJavaScriptを使って、スマートフォン用のUIを細かく作りこむことが可能になります。特にスマートフォン用に普及しているJavaScriptによるリッチなUIコンポーネントを使えることは大きなメリットになります。
一方、更新方式の場合には、変換のロジックが元のツリー構造への操作となる為、出力ツリー構造を安定化させることが、ほぼできません。この為、実現したいUIに必要なCSSやJavaScriptを適用することが困難で、一般的に普及しているライブラリなどを適用することができません。結果的に１つ１つの変換ロジック毎に個別制作となるために、UIの質を保つことができません。
このように更新方式と再構築方式では、最適なUIを実現できる可能性に大きな差があります。結果、複雑なページや大量のページが対象である場合、工期やコスト・品質において、再構築方式に大きなアドバンテージがあります。
であれば、全てのPC→SP変換が再構築方式を取っているかとなれば、そういうわけではありません。これを実現するには、技術的な大きな壁が存在するからです。次回は、それを取り上げます。