Aurora React UI Demo/Prototype

[Joshua Cohen <jc...@twopensource.com>]

As mentioned during the IRC meeting earlier this week. I spent some time
recently putting together a React-driven UI prototype as a strawman for a
discussion about potentially moving away from Angular for the UI. This
prototype is now available on Github: https://github.com/jcohen/aurora-react
.

As mentioned in the README, the project is very simple. It doesn't actually
talk to the Scheduler and it only contains two pages (of which only one
attempts to render data). It also uses the current UI layout for
convenience. The intention to use it as a way to judge whether this style
of app is preferable to Angular or if we should renew our investment in the
current Angular based UI and pay down the tech debt that it has accrued.

Interested to hear everyone's thoughts!

Cheers,

Joshua

Re: Aurora React UI Demo/Prototype

[Joshua Cohen <jc...@twopensource.com>]

I actually checked into a React replacement for smart-table, and one does
exist: https://github.com/zippyui/react-datagrid.

On Thu, Jul 16, 2015 at 3:05 PM, Suman Karumuri <
skarumuri@twitter.com.invalid> wrote:

> Thanks for building this Joshua!
>
> I am -1 on a proposal to switch FE technology stacks for the same reasons
> David mentioned.
>
> Also, the current scheduler UI uses an angularJS library called smart table
> for rendering tables, searching and sorting columns and pagination. Since
> there is no react equivalent of the same library, we have to re-implement
> the library in react, which could potentially mean we will end up
> maintaining a lot more code if we moved to react.
>
> On Thu, Jul 16, 2015 at 11:24 AM, David McLaughlin <da...@dmclaughlin.com>
> wrote:
>
> > Thanks for doing this and sharing code!
> >
> > I'd be -1 to any proposal to switch our FE technology stack for several
> > reasons.
> >
> > I find this stack way too advanced for what the scheduler UI currently
> > does. This is also a problem with Angular, but we're already stuck with
> > that now.
> >
> > I also don't think any of the problems with the current UI are due to
> > Angular. The biggest hole that I see in our FE code is lack of automated
> > testing, and this technology stack doesn't change the trade-offs involved
> > in solving that.
> >
> > I also don't think our current technology stack hinders our ability to
> > resolve any of the currently open UI tickets, nor does it prevent us from
> > doing any of the 'this would be cool' features we've talked about. The
> > biggest barriers are more about abstractions or lack of concrete
> interfaces
> > between the components in Aurora.
> >
> > I think we need to acknowledge that for the most part the Aurora project
> > does not have a great deal of FE resource. Switching stacks again would
> > involve retraining everyone to this new thing, but based on the nature of
> > the code in the demo - it also involves making sure everyone has cutting
> > edge knowledge of JS, which would be a new barrier to entry for anyone
> > looking to make quick UI fixes and also make code reviews much harder. I
> > think for an infrastructure product like this where most of the expertise
> > is in server-side development, it's probably safer to be a couple of
> > iterations behind the latest fads in the JS community.
> >
> >
> > Cheers,
> > David
> >
> >
> > On Thu, Jul 16, 2015 at 11:07 AM, Joshua Cohen <jc...@twopensource.com>
> > wrote:
> >
> > > There are numerous large and stable sites powered by this technology.
> Not
> > > least among them are Facebook and Instagram for which these
> technologies
> > > were developed (that being React/Flux). ES6 being transpiled down to
> ES5
> > is
> > > widely adopted as well (off the top of my head, I know Slack does it).
> > ES6
> > > is an officially adopted standard and direct browser support for it is
> > > increasing quickly: https://kangax.github.io/compat-table/es6/. As you
> > can
> > > see from the table Firefox and Chrome have already implemented
> > significant
> > > parts of the spec. Predictably IE and Safari are lagging behind, but I
> > > think we're past the point where we need to be concerned about ES6
> never
> > > being adopted. Transpiling in general is a common practice in the JS
> > > community as can be seen by the popularity of things like CoffeeScript.
> > Of
> > > all the technologies that would potentially be introduced by this
> change,
> > > using ES6 syntax and transpiling it to ES5 is the one that I have the
> > least
> > > qualms about.
> > >
> > > On Thu, Jul 16, 2015 at 12:53 PM, Bill Farner <wf...@apache.org>
> > wrote:
> > >
> > > > I'm pretty ignorant of this space, please bear with me.
> > > >
> > > > You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > > > > javascript you're likely familiar with). As of React 0.13.x, ES6
> > with a
> > > > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > > > syntax)
> > > > > is the preferred method of writing React apps. For more details on
> > the
> > > > new
> > > > > ES6 features you can read this:
> http://babeljs.io/docs/learn-es2015/
> > > > > (babel
> > > > > is the transpiler used by the demo).
> > > > >
> > > >
> > > > This sounds very fancy and cutting-edge.  Sometimes fancy and
> > > cutting-edge
> > > > things are not ready for prime time.  What gives you confidence that
> > this
> > > > is stable and will not result in trailblazing on our part?
> > > >
> > > >
> > > >
> > > > -=Bill
> > > >
> > > > On Thu, Jul 16, 2015 at 8:50 AM, Joshua Cohen <
> jcohen@twopensource.com
> > >
> > > > wrote:
> > > >
> > > > > For those who are not familiar with React, here's some more
> > > > details/helpful
> > > > > links on the underlying technologies.
> > > > >
> > > > > 1) You'll notice that the app is written in ES6 and not ES5 (i.e.
> the
> > > > > javascript you're likely familiar with). As of React 0.13.x, ES6
> > with a
> > > > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > > > syntax)
> > > > > is the preferred method of writing React apps. For more details on
> > the
> > > > new
> > > > > ES6 features you can read this:
> http://babeljs.io/docs/learn-es2015/
> > > > > (babel
> > > > > is the transpiler used by the demo).
> > > > >
> > > > > 2) The next thing you'll notice is that the components weirdly
> > > > intermingle
> > > > > javascript and HTML. This is a React feature called JSX. JSX lets
> you
> > > > > express DOM-like components in a more natural style. You *can*
> create
> > > > React
> > > > > components using pure-JS, but JSX is the recommended way to do so.
> > For
> > > > more
> > > > > details on JSX I'd recommend reading:
> > > > > https://facebook.github.io/react/docs/jsx-in-depth.html.
> > > > >
> > > > > 3) With the syntax-strangeness out of the way, the next thing to
> > > > understand
> > > > > is React itself. React simplifies building high performance JS apps
> > in
> > > a
> > > > > couple of ways: first, it removes two-way binding, which in complex
> > > apps
> > > > > can make reasoning about what causes what to change and when very
> > > > > difficult, and second: it provides a virtual DOM. The slowest part
> of
> > > > > JS-driven apps is updating the DOM. With React, when your data
> > changes
> > > > your
> > > > > components are only re-rendered if they've actually changed; this
> is
> > > > > accomplished via the virtual DOM. Components are first rendered
> into
> > > the
> > > > > virtual DOM and then the new tree is compared against the current
> > one,
> > > > and
> > > > > only the portions of the tree that are changed are actually
> rendered
> > > into
> > > > > the page. For more details about React in general, I'd recommend
> > > reading
> > > > > the React docs themselves:
> > > > > https://facebook.github.io/react/docs/getting-started.html.
> > > > >
> > > > > 4) Finally, the last architectural piece of the demo is Flux. Flux
> > is a
> > > > > replacement for the traditional MVC model. It provides a
> > unidirectional
> > > > > data flow for responding to events. Essentially the user interacts
> > with
> > > > the
> > > > > app which causes Actions to be sent to the Dispatcher. Stores
> listen
> > > for
> > > > > events from the Dispatcher and update their state. This causes
> Views
> > > (in
> > > > > our case React components) to re-render, at which point the cycle
> > > begins
> > > > > anew. You can read more about Flux here:
> > > > > https://facebook.github.io/flux/docs/overview.html.
> > > > >
> > > > > This stuff is relatively new to me as well, so there's a better
> than
> > > zero
> > > > > chance that there's room for improvement with the way the demo is
> > > > > implemented. but I think it serves as a good starting point for a
> > > > > discussion about whether this style of application is palatable.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Joshua
> > > > >
> > > > > On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <
> > jcohen@twopensource.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > As mentioned during the IRC meeting earlier this week. I spent
> some
> > > > time
> > > > > > recently putting together a React-driven UI prototype as a
> strawman
> > > > for a
> > > > > > discussion about potentially moving away from Angular for the UI.
> > > This
> > > > > > prototype is now available on Github:
> > > > > > https://github.com/jcohen/aurora-react.
> > > > > >
> > > > > > As mentioned in the README, the project is very simple. It
> doesn't
> > > > > > actually talk to the Scheduler and it only contains two pages (of
> > > which
> > > > > > only one attempts to render data). It also uses the current UI
> > layout
> > > > for
> > > > > > convenience. The intention to use it as a way to judge whether
> this
> > > > style
> > > > > > of app is preferable to Angular or if we should renew our
> > investment
> > > in
> > > > > the
> > > > > > current Angular based UI and pay down the tech debt that it has
> > > > accrued.
> > > > > >
> > > > > > Interested to hear everyone's thoughts!
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Joshua
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Aurora React UI Demo/Prototype

