https://github.com/BabylonJS/BabylonNative/blob/master/Documentation/WhenToUseBabylonNative.md

Questionnaire

For each of the following questions, click on the link you feel best represents your answer. The link will take you to another view of this same page with the next question for you at the top of your view. Eventually, a link will take you to a lower section discussing whether or not we believe a Babylon Native technology might be right for your scenario and why.
アンケート
以下の各質問について、あなたの答えに最も近いと思われるリンクをクリックしてください。このリンクは、この同じページの別のビューに移動し、ビューの上部にあなたへの次の質問が表示されます。最終的には、バビロンネイティブテクノロジーがあなたのシナリオに適しているかどうか、その理由を説明する下のセクションに移動します。

質問①

Does your project need rendering code to be shared between Web and native deployments?
あなたのプロジェクトでは、Webとネイティブのデプロイメント間でレンダリングコードを共有する必要がありますか？

• Yes, I need Web and native deployments to share rendering code.
  • はい、ウェブとネイティブのデプロイメントでレンダリング コードを共有する必要があります。
    • 質問②へ
• No, having multiple deployments share rendering code isn't a priority for me.
  • いいえ、複数のデプロイメントでレンダリング コードを共有することは、私にとって優先事項ではありません。
    • 質問②へ

質問②

Are you picking a platform for a new app, or is your app's platform already decided?
新しいアプリのプラットフォームを選んでいるのか、それともアプリのプラットフォームはすでに決まっているのか？

• I'm picking a platform for my new app.
  • 新しいアプリのプラットフォームを選択中です。
    • 質問③へ
• I'm adding rendering to an app that's already committed to a platform.
  • すでにプラットフォームにコミットしているアプリにレンダリングを追加している。
    • 質問⑥へ

質問③

Do you prefer more native-like technologies or more Web-like technologies?
よりネイティブに近い技術と、よりWebに近い技術のどちらが好きですか？

• I prefer more native-like technologies.
  • 質問④へ
• I prefer more Web-like technologies.
  • 質問⑤へ

質問④

Do you have exceptional rendering requirements such as AAA-quality graphics or extreme performance needs?
AAA品質のグラフィックスや極端なパフォーマンスニーズなど、例外的なレンダリング要件がありますか？

• I want things to look good, but I don't need extreme graphics or performance.
  • 見栄えはよくしたいが、極端なグラフィックや性能は必要ない。
    • Babylon Native おすすめ
• I need AAA-quality graphics and/or exceptional performance.
  • 他のテクノロジーの方が適しているかも
    • AAAクラスのグラフィックスと卓越したパフォーマンスの両方が必要だ。

質問⑤

Do you already have existing expertise and/or preferences for React Native, or do you need native capabilities that aren't provided by normal Web APIs (such as AR on iOS)?
React Nativeに関する既存の専門知識や好みがあるか、あるいは通常のWeb APIでは提供されないネイティブの機能（iOSのARなど）が必要か？

• Yes.
  • Babylon React Nativeおすすめ
• No.
  • 他のテクノロジーの方が適しているかも

質問⑥

Is your app built on React Native, another JavaScript-using platform (including Web or hybrid app platforms), or non-JavaScript technologies?
アプリは、React Native、JavaScriptを使用する他のプラットフォーム（Webやハイブリッドアプリのプラットフォームを含む）、または非JavaScriptテクノロジーで構築されていますか？

• My app is a React Native app.
  • Babylon React Nativeおすすめ
• My app's platform uses JavaScript, but it isn't made with React Native.
  • JavaScriptだがReact Nativeではない
    • 他のテクノロジーの方が適しているかも
• My app's platform doesn't inherently use JavaScript.
  • 私のアプリのプラットフォームでは、本来JavaScriptは使えません。
    • 質問④へ

Babylon Native is probably a good choice for your project!

