aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Cohen <jco...@twopensource.com>
Subject Re: Aurora React UI Demo/Prototype
Date Thu, 16 Jul 2015 18:07:00 GMT
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