[Suman Karumuri <sk...@twitter.com.INVALID>]

Thanks for building this Joshua!

I am -1 on a proposal to switch FE technology stacks for the same reasons
David mentioned.

Also, the current scheduler UI uses an angularJS library called smart table
for rendering tables, searching and sorting columns and pagination. Since
there is no react equivalent of the same library, we have to re-implement
the library in react, which could potentially mean we will end up
maintaining a lot more code if we moved to react.

On Thu, Jul 16, 2015 at 11:24 AM, David McLaughlin <da...@dmclaughlin.com>
wrote:

> Thanks for doing this and sharing code!
>
> I'd be -1 to any proposal to switch our FE technology stack for several
> reasons.
>
> I find this stack way too advanced for what the scheduler UI currently
> does. This is also a problem with Angular, but we're already stuck with
> that now.
>
> I also don't think any of the problems with the current UI are due to
> Angular. The biggest hole that I see in our FE code is lack of automated
> testing, and this technology stack doesn't change the trade-offs involved
> in solving that.
>
> I also don't think our current technology stack hinders our ability to
> resolve any of the currently open UI tickets, nor does it prevent us from
> doing any of the 'this would be cool' features we've talked about. The
> biggest barriers are more about abstractions or lack of concrete interfaces
> between the components in Aurora.
>
> I think we need to acknowledge that for the most part the Aurora project
> does not have a great deal of FE resource. Switching stacks again would
> involve retraining everyone to this new thing, but based on the nature of
> the code in the demo - it also involves making sure everyone has cutting
> edge knowledge of JS, which would be a new barrier to entry for anyone
> looking to make quick UI fixes and also make code reviews much harder. I
> think for an infrastructure product like this where most of the expertise
> is in server-side development, it's probably safer to be a couple of
> iterations behind the latest fads in the JS community.
>
>
> Cheers,
> David
>
>
> On Thu, Jul 16, 2015 at 11:07 AM, Joshua Cohen <jc...@twopensource.com>
> wrote:
>
> > There are numerous large and stable sites powered by this technology. Not
> > least among them are Facebook and Instagram for which these technologies
> > were developed (that being React/Flux). ES6 being transpiled down to ES5
> is
> > widely adopted as well (off the top of my head, I know Slack does it).
> ES6
> > is an officially adopted standard and direct browser support for it is
> > increasing quickly: https://kangax.github.io/compat-table/es6/. As you
> can
> > see from the table Firefox and Chrome have already implemented
> significant
> > parts of the spec. Predictably IE and Safari are lagging behind, but I
> > think we're past the point where we need to be concerned about ES6 never
> > being adopted. Transpiling in general is a common practice in the JS
> > community as can be seen by the popularity of things like CoffeeScript.
> Of
> > all the technologies that would potentially be introduced by this change,
> > using ES6 syntax and transpiling it to ES5 is the one that I have the
> least
> > qualms about.
> >
> > On Thu, Jul 16, 2015 at 12:53 PM, Bill Farner <wf...@apache.org>
> wrote:
> >
> > > I'm pretty ignorant of this space, please bear with me.
> > >
> > > You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > > > javascript you're likely familiar with). As of React 0.13.x, ES6
> with a
> > > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > > syntax)
> > > > is the preferred method of writing React apps. For more details on
> the
> > > new
> > > > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> > > > (babel
> > > > is the transpiler used by the demo).
> > > >
> > >
> > > This sounds very fancy and cutting-edge.  Sometimes fancy and
> > cutting-edge
> > > things are not ready for prime time.  What gives you confidence that
> this
> > > is stable and will not result in trailblazing on our part?
> > >
> > >
> > >
> > > -=Bill
> > >
> > > On Thu, Jul 16, 2015 at 8:50 AM, Joshua Cohen <jcohen@twopensource.com
> >
> > > wrote:
> > >
> > > > For those who are not familiar with React, here's some more
> > > details/helpful
> > > > links on the underlying technologies.
> > > >
> > > > 1) You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > > > javascript you're likely familiar with). As of React 0.13.x, ES6
> with a
> > > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > > syntax)
> > > > is the preferred method of writing React apps. For more details on
> the
> > > new
> > > > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> > > > (babel
> > > > is the transpiler used by the demo).
> > > >
> > > > 2) The next thing you'll notice is that the components weirdly
> > > intermingle
> > > > javascript and HTML. This is a React feature called JSX. JSX lets you
> > > > express DOM-like components in a more natural style. You *can* create
> > > React
> > > > components using pure-JS, but JSX is the recommended way to do so.
> For
> > > more
> > > > details on JSX I'd recommend reading:
> > > > https://facebook.github.io/react/docs/jsx-in-depth.html.
> > > >
> > > > 3) With the syntax-strangeness out of the way, the next thing to
> > > understand
> > > > is React itself. React simplifies building high performance JS apps
> in
> > a
> > > > couple of ways: first, it removes two-way binding, which in complex
> > apps
> > > > can make reasoning about what causes what to change and when very
> > > > difficult, and second: it provides a virtual DOM. The slowest part of
> > > > JS-driven apps is updating the DOM. With React, when your data
> changes
> > > your
> > > > components are only re-rendered if they've actually changed; this is
> > > > accomplished via the virtual DOM. Components are first rendered into
> > the
> > > > virtual DOM and then the new tree is compared against the current
> one,
> > > and
> > > > only the portions of the tree that are changed are actually rendered
> > into
> > > > the page. For more details about React in general, I'd recommend
> > reading
> > > > the React docs themselves:
> > > > https://facebook.github.io/react/docs/getting-started.html.
> > > >
> > > > 4) Finally, the last architectural piece of the demo is Flux. Flux
> is a
> > > > replacement for the traditional MVC model. It provides a
> unidirectional
> > > > data flow for responding to events. Essentially the user interacts
> with
> > > the
> > > > app which causes Actions to be sent to the Dispatcher. Stores listen
> > for
> > > > events from the Dispatcher and update their state. This causes Views
> > (in
> > > > our case React components) to re-render, at which point the cycle
> > begins
> > > > anew. You can read more about Flux here:
> > > > https://facebook.github.io/flux/docs/overview.html.
> > > >
> > > > This stuff is relatively new to me as well, so there's a better than
> > zero
> > > > chance that there's room for improvement with the way the demo is
> > > > implemented. but I think it serves as a good starting point for a
> > > > discussion about whether this style of application is palatable.
> > > >
> > > > Cheers,
> > > >
> > > > Joshua
> > > >
> > > > On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <
> jcohen@twopensource.com
> > >
> > > > wrote:
> > > >
> > > > > As mentioned during the IRC meeting earlier this week. I spent some
> > > time
> > > > > recently putting together a React-driven UI prototype as a strawman
> > > for a
> > > > > discussion about potentially moving away from Angular for the UI.
> > This
> > > > > prototype is now available on Github:
> > > > > https://github.com/jcohen/aurora-react.
> > > > >
> > > > > As mentioned in the README, the project is very simple. It doesn't
> > > > > actually talk to the Scheduler and it only contains two pages (of
> > which
> > > > > only one attempts to render data). It also uses the current UI
> layout
> > > for
> > > > > convenience. The intention to use it as a way to judge whether this
> > > style
> > > > > of app is preferable to Angular or if we should renew our
> investment
> > in
> > > > the
> > > > > current Angular based UI and pay down the tech debt that it has
> > > accrued.
> > > > >
> > > > > Interested to hear everyone's thoughts!
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Joshua
> > > > >
> > > >
> > >
> >
>

