aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suman Karumuri <skarum...@twitter.com.INVALID>
Subject Re: Aurora React UI Demo/Prototype
Date Thu, 16 Jul 2015 20:05:57 GMT
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 <david@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 <jcohen@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 <wfarner@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
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message