Congratulations! If you ended up here, then we think Babylon Native may be a suitable choice for adding Babylon.js to your project. Typically, applications for which Babylon Native is well-suited tend to be developed as true native apps (C++, C#, etc.) which require rendering as a feature, though not necessarily the focus. Examples might include the following:

• A presentation app written in C# that needs to be able to render 3D as well as 2D content.
• A scientific simulation utility written in Java that wants to be able to render data.
• A 3D content generation tool written in C++ that wants to be able to preview its output.

The main reason Babylon Native is well-suited for these scenarios is because Babylon Native makes it possible to bring Babylon's rendering capabilities into native applications with extremely minimal requirements regarding app and development infrastructure. In other words, Babylon Native is perhaps the simplest way to add Web-style rendering to a native application without having to pivot that application to become a Web app.

おめでとうございます。ここにたどり着いたということは、Babylon Nativeは、あなたのプロジェクトにBabylon.jsを追加するのに適した選択かもしれないと、私たちは考えています。一般的に、Babylon Nativeが適しているアプリケーションは、真のネイティブ・アプリケーション（C++、C#など）として開発される傾向にあり、必ずしもフォーカスされてはいないものの、機能としてレンダリングを必要とします。例としては、以下のようなものがあります。

• C#で書かれたプレゼンテーションアプリで、2Dだけでなく3Dのコンテンツもレンダリングできる必要があるもの。
• Javaで書かれた科学的シミュレーションユーティリティで、データのレンダリングが必要な場合。
• C++で書かれた3Dコンテンツ生成ツールで、その出力をプレビューすることができるようにしたい。

Babylon Nativeが、これらのシナリオに適している主な理由は、Babylon Nativeが、アプリと開発インフラに関する極めて最小限の要件で、バビロンのレンダリング能力を、ネイティブ・アプリケーションにもたらすことを可能にするからです。言い換えれば、Babylon Nativeは、おそらく、ウェブアプリケーションになるために、アプリケーションをピボットすることなく、ネイティブアプリケーションにウェブスタイルレンダリングを追加する、最もシンプルな方法と言えます。

Babylon React Native is probably a good choice for your project!

Congratulations! If you ended up here, then we think Babylon React Native may be a suitable choice for adding Babylon.js to your project. There are two main situations when Babylon React Native is a particularly good choice for a project:

• When the project is already being built with React Native and wants to add GPU-accelerated rendering as simply as possible.
• When the project requires capabilities that aren't typically exposed to Web-like platforms.

In the former case, if your app is already committed to React Native as a platform, Babylon React Native is one of two options to add rendering to your project using Babylon.js. The second of these options is to simply use Babylon.js in a WebView, and there are some advantages to this approach: it can sometimes yield better JavaScript performance (on iOS, WebViews are allowed to run JavaScript with JIT enabled while React Native, and consequently Babylon React Native, are not) and it will provide access to the very latest Babylon.js features, which may not always be available in Babylon React Native. However, there are disadvantages as well: a WebView will create a second JavaScript context distinct from React Native's main JavaScript context and you will have to manage communication between the contexts manually, which can be complex and/or slow and may negatively impact memory footprint as you pay the memory cost for two JavaScript contexts instead of one. Furthermore, running inside a WebView will restrict you to only the features that the platform's WebView allows, whereas with Babylon React Native you can extend your JavaScript-exposed capabilities by reaching through the platform into the native layer itself.

This segues directly into the second situation when Babylon React Native is a particularly good choice: when you need capabilities that aren't typically exposed to Web-like platforms. The most blatant example of a case like this is AR on iOS. Apple does not expose ARKit to JavaScript, which means that JavaScript-based logic (such as Babylon.js) cannot power XR experiences on Apple platforms. Babylon React Native, however, overcomes this limitation by augmenting its JavaScript capabilities to allow AR apps using the same code on both Android and iOS. Thus, for any developer seeking to use Web-like technologies to develop AR-capable apps that run on iOS (or use any other platform feature not exposed to JavaScript), Babylon React Native may be the best -- and perhaps even the only -- viable choice.

おめでとうございます。ここにたどり着いたということは、Babylon React Nativeは、あなたのプロジェクトにBabylon.jsを追加するのに適した選択かもしれないと、私たちは考えています。Babylon React Nativeがプロジェクトにとって特に良い選択である場合、主に2つの状況があります。

• プロジェクトがすでにReact Nativeで構築されており、できるだけシンプルにGPUアクセラレーションによるレンダリングを追加したい場合。
• プロジェクトが、一般的にウェブライクなプラットフォームでは公開されない機能を必要とする場合。

前者の場合、アプリがプラットフォームとしてすでにReact Nativeにコミットしている場合、Babylon React Nativeは、Babylon.jsを使用してプロジェクトにレンダリングを追加する2つのオプションのうちの1つとなります。2つ目の選択肢は、単純にWebViewでBabylon.jsを使うというもので、この方法にはいくつかのメリットがあります。JavaScriptのパフォーマンスが向上する場合があり（iOSでは、WebViewはJITを有効にしてJavaScriptを実行できますが、React Native、ひいてはBabylon React Nativeはそうではありません）、常にBabylon React Nativeでは利用できないかもしれない最新のBabylon.js機能へのアクセスが可能になることでしょう。WebViewはReact NativeのメインのJavaScriptコンテキストとは異なる2つ目のJavaScriptコンテキストを作成し、コンテキスト間の通信を手動で管理する必要がありますが、これは複雑かつ遅くなり、1つではなく2つのJavaScriptコンテキストに対してメモリコストを支払うため、メモリフットプリントに悪影響を与える可能性があります。さらに、WebViewの内部で実行すると、プラットフォームのWebViewが許可する機能だけに制限されます。一方、Babylon React Nativeでは、プラットフォームを通じてネイティブ層自体に到達することで、JavaScriptが公開する機能を拡張することができます。

これは、Babylon React Nativeが特に良い選択である2つ目の状況、つまり、一般的にWebライクなプラットフォームで公開されていない機能が必要な場合に、直接つながっていきます。このようなケースの最も露骨な例は、iOSのARです。AppleはARKitをJavaScriptに公開していないため、JavaScriptベースのロジック（Babylon.jsなど）は、Appleプラットフォーム上のXR体験をパワーアップできないことを意味します。しかし、Babylon React Nativeは、そのJavaScript機能を強化することで、この制限を克服し、AndroidとiOSの両方で同じコードを使用してARアプリを実現することができます。したがって、iOS上で動作するAR対応アプリを開発するために、Webライクな技術を使おうとする開発者にとっては、Babylon React Nativeは、最良の、そしておそらく唯一の、実行可能な選択かもしれません。

There may be other choices better suited to your project than Babylon Native technologies. (Babylon Nativeの技術よりも、プロジェクトに適した他の選択肢があるかもしれません。)

If you've ended up here, then Babylon Native technologies may not be the best options for your particular scenario. There are a number of reasons this might be the case, but the most common boil down to, "You don't need Babylon Native's or Babylon React Native's special capabilities, so there are simpler alternatives that may suit your needs better."

Babylon Native and Babylon React Native both belong on the spectrum of hybrid app platforms -- platforms which combine features of Web and native environments -- and both lie more toward the native side of the spectrum than toward the Web side.

もし、あなたがここにたどり着いたのなら、Babylon Nativeテクノロジーは、あなたの特定のシナリオにとって、最良の選択肢ではないかもしれません。その理由はいくつかありますが、最も多いのは、「Babylon NativeやBabylon React Nativeの特別な機能は必要ないので、よりニーズに合ったシンプルな代替手段がある」というものです。

Babylon NativeとBabylon React Nativeはどちらも、ハイブリッドアプリプラットフォーム（ウェブとネイティブ環境の機能を組み合わせたプラットフォーム）のスペクトラムに属し、どちらもウェブ側よりもネイティブ側に位置しています。

Generally speaking, developers will approach hybrid apps from a basis of familiarity with one or the other end of the spectrum (dedicated React Native developers are an exception), and the further one goes on the spectrum from one's prior familiarity, the more complex a platform will be to use. Babylon Native and Babylon React Native, while still hybrid app technologies, are both significantly dissimiliar from a "true" Web platform, and a Web developer has many other hybrid platform options that are significantly more similar to the Web and are thus likely to be simpler for that developer to use. Likewise from the opposite perspective, a developer more familiar with native platforms may find Babylon Native and Babylon React Native more complex to use than a pure native solution such as a Unity or Unreal. (Again, dedicated React Native developers are a bit of an exception as their baseline familiarity lies with neither native nor Web; however, they are also much less likely to be reading this section as it's very likely that Babylon React Native will be a suitable choice for their preferred platform.) Thus, the most common reason why a Babylon Native technology may not be the most suitable platform for a given usage is simply, "There's a simpler alternative that will suffice in your scenario."