Re: Aurora React UI Demo/Prototype

[Joshua Cohen <jc...@twopensource.com>]

On Tue, Jul 21, 2015 at 10:12 AM, Bill Farner <wf...@apache.org> wrote:

> >
> > One thing that did come up in the context of this discussion, however,
> was
> > the ability for Aurora to serve up a custom UI. There was a suggestion
> for
> > allowing Aurora operators to specify a custom UI path that would be
> served
> > up, allowing users to swap in a non-default UI. I'm curious what people
> > think about that idea?
>
>
> Huge +1 if we can make it easy to manage.  I did a decent chunk of work to
> position for this last year, resulting in all assets being served out of
> /scheduler/assets on the classpath.
>

Just to circle back to this, I filed
https://issues.apache.org/jira/browse/AURORA-1408 to track this feature
request.

Re: Aurora React UI Demo/Prototype

[Bill Farner <wf...@apache.org>]

>
> One thing that did come up in the context of this discussion, however, was
> the ability for Aurora to serve up a custom UI. There was a suggestion for
> allowing Aurora operators to specify a custom UI path that would be served
> up, allowing users to swap in a non-default UI. I'm curious what people
> think about that idea?


Huge +1 if we can make it easy to manage.  I did a decent chunk of work to
position for this last year, resulting in all assets being served out of
/scheduler/assets on the classpath.


-=Bill

On Tue, Jul 21, 2015 at 5:32 AM, Joshua Cohen <jc...@twopensource.com>
wrote:

> I don't really disagree with any of the points you raise, David, they were
> all concerns I had going into the work, the only uncertainty was exactly
> how big of a change going from Angular to React would turn out to be. The
> primary reason why I ventured down this path to begin with is the looming
> Angular 2.0 release. Angular 2.0 is similar to React in many ways (virtual
> DOM, uses TypeScript which is a superset of ES6, etc.). My concern was that
> we'd be forced to make the upgrade in the future when support for Angular
> 1.x was dropped. Given that I'm going to put some effort into adding test
> coverage for the UI, this seemed like a good time to evaluate alternatives,
> and whether we could avoid that forced upgrade in the future. I definitely
> don't want us to get stuck on an unsupported tech stack for the UI,
> regardless of how deep (or shallow, as the case may be) our requirements
> for a UI framework are.
>
> That said, I've been doing some deeper reading on the Angular 2.0 release
> and it seems like the developers have softened their stance a bit:
> http://www.infoq.com/news/2015/03/angular-2-concerns-addressed.
> Essentially
> they've committed to support Angular 1.x until the "vast majority" of the
> community has migrated to 2.x. There's no real timeframe attached to
> Angular 1.x being EOL'd. Additionally, they seem to be providing at least
> something of a migration path from 1.x to 2.x via the new router. This is
> definitely still something we need to pay attention to (and I still might
> advocate for React over Angular 2.x when the time comes), but I don't think
> it currently bubbles up to level of concern that would require a total
> overhaul of the UI.
>
> One thing that did come up in the context of this discussion, however, was
> the ability for Aurora to serve up a custom UI. There was a suggestion for
> allowing Aurora operators to specify a custom UI path that would be served
> up, allowing users to swap in a non-default UI. I'm curious what people
> think about that idea?
>
> On Thu, Jul 16, 2015 at 1:24 PM, David McLaughlin <da...@dmclaughlin.com>
> wrote:
>
> > Thanks for doing this and sharing code!
> >
> > I'd be -1 to any proposal to switch our FE technology stack for several
> > reasons.
> >
> > I find this stack way too advanced for what the scheduler UI currently
> > does. This is also a problem with Angular, but we're already stuck with
> > that now.
> >
> > I also don't think any of the problems with the current UI are due to
> > Angular. The biggest hole that I see in our FE code is lack of automated
> > testing, and this technology stack doesn't change the trade-offs involved
> > in solving that.
> >
> > I also don't think our current technology stack hinders our ability to
> > resolve any of the currently open UI tickets, nor does it prevent us from
> > doing any of the 'this would be cool' features we've talked about. The
> > biggest barriers are more about abstractions or lack of concrete
> interfaces
> > between the components in Aurora.
> >
> > I think we need to acknowledge that for the most part the Aurora project
> > does not have a great deal of FE resource. Switching stacks again would
> > involve retraining everyone to this new thing, but based on the nature of
> > the code in the demo - it also involves making sure everyone has cutting
> > edge knowledge of JS, which would be a new barrier to entry for anyone
> > looking to make quick UI fixes and also make code reviews much harder. I
> > think for an infrastructure product like this where most of the expertise
> > is in server-side development, it's probably safer to be a couple of
> > iterations behind the latest fads in the JS community.
> >
> >
> > Cheers,
> > David
> >
> >
> > On Thu, Jul 16, 2015 at 11:07 AM, Joshua Cohen <jc...@twopensource.com>
> > wrote:
> >
> > > There are numerous large and stable sites powered by this technology.
> Not
> > > least among them are Facebook and Instagram for which these
> technologies
> > > were developed (that being React/Flux). ES6 being transpiled down to
> ES5
> > is
> > > widely adopted as well (off the top of my head, I know Slack does it).
> > ES6
> > > is an officially adopted standard and direct browser support for it is
> > > increasing quickly: https://kangax.github.io/compat-table/es6/. As you
> > can
> > > see from the table Firefox and Chrome have already implemented
> > significant
> > > parts of the spec. Predictably IE and Safari are lagging behind, but I
> > > think we're past the point where we need to be concerned about ES6
> never
> > > being adopted. Transpiling in general is a common practice in the JS
> > > community as can be seen by the popularity of things like CoffeeScript.
> > Of
> > > all the technologies that would potentially be introduced by this
> change,
> > > using ES6 syntax and transpiling it to ES5 is the one that I have the
> > least
> > > qualms about.
> > >
> > > On Thu, Jul 16, 2015 at 12:53 PM, Bill Farner <wf...@apache.org>
> > wrote:
> > >
> > > > I'm pretty ignorant of this space, please bear with me.
> > > >
> > > > You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > > > > javascript you're likely familiar with). As of React 0.13.x, ES6
> > with a
> > > > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > > > syntax)
> > > > > is the preferred method of writing React apps. For more details on
> > the
> > > > new
> > > > > ES6 features you can read this:
> http://babeljs.io/docs/learn-es2015/
> > > > > (babel
> > > > > is the transpiler used by the demo).
> > > > >
> > > >
> > > > This sounds very fancy and cutting-edge.  Sometimes fancy and
> > > cutting-edge
> > > > things are not ready for prime time.  What gives you confidence that
> > this
> > > > is stable and will not result in trailblazing on our part?
> > > >
> > > >
> > > >
> > > > -=Bill
> > > >
> > > > On Thu, Jul 16, 2015 at 8:50 AM, Joshua Cohen <
> jcohen@twopensource.com
> > >
> > > > wrote:
> > > >
> > > > > For those who are not familiar with React, here's some more
> > > > details/helpful
> > > > > links on the underlying technologies.
> > > > >
> > > > > 1) You'll notice that the app is written in ES6 and not ES5 (i.e.
> the
> > > > > javascript you're likely familiar with). As of React 0.13.x, ES6
> > with a
> > > > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > > > syntax)
> > > > > is the preferred method of writing React apps. For more details on
> > the
> > > > new
> > > > > ES6 features you can read this:
> http://babeljs.io/docs/learn-es2015/
> > > > > (babel
> > > > > is the transpiler used by the demo).
> > > > >
> > > > > 2) The next thing you'll notice is that the components weirdly
> > > > intermingle
> > > > > javascript and HTML. This is a React feature called JSX. JSX lets
> you
> > > > > express DOM-like components in a more natural style. You *can*
> create
> > > > React
> > > > > components using pure-JS, but JSX is the recommended way to do so.
> > For
> > > > more
> > > > > details on JSX I'd recommend reading:
> > > > > https://facebook.github.io/react/docs/jsx-in-depth.html.
> > > > >
> > > > > 3) With the syntax-strangeness out of the way, the next thing to
> > > > understand
> > > > > is React itself. React simplifies building high performance JS apps
> > in
> > > a
> > > > > couple of ways: first, it removes two-way binding, which in complex
> > > apps
> > > > > can make reasoning about what causes what to change and when very
> > > > > difficult, and second: it provides a virtual DOM. The slowest part
> of
> > > > > JS-driven apps is updating the DOM. With React, when your data
> > changes
> > > > your
> > > > > components are only re-rendered if they've actually changed; this
> is
> > > > > accomplished via the virtual DOM. Components are first rendered
> into
> > > the
> > > > > virtual DOM and then the new tree is compared against the current
> > one,
> > > > and
> > > > > only the portions of the tree that are changed are actually
> rendered
> > > into
> > > > > the page. For more details about React in general, I'd recommend
> > > reading
> > > > > the React docs themselves:
> > > > > https://facebook.github.io/react/docs/getting-started.html.
> > > > >
> > > > > 4) Finally, the last architectural piece of the demo is Flux. Flux
> > is a
> > > > > replacement for the traditional MVC model. It provides a
> > unidirectional
> > > > > data flow for responding to events. Essentially the user interacts
> > with
> > > > the
> > > > > app which causes Actions to be sent to the Dispatcher. Stores
> listen
> > > for
> > > > > events from the Dispatcher and update their state. This causes
> Views
> > > (in
> > > > > our case React components) to re-render, at which point the cycle
> > > begins
> > > > > anew. You can read more about Flux here:
> > > > > https://facebook.github.io/flux/docs/overview.html.
> > > > >
> > > > > This stuff is relatively new to me as well, so there's a better
> than
> > > zero
> > > > > chance that there's room for improvement with the way the demo is
> > > > > implemented. but I think it serves as a good starting point for a
> > > > > discussion about whether this style of application is palatable.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Joshua
> > > > >
> > > > > On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <
> > jcohen@twopensource.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > As mentioned during the IRC meeting earlier this week. I spent
> some
> > > > time
> > > > > > recently putting together a React-driven UI prototype as a
> strawman
> > > > for a
> > > > > > discussion about potentially moving away from Angular for the UI.
> > > This
> > > > > > prototype is now available on Github:
> > > > > > https://github.com/jcohen/aurora-react.
> > > > > >
> > > > > > As mentioned in the README, the project is very simple. It
> doesn't
> > > > > > actually talk to the Scheduler and it only contains two pages (of
> > > which
> > > > > > only one attempts to render data). It also uses the current UI
> > layout
> > > > for
> > > > > > convenience. The intention to use it as a way to judge whether
> this
> > > > style
> > > > > > of app is preferable to Angular or if we should renew our
> > investment
> > > in
> > > > > the
> > > > > > current Angular based UI and pay down the tech debt that it has
> > > > accrued.
> > > > > >
> > > > > > Interested to hear everyone's thoughts!
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Joshua
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Aurora React UI Demo/Prototype

