Hi Colin, Thanks for comment, I think your concerns are all valid but also arguable:
First, YARN UI is different from HDFS UI, it is much more complex: 1. We have many data models, such as app/container/system/node, etc. UI of HDFS is more like a file explorer. 2. We plan to add more rich data visualization to YARN UI to make admin can easier identify what happened. For example, using sunburst map <http://bl.ocks.org/kerryrodden/7090426> to render usage breakdown of cluster/queue/user/app, etc. 3. We need to get data from different sources with different format. For example, application's running container information stores at RM and finished container information stores at Timeline server. We need to get data from both daemon, normalize these data (because REST API is different) and aggregate them. Ember.js could simplify what we should do a lot: - It has great data store design so we can easily normalize data model from different sources with different formats (adapter) - It can easily bind data model with view, so any changes to data store (like application status updated) can trigger page re-rendering without any additional works. - Besides binding data with view, it can also bind data to other computed properties. For example, if property of a model relies on another model, all properties/models will be updated altogether. - Integrates bower/broccoli/watchman to help with package management/build/development. - For other benefits, please refer to Why Ember? <http://mutewinter.github.io/why_ember/#/slides> slides. The plan of nextgen YARN UI is not only inherit and prettify existing YARN UI. I hope it can let users can get deep insight of what happens in their cluster. As you said, a simple JS framework can also achieve what we wanna to do, but using well designed framework can avoid reinvent the wheel. Regarding to your concerns about JS compilation/compaction, I think it is not conflict with open source: In source folder (git repository), all code are readable. Compilation/compaction code only exists in released code. I agree that we don't need obfuscation at all, but source code compaction could increase performance a lot, we could have heavy rendering tasks, such as visualization from statuses of 10K+ applications. Just like Java code of Hadoop, no user will try to get source code from a running cluster :). I will make sure integration to Maven is as less as possible, we should only need one single sub module, and limit all changes in that module only. Please let me know if you have any other concerns. Thanks, Wangda On Mon, Feb 29, 2016 at 8:51 AM, Colin P. McCabe <cmcc...@apache.org> wrote: > Hmm. Devil's advocate here: Do we really need to have a "JS build"? > > The main use-cases for "JS builds" seem to be if you want to minimize > or obfuscate your JS. Given that this is open source code, > obfuscation seems unnecessary. Given that it's a low-traffic > management interface, minimizing the JS seems like a premature > optimization. > > The HDFS user interface is based on dust.js, and it just requires JS > files to be copied into the correct location. > > Perhaps there are advantages to ember.js that I am missing. But > there's also a big advantage to not having to manage a node.js build > system separate from Maven and CMake. What do you think? > > best, > Colin > > On Thu, Feb 25, 2016 at 11:18 AM, Wangda Tan <wheele...@gmail.com> wrote: > > Hi Allen, > > > > YARN-3368 is using Ember.JS and Ember.JS depends on npm (Node.JS Package > > Manager) to manage packages. > > > > One thing to clarify is: npm dependency is only required by build stage > (JS > > build is stitching source files and renaming variables). After JS build > > completes, there's no dependency of Node.JS any more. Server such as RM > > only needs to run a HTTP server to host JS files, and browser will take > > care of page rendering, just like HDFS/Spark/Mesos UI. > > > > There're a couple of other Apache projects are using Ember.JS, such as > > Tez/Ambari. Ember.JS can help front-end developers easier manage models, > > pages, events and packages. > > > > Thanks, > > Wangda > > > > On Thu, Feb 25, 2016 at 9:16 AM, Allen Wittenauer <a...@altiscale.com> > wrote: > > > >> > >> Hey folks. > >> > >> Have any of you looked at YARN-3368? Is adding node.js+a bunch > of > >> other stuff as dependencies just for the UI a good idea? Doesn’t that > seem > >> significantly heavyweight? How hard is this going to be operationally > to > >> manage? >