Less commonly, Babylon Native technologies may not be suitable for a particular app because the app requires something Babylon Native does not provide well. For example, a usage that depends on AAA-quality graphics, leveraging the latest features in specialized rendering pipelines, may not find its needs met by Babylon Native technologies because Web rendering technologies in general typically lag behind native rendering capabilities by several years. Similarly, apps with significant performance constraints may not be well-served by Babylon Native technologies because Babylon.js scene logic runs in JavaScript, which incurs inherent performance cost. This can even manifest between seemingly comparable alternatives, such as comparing Babylon React Native to Babylon.js in a WebView on iOS; in this scenario, depending on what exactly is being rendered and how, the specialized optimizations Babylon React Native can do thanks to its "native" nature may or may not fully offset the performance penalty of running JavaScript without JIT (which Apple permits for WebViews but prevents for Babylon React Native). In nuanced scenarios such as this, the only way to know for sure which approach might perform better for the particular rendering in question would be to try both and measure, but both will run less speedily than a pure-native (not Web-like) rendering solution like Unity or Unreal.

一般的に、開発者はどちらか一方に精通した上でハイブリッド アプリに取り組みます (React Native 専用の開発者は例外です)。そして、以前の精通からスペクトルを進めれば進めるほど、プラットフォームの使用はより複雑になります。Babylon NativeとBabylon React Nativeは、ハイブリッドアプリ技術ではありますが、どちらも「真の」Webプラットフォームとは大きく異なっており、Web開発者には、Webに大きく似た他の多くのハイブリッドプラットフォームの選択肢があるため、開発者にとってはよりシンプルに使用できる可能性があります。同様に逆の観点から、ネイティブ プラットフォームに精通している開発者は、Babylon Native や Babylon React Native を、Unity や Unreal などの純粋なネイティブ ソリューションよりも複雑だと感じるかもしれません。(繰り返しになりますが、専用のReact Native開発者は、基本的にネイティブにもウェブにも精通していないため、少し例外的です。しかし、彼らがこのセクションを読んでいる可能性もかなり低く、Babylon React Nativeが彼らの好むプラットフォームに適した選択である可能性が非常に高いからです)。このように、Babylon Nativeの技術が、ある用途に最も適したプラットフォームではない最も一般的な理由は、単に「あなたのシナリオで十分な、よりシンプルな代替案がある」ということです。