[Joshua Cohen <jc...@twopensource.com>]

I don't really disagree with any of the points you raise, David, they were
all concerns I had going into the work, the only uncertainty was exactly
how big of a change going from Angular to React would turn out to be. The
primary reason why I ventured down this path to begin with is the looming
Angular 2.0 release. Angular 2.0 is similar to React in many ways (virtual
DOM, uses TypeScript which is a superset of ES6, etc.). My concern was that
we'd be forced to make the upgrade in the future when support for Angular
1.x was dropped. Given that I'm going to put some effort into adding test
coverage for the UI, this seemed like a good time to evaluate alternatives,
and whether we could avoid that forced upgrade in the future. I definitely
don't want us to get stuck on an unsupported tech stack for the UI,
regardless of how deep (or shallow, as the case may be) our requirements
for a UI framework are.

That said, I've been doing some deeper reading on the Angular 2.0 release
and it seems like the developers have softened their stance a bit:
http://www.infoq.com/news/2015/03/angular-2-concerns-addressed. Essentially
they've committed to support Angular 1.x until the "vast majority" of the
community has migrated to 2.x. There's no real timeframe attached to
Angular 1.x being EOL'd. Additionally, they seem to be providing at least
something of a migration path from 1.x to 2.x via the new router. This is
definitely still something we need to pay attention to (and I still might
advocate for React over Angular 2.x when the time comes), but I don't think
it currently bubbles up to level of concern that would require a total
overhaul of the UI.

One thing that did come up in the context of this discussion, however, was
the ability for Aurora to serve up a custom UI. There was a suggestion for
allowing Aurora operators to specify a custom UI path that would be served
up, allowing users to swap in a non-default UI. I'm curious what people
think about that idea?

On Thu, Jul 16, 2015 at 1:24 PM, David McLaughlin <da...@dmclaughlin.com>
wrote:

> Thanks for doing this and sharing code!
>
> I'd be -1 to any proposal to switch our FE technology stack for several
> reasons.
>
> I find this stack way too advanced for what the scheduler UI currently
> does. This is also a problem with Angular, but we're already stuck with
> that now.
>
> I also don't think any of the problems with the current UI are due to
> Angular. The biggest hole that I see in our FE code is lack of automated
> testing, and this technology stack doesn't change the trade-offs involved
> in solving that.
>
> I also don't think our current technology stack hinders our ability to
> resolve any of the currently open UI tickets, nor does it prevent us from
> doing any of the 'this would be cool' features we've talked about. The
> biggest barriers are more about abstractions or lack of concrete interfaces
> between the components in Aurora.
>
> I think we need to acknowledge that for the most part the Aurora project
> does not have a great deal of FE resource. Switching stacks again would
> involve retraining everyone to this new thing, but based on the nature of
> the code in the demo - it also involves making sure everyone has cutting
> edge knowledge of JS, which would be a new barrier to entry for anyone
> looking to make quick UI fixes and also make code reviews much harder. I
> think for an infrastructure product like this where most of the expertise
> is in server-side development, it's probably safer to be a couple of
> iterations behind the latest fads in the JS community.
>
>
> Cheers,
> David
>
>
> On Thu, Jul 16, 2015 at 11:07 AM, Joshua Cohen <jc...@twopensource.com>
> wrote:
>
> > There are numerous large and stable sites powered by this technology. Not
> > least among them are Facebook and Instagram for which these technologies
> > were developed (that being React/Flux). ES6 being transpiled down to ES5
> is
> > widely adopted as well (off the top of my head, I know Slack does it).
> ES6
> > is an officially adopted standard and direct browser support for it is
> > increasing quickly: https://kangax.github.io/compat-table/es6/. As you
> can
> > see from the table Firefox and Chrome have already implemented
> significant
> > parts of the spec. Predictably IE and Safari are lagging behind, but I
> > think we're past the point where we need to be concerned about ES6 never
> > being adopted. Transpiling in general is a common practice in the JS
> > community as can be seen by the popularity of things like CoffeeScript.
> Of
> > all the technologies that would potentially be introduced by this change,
> > using ES6 syntax and transpiling it to ES5 is the one that I have the
> least
> > qualms about.
> >
> > On Thu, Jul 16, 2015 at 12:53 PM, Bill Farner <wf...@apache.org>
> wrote:
> >
> > > I'm pretty ignorant of this space, please bear with me.
> > >
> > > You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > > > javascript you're likely familiar with). As of React 0.13.x, ES6
> with a
> > > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > > syntax)
> > > > is the preferred method of writing React apps. For more details on
> the
> > > new
> > > > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> > > > (babel
> > > > is the transpiler used by the demo).
> > > >
> > >
> > > This sounds very fancy and cutting-edge.  Sometimes fancy and
> > cutting-edge
> > > things are not ready for prime time.  What gives you confidence that
> this
> > > is stable and will not result in trailblazing on our part?
> > >
> > >
> > >
> > > -=Bill
> > >
> > > On Thu, Jul 16, 2015 at 8:50 AM, Joshua Cohen <jcohen@twopensource.com
> >
> > > wrote:
> > >
> > > > For those who are not familiar with React, here's some more
> > > details/helpful
> > > > links on the underlying technologies.
> > > >
> > > > 1) You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > > > javascript you're likely familiar with). As of React 0.13.x, ES6
> with a
> > > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > > syntax)
> > > > is the preferred method of writing React apps. For more details on
> the
> > > new
> > > > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> > > > (babel
> > > > is the transpiler used by the demo).
> > > >
> > > > 2) The next thing you'll notice is that the components weirdly
> > > intermingle
> > > > javascript and HTML. This is a React feature called JSX. JSX lets you
> > > > express DOM-like components in a more natural style. You *can* create
> > > React
> > > > components using pure-JS, but JSX is the recommended way to do so.
> For
> > > more
> > > > details on JSX I'd recommend reading:
> > > > https://facebook.github.io/react/docs/jsx-in-depth.html.
> > > >
> > > > 3) With the syntax-strangeness out of the way, the next thing to
> > > understand
> > > > is React itself. React simplifies building high performance JS apps
> in
> > a
> > > > couple of ways: first, it removes two-way binding, which in complex
> > apps
> > > > can make reasoning about what causes what to change and when very
> > > > difficult, and second: it provides a virtual DOM. The slowest part of
> > > > JS-driven apps is updating the DOM. With React, when your data
> changes
> > > your
> > > > components are only re-rendered if they've actually changed; this is
> > > > accomplished via the virtual DOM. Components are first rendered into
> > the
> > > > virtual DOM and then the new tree is compared against the current
> one,
> > > and
> > > > only the portions of the tree that are changed are actually rendered
> > into
> > > > the page. For more details about React in general, I'd recommend
> > reading
> > > > the React docs themselves:
> > > > https://facebook.github.io/react/docs/getting-started.html.
> > > >
> > > > 4) Finally, the last architectural piece of the demo is Flux. Flux
> is a
> > > > replacement for the traditional MVC model. It provides a
> unidirectional
> > > > data flow for responding to events. Essentially the user interacts
> with
> > > the
> > > > app which causes Actions to be sent to the Dispatcher. Stores listen
> > for
> > > > events from the Dispatcher and update their state. This causes Views
> > (in
> > > > our case React components) to re-render, at which point the cycle
> > begins
> > > > anew. You can read more about Flux here:
> > > > https://facebook.github.io/flux/docs/overview.html.
> > > >
> > > > This stuff is relatively new to me as well, so there's a better than
> > zero
> > > > chance that there's room for improvement with the way the demo is
> > > > implemented. but I think it serves as a good starting point for a
> > > > discussion about whether this style of application is palatable.
> > > >
> > > > Cheers,
> > > >
> > > > Joshua
> > > >
> > > > On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <
> jcohen@twopensource.com
> > >
> > > > wrote:
> > > >
> > > > > As mentioned during the IRC meeting earlier this week. I spent some
> > > time
> > > > > recently putting together a React-driven UI prototype as a strawman
> > > for a
> > > > > discussion about potentially moving away from Angular for the UI.
> > This
> > > > > prototype is now available on Github:
> > > > > https://github.com/jcohen/aurora-react.
> > > > >
> > > > > As mentioned in the README, the project is very simple. It doesn't
> > > > > actually talk to the Scheduler and it only contains two pages (of
> > which
> > > > > only one attempts to render data). It also uses the current UI
> layout
> > > for
> > > > > convenience. The intention to use it as a way to judge whether this
> > > style
> > > > > of app is preferable to Angular or if we should renew our
> investment
> > in
> > > > the
> > > > > current Angular based UI and pay down the tech debt that it has
> > > accrued.
> > > > >
> > > > > Interested to hear everyone's thoughts!
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Joshua
> > > > >
> > > >
> > >
> >
>

