aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David McLaughlin <da...@dmclaughlin.com>
Subject Re: Aurora React UI Demo/Prototype
Date Thu, 16 Jul 2015 18:24:30 GMT
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