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 <jco...@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 <wfar...@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 <jco...@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 < > jco...@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 > > > > > > > > > > > > > > >