Re: Aurora React UI Demo/Prototype

[David McLaughlin <da...@dmclaughlin.com>]

Thanks for doing this and sharing code!

I'd be -1 to any proposal to switch our FE technology stack for several
reasons.

I find this stack way too advanced for what the scheduler UI currently
does. This is also a problem with Angular, but we're already stuck with
that now.

I also don't think any of the problems with the current UI are due to
Angular. The biggest hole that I see in our FE code is lack of automated
testing, and this technology stack doesn't change the trade-offs involved
in solving that.

I also don't think our current technology stack hinders our ability to
resolve any of the currently open UI tickets, nor does it prevent us from
doing any of the 'this would be cool' features we've talked about. The
biggest barriers are more about abstractions or lack of concrete interfaces
between the components in Aurora.

I think we need to acknowledge that for the most part the Aurora project
does not have a great deal of FE resource. Switching stacks again would
involve retraining everyone to this new thing, but based on the nature of
the code in the demo - it also involves making sure everyone has cutting
edge knowledge of JS, which would be a new barrier to entry for anyone
looking to make quick UI fixes and also make code reviews much harder. I
think for an infrastructure product like this where most of the expertise
is in server-side development, it's probably safer to be a couple of
iterations behind the latest fads in the JS community.


Cheers,
David


On Thu, Jul 16, 2015 at 11:07 AM, Joshua Cohen <jc...@twopensource.com>
wrote:

> There are numerous large and stable sites powered by this technology. Not
> least among them are Facebook and Instagram for which these technologies
> were developed (that being React/Flux). ES6 being transpiled down to ES5 is
> widely adopted as well (off the top of my head, I know Slack does it). ES6
> is an officially adopted standard and direct browser support for it is
> increasing quickly: https://kangax.github.io/compat-table/es6/. As you can
> see from the table Firefox and Chrome have already implemented significant
> parts of the spec. Predictably IE and Safari are lagging behind, but I
> think we're past the point where we need to be concerned about ES6 never
> being adopted. Transpiling in general is a common practice in the JS
> community as can be seen by the popularity of things like CoffeeScript. Of
> all the technologies that would potentially be introduced by this change,
> using ES6 syntax and transpiling it to ES5 is the one that I have the least
> qualms about.
>
> On Thu, Jul 16, 2015 at 12:53 PM, Bill Farner <wf...@apache.org> wrote:
>
> > I'm pretty ignorant of this space, please bear with me.
> >
> > You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > > javascript you're likely familiar with). As of React 0.13.x, ES6 with a
> > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > syntax)
> > > is the preferred method of writing React apps. For more details on the
> > new
> > > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> > > (babel
> > > is the transpiler used by the demo).
> > >
> >
> > This sounds very fancy and cutting-edge.  Sometimes fancy and
> cutting-edge
> > things are not ready for prime time.  What gives you confidence that this
> > is stable and will not result in trailblazing on our part?
> >
> >
> >
> > -=Bill
> >
> > On Thu, Jul 16, 2015 at 8:50 AM, Joshua Cohen <jc...@twopensource.com>
> > wrote:
> >
> > > For those who are not familiar with React, here's some more
> > details/helpful
> > > links on the underlying technologies.
> > >
> > > 1) You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > > javascript you're likely familiar with). As of React 0.13.x, ES6 with a
> > > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> > syntax)
> > > is the preferred method of writing React apps. For more details on the
> > new
> > > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> > > (babel
> > > is the transpiler used by the demo).
> > >
> > > 2) The next thing you'll notice is that the components weirdly
> > intermingle
> > > javascript and HTML. This is a React feature called JSX. JSX lets you
> > > express DOM-like components in a more natural style. You *can* create
> > React
> > > components using pure-JS, but JSX is the recommended way to do so. For
> > more
> > > details on JSX I'd recommend reading:
> > > https://facebook.github.io/react/docs/jsx-in-depth.html.
> > >
> > > 3) With the syntax-strangeness out of the way, the next thing to
> > understand
> > > is React itself. React simplifies building high performance JS apps in
> a
> > > couple of ways: first, it removes two-way binding, which in complex
> apps
> > > can make reasoning about what causes what to change and when very
> > > difficult, and second: it provides a virtual DOM. The slowest part of
> > > JS-driven apps is updating the DOM. With React, when your data changes
> > your
> > > components are only re-rendered if they've actually changed; this is
> > > accomplished via the virtual DOM. Components are first rendered into
> the
> > > virtual DOM and then the new tree is compared against the current one,
> > and
> > > only the portions of the tree that are changed are actually rendered
> into
> > > the page. For more details about React in general, I'd recommend
> reading
> > > the React docs themselves:
> > > https://facebook.github.io/react/docs/getting-started.html.
> > >
> > > 4) Finally, the last architectural piece of the demo is Flux. Flux is a
> > > replacement for the traditional MVC model. It provides a unidirectional
> > > data flow for responding to events. Essentially the user interacts with
> > the
> > > app which causes Actions to be sent to the Dispatcher. Stores listen
> for
> > > events from the Dispatcher and update their state. This causes Views
> (in
> > > our case React components) to re-render, at which point the cycle
> begins
> > > anew. You can read more about Flux here:
> > > https://facebook.github.io/flux/docs/overview.html.
> > >
> > > This stuff is relatively new to me as well, so there's a better than
> zero
> > > chance that there's room for improvement with the way the demo is
> > > implemented. but I think it serves as a good starting point for a
> > > discussion about whether this style of application is palatable.
> > >
> > > Cheers,
> > >
> > > Joshua
> > >
> > > On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <jcohen@twopensource.com
> >
> > > wrote:
> > >
> > > > As mentioned during the IRC meeting earlier this week. I spent some
> > time
> > > > recently putting together a React-driven UI prototype as a strawman
> > for a
> > > > discussion about potentially moving away from Angular for the UI.
> This
> > > > prototype is now available on Github:
> > > > https://github.com/jcohen/aurora-react.
> > > >
> > > > As mentioned in the README, the project is very simple. It doesn't
> > > > actually talk to the Scheduler and it only contains two pages (of
> which
> > > > only one attempts to render data). It also uses the current UI layout
> > for
> > > > convenience. The intention to use it as a way to judge whether this
> > style
> > > > of app is preferable to Angular or if we should renew our investment
> in
> > > the
> > > > current Angular based UI and pay down the tech debt that it has
> > accrued.
> > > >
> > > > Interested to hear everyone's thoughts!
> > > >
> > > > Cheers,
> > > >
> > > > Joshua
> > > >
> > >
> >
>