あまり一般的ではありませんが、アプリが、Babylon Nativeがうまく提供できないものを必要とするため、Babylon Nativeテクノロジーは、特定のアプリに適さないかもしれません。例えば、特殊なレンダリング・パイプラインの最新機能を活用した、AAA品質のグラフィックスに依存する使用法は、一般的にウェブレンダリング技術が、数年遅れでネイティブレンダリング機能に対応しているため、そのニーズをバビロンネイティブテクノロジーで満たすことができないかもしれません。同様に、パフォーマンスに大きな制約のあるアプリケーションは、Babylon Native・テクノロジーでは、うまくいかないかもしれません。なぜなら、Babylon.jsのシーンロジックは、固有のパフォーマンス・コストが発生する、JavaScriptで実行されるからです。このシナリオでは、正確に何がどのようにレンダリングされているかによって、Babylon React Nativeがその「ネイティブ」な性質のおかげでできる特別な最適化が、JITなしでJavaScriptを実行することによるパフォーマンスのペナルティを完全に相殺するかもしれません（AppleはWebViewsでは許可しますがBabylon React Nativeでは禁止しています）。このようなニュアンスのシナリオでは、問題の特定のレンダリングに対してどちらのアプローチがより良いパフォーマンスとなるかを確実に知る唯一の方法は、両方を試して測定することですが、どちらもUnityやUnrealなどの（ウェブライクではない）ピュアネイティブレンダリングソリューションよりも実行速度が遅くなります。

So If I Shouldn't Use Babylon Native, What Should I Use? (Babylon Nativeを使っちゃいけないなら、何を使えばいいんだ？)

The answer to this question depends on why Babylon Native technologies weren't ideally suited for your scenario.

• Did you simply not need Babylon Native's specialized capabilities such that a simpler alternative would suffice? If so, other options such as Progressive Web Apps, Ionic, or Electron may be worth looking into. (Comparing these alternatives is beyond the scope of this document.)
  • Babylon Nativeの特殊な機能を必要とせず、よりシンプルな代替技術で十分だったのでしょうか？もしそうなら、Progressive Web Apps、Ionic、Electronなどの他の選択肢を検討する価値があるかもしれません。(これらの選択肢を比較することは、このドキュメントの範囲外です）。
• Did your particular scenario run poorly in Babylon React Native on iOS due to the unavailability of JIT? If so, you might try rendering the same thing using Babylon.js in a WebView.
  • あなたの特定のシナリオは、JITが利用できないために、iOS上のBabylon React Nativeでうまく動作しなかったのでしょうか？もしそうなら、WebViewでBabylon.jsを使って同じものをレンダリングしてみてはいかがでしょうか。
• Do you need rendering speed or fidelity that seems to be beyond what Web-like rendering can provide? If so, pure native rendering solutions like Unity or Unreal may provide what you're looking for.
  • Web ライクなレンダリングでは実現できないようなレンダリング速度や忠実度が必要な場合はどうでしょうか。そのような場合は、Unity や Unreal などの純粋なネイティブ レンダリング ソリューションが、お探しのものを提供してくれるかもしれません。
• Do you need additional help thinking about what platform might be best for you? If so, please don't hesitate to ping us on the the Babylon.js forum and we'll be happy to help you weigh the options.
  • どのようなプラットフォームが最適か、さらに考える手助けが必要でしょうか？その場合は、Babylon.jsのフォーラムで、遠慮なく私たちにご連絡ください。

Thanks for considering Babylon Native and Babylon React Native!