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