Re: Aurora React UI Demo/Prototype

[Joshua Cohen <jc...@twopensource.com>]

There are numerous large and stable sites powered by this technology. Not
least among them are Facebook and Instagram for which these technologies
were developed (that being React/Flux). ES6 being transpiled down to ES5 is
widely adopted as well (off the top of my head, I know Slack does it). ES6
is an officially adopted standard and direct browser support for it is
increasing quickly: https://kangax.github.io/compat-table/es6/. As you can
see from the table Firefox and Chrome have already implemented significant
parts of the spec. Predictably IE and Safari are lagging behind, but I
think we're past the point where we need to be concerned about ES6 never
being adopted. Transpiling in general is a common practice in the JS
community as can be seen by the popularity of things like CoffeeScript. Of
all the technologies that would potentially be introduced by this change,
using ES6 syntax and transpiling it to ES5 is the one that I have the least
qualms about.

On Thu, Jul 16, 2015 at 12:53 PM, Bill Farner <wf...@apache.org> wrote:

> I'm pretty ignorant of this space, please bear with me.
>
> You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > javascript you're likely familiar with). As of React 0.13.x, ES6 with a
> > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> syntax)
> > is the preferred method of writing React apps. For more details on the
> new
> > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> > (babel
> > is the transpiler used by the demo).
> >
>
> This sounds very fancy and cutting-edge.  Sometimes fancy and cutting-edge
> things are not ready for prime time.  What gives you confidence that this
> is stable and will not result in trailblazing on our part?
>
>
>
> -=Bill
>
> On Thu, Jul 16, 2015 at 8:50 AM, Joshua Cohen <jc...@twopensource.com>
> wrote:
>
> > For those who are not familiar with React, here's some more
> details/helpful
> > links on the underlying technologies.
> >
> > 1) You'll notice that the app is written in ES6 and not ES5 (i.e. the
> > javascript you're likely familiar with). As of React 0.13.x, ES6 with a
> > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5
> syntax)
> > is the preferred method of writing React apps. For more details on the
> new
> > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> > (babel
> > is the transpiler used by the demo).
> >
> > 2) The next thing you'll notice is that the components weirdly
> intermingle
> > javascript and HTML. This is a React feature called JSX. JSX lets you
> > express DOM-like components in a more natural style. You *can* create
> React
> > components using pure-JS, but JSX is the recommended way to do so. For
> more
> > details on JSX I'd recommend reading:
> > https://facebook.github.io/react/docs/jsx-in-depth.html.
> >
> > 3) With the syntax-strangeness out of the way, the next thing to
> understand
> > is React itself. React simplifies building high performance JS apps in a
> > couple of ways: first, it removes two-way binding, which in complex apps
> > can make reasoning about what causes what to change and when very
> > difficult, and second: it provides a virtual DOM. The slowest part of
> > JS-driven apps is updating the DOM. With React, when your data changes
> your
> > components are only re-rendered if they've actually changed; this is
> > accomplished via the virtual DOM. Components are first rendered into the
> > virtual DOM and then the new tree is compared against the current one,
> and
> > only the portions of the tree that are changed are actually rendered into
> > the page. For more details about React in general, I'd recommend reading
> > the React docs themselves:
> > https://facebook.github.io/react/docs/getting-started.html.
> >
> > 4) Finally, the last architectural piece of the demo is Flux. Flux is a
> > replacement for the traditional MVC model. It provides a unidirectional
> > data flow for responding to events. Essentially the user interacts with
> the
> > app which causes Actions to be sent to the Dispatcher. Stores listen for
> > events from the Dispatcher and update their state. This causes Views (in
> > our case React components) to re-render, at which point the cycle begins
> > anew. You can read more about Flux here:
> > https://facebook.github.io/flux/docs/overview.html.
> >
> > This stuff is relatively new to me as well, so there's a better than zero
> > chance that there's room for improvement with the way the demo is
> > implemented. but I think it serves as a good starting point for a
> > discussion about whether this style of application is palatable.
> >
> > Cheers,
> >
> > Joshua
> >
> > On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <jc...@twopensource.com>
> > wrote:
> >
> > > As mentioned during the IRC meeting earlier this week. I spent some
> time
> > > recently putting together a React-driven UI prototype as a strawman
> for a
> > > discussion about potentially moving away from Angular for the UI. This
> > > prototype is now available on Github:
> > > https://github.com/jcohen/aurora-react.
> > >
> > > As mentioned in the README, the project is very simple. It doesn't
> > > actually talk to the Scheduler and it only contains two pages (of which
> > > only one attempts to render data). It also uses the current UI layout
> for
> > > convenience. The intention to use it as a way to judge whether this
> style
> > > of app is preferable to Angular or if we should renew our investment in
> > the
> > > current Angular based UI and pay down the tech debt that it has
> accrued.
> > >
> > > Interested to hear everyone's thoughts!
> > >
> > > Cheers,
> > >
> > > Joshua
> > >
> >
>

