Re: Aurora React UI Demo/Prototype
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
[GitHub] aurora pull request:
Github user datakurre commented on the pull request: https://github.com/apache/aurora/commit/e34bf7c69c31438725714c27a2a0cbc75684ec15#commitcomment-12268062 @wfarner FYI that adding http_authentication_machenism for scheduler has broken the tutorial, causing test_tutorial.sh to fail (scheduler responds with 401). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Aurora React UI Demo/Prototype
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