Re: Aurora React UI Demo/Prototype

[Bill Farner <wf...@apache.org>]

I'm pretty ignorant of this space, please bear with me.

You'll notice that the app is written in ES6 and not ES5 (i.e. the
> javascript you're likely familiar with). As of React 0.13.x, ES6 with a
> transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5 syntax)
> is the preferred method of writing React apps. For more details on the new
> ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> (babel
> is the transpiler used by the demo).
>

This sounds very fancy and cutting-edge.  Sometimes fancy and cutting-edge
things are not ready for prime time.  What gives you confidence that this
is stable and will not result in trailblazing on our part?



-=Bill

On Thu, Jul 16, 2015 at 8:50 AM, Joshua Cohen <jc...@twopensource.com>
wrote:

> For those who are not familiar with React, here's some more details/helpful
> links on the underlying technologies.
>
> 1) You'll notice that the app is written in ES6 and not ES5 (i.e. the
> javascript you're likely familiar with). As of React 0.13.x, ES6 with a
> transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5 syntax)
> is the preferred method of writing React apps. For more details on the new
> ES6 features you can read this: http://babeljs.io/docs/learn-es2015/
> (babel
> is the transpiler used by the demo).
>
> 2) The next thing you'll notice is that the components weirdly intermingle
> javascript and HTML. This is a React feature called JSX. JSX lets you
> express DOM-like components in a more natural style. You *can* create React
> components using pure-JS, but JSX is the recommended way to do so. For more
> details on JSX I'd recommend reading:
> https://facebook.github.io/react/docs/jsx-in-depth.html.
>
> 3) With the syntax-strangeness out of the way, the next thing to understand
> is React itself. React simplifies building high performance JS apps in a
> couple of ways: first, it removes two-way binding, which in complex apps
> can make reasoning about what causes what to change and when very
> difficult, and second: it provides a virtual DOM. The slowest part of
> JS-driven apps is updating the DOM. With React, when your data changes your
> components are only re-rendered if they've actually changed; this is
> accomplished via the virtual DOM. Components are first rendered into the
> virtual DOM and then the new tree is compared against the current one, and
> only the portions of the tree that are changed are actually rendered into
> the page. For more details about React in general, I'd recommend reading
> the React docs themselves:
> https://facebook.github.io/react/docs/getting-started.html.
>
> 4) Finally, the last architectural piece of the demo is Flux. Flux is a
> replacement for the traditional MVC model. It provides a unidirectional
> data flow for responding to events. Essentially the user interacts with the
> app which causes Actions to be sent to the Dispatcher. Stores listen for
> events from the Dispatcher and update their state. This causes Views (in
> our case React components) to re-render, at which point the cycle begins
> anew. You can read more about Flux here:
> https://facebook.github.io/flux/docs/overview.html.
>
> This stuff is relatively new to me as well, so there's a better than zero
> chance that there's room for improvement with the way the demo is
> implemented. but I think it serves as a good starting point for a
> discussion about whether this style of application is palatable.
>
> Cheers,
>
> Joshua
>
> On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <jc...@twopensource.com>
> wrote:
>
> > As mentioned during the IRC meeting earlier this week. I spent some time
> > recently putting together a React-driven UI prototype as a strawman for a
> > discussion about potentially moving away from Angular for the UI. This
> > prototype is now available on Github:
> > https://github.com/jcohen/aurora-react.
> >
> > As mentioned in the README, the project is very simple. It doesn't
> > actually talk to the Scheduler and it only contains two pages (of which
> > only one attempts to render data). It also uses the current UI layout for
> > convenience. The intention to use it as a way to judge whether this style
> > of app is preferable to Angular or if we should renew our investment in
> the
> > current Angular based UI and pay down the tech debt that it has accrued.
> >
> > Interested to hear everyone's thoughts!
> >
> > Cheers,
> >
> > Joshua
> >
>

Re: Aurora React UI Demo/Prototype

[Joshua Cohen <jc...@twopensource.com>]

For those who are not familiar with React, here's some more details/helpful
links on the underlying technologies.

1) You'll notice that the app is written in ES6 and not ES5 (i.e. the
javascript you're likely familiar with). As of React 0.13.x, ES6 with a
transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5 syntax)
is the preferred method of writing React apps. For more details on the new
ES6 features you can read this: http://babeljs.io/docs/learn-es2015/ (babel
is the transpiler used by the demo).

2) The next thing you'll notice is that the components weirdly intermingle
javascript and HTML. This is a React feature called JSX. JSX lets you
express DOM-like components in a more natural style. You *can* create React
components using pure-JS, but JSX is the recommended way to do so. For more
details on JSX I'd recommend reading:
https://facebook.github.io/react/docs/jsx-in-depth.html.

3) With the syntax-strangeness out of the way, the next thing to understand
is React itself. React simplifies building high performance JS apps in a
couple of ways: first, it removes two-way binding, which in complex apps
can make reasoning about what causes what to change and when very
difficult, and second: it provides a virtual DOM. The slowest part of
JS-driven apps is updating the DOM. With React, when your data changes your
components are only re-rendered if they've actually changed; this is
accomplished via the virtual DOM. Components are first rendered into the
virtual DOM and then the new tree is compared against the current one, and
only the portions of the tree that are changed are actually rendered into
the page. For more details about React in general, I'd recommend reading
the React docs themselves:
https://facebook.github.io/react/docs/getting-started.html.

4) Finally, the last architectural piece of the demo is Flux. Flux is a
replacement for the traditional MVC model. It provides a unidirectional
data flow for responding to events. Essentially the user interacts with the
app which causes Actions to be sent to the Dispatcher. Stores listen for
events from the Dispatcher and update their state. This causes Views (in
our case React components) to re-render, at which point the cycle begins
anew. You can read more about Flux here:
https://facebook.github.io/flux/docs/overview.html.

This stuff is relatively new to me as well, so there's a better than zero
chance that there's room for improvement with the way the demo is
implemented. but I think it serves as a good starting point for a
discussion about whether this style of application is palatable.

Cheers,

Joshua

On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <jc...@twopensource.com>
wrote:

> As mentioned during the IRC meeting earlier this week. I spent some time
> recently putting together a React-driven UI prototype as a strawman for a
> discussion about potentially moving away from Angular for the UI. This
> prototype is now available on Github:
> https://github.com/jcohen/aurora-react.
>
> As mentioned in the README, the project is very simple. It doesn't
> actually talk to the Scheduler and it only contains two pages (of which
> only one attempts to render data). It also uses the current UI layout for
> convenience. The intention to use it as a way to judge whether this style
> of app is preferable to Angular or if we should renew our investment in the
> current Angular based UI and pay down the tech debt that it has accrued.
>
> Interested to hear everyone's thoughts!
>
> Cheers,
>
> Joshua
>