Galaxy Client Planning

[jxtx]

This issue is to track plans for the evolution of the Galaxy client (the browser based interface to a Galaxy instance). Galaxy currently includes a mixture of server-side rendered pages and client-side rendered pages, most of which use Backbone.js views and models. With the availability of more modern Javascript technologies, we want to evolve the client to be reactive and entirely rendered on the client side.

Tooling

We will use webpack (v3) along with babel to transpile es6 source code for browser consumption. es6 syntax will be preferred for all future work once the https://github.com/dannon/galaxy/commits/es6 branch is integrated. We will support flow type annotations to be gradually added.

We will use simplify formatting using style standardization by Prettier, prettier --format flow --tab-width 4

Routing

We will continue using the Backbone based routing infrastructure that has been developed in Galaxy to allow different types of components through the transition.

Data Access

All access to the Galaxy backend will be through documented APIs. We will document APIs with Swagger OpenAPI and generate data objects and access wrappers using swagger-js.

View

We will use a reactive framework. We are currently evaluating both Vue and React for this purpose. (We are moving forward with Vue). We will reimplementing a single component, the published history grid, in Vue as a prototype. See #4425.

[willdurand]

Prettier seems to be a better choice to enforce coding standards for many reasons but one of the best is: you let the tool do the work, and everyone follows that. Prettier takes your code and reprints it from scratch. So there's only one way code can be printed, not many. This is the same principle in Go and it makes everything easy. Prettier works with JS/JSX but also CSS.

[jxtx]

Awesome, go fmt was what I was going for here. Didn't know about Prettier, looks even better.

[willdurand]

We are currently evaluating both Vue and React for this purpose. We will reimplementing a single component, the published history grid, in Vue as a prototype. See #4425.

We discussed React vs Vue. Vue is currently considered a better fit as it seems easier at first (which is both interesting and important to onboard new contributors), and also it seems a better candidate to integrate with an existing codebase and avoid to rewrite everything from scratch. React seems to be a all-in solution, more complicated but with a better ecosystem though.

I do not think we should focus on React vs Vue but rather on data management solutions (and routing, maybe).

It would be great to have feedback from people who did Backbone => React/Redux or/and Backbone => Vue. The Galaxy web app is considered a rather large web app.

[doomedramen]

Vue is a much better fit for this project than React.

[mvdbeek]

So how should the workflow look like for the OpenAPI documentation ?
We place yaml descriptions of the API endpoint into the endpoint's docstring and use these to parse out a full specification?

[bgruening]

@wookoouk can you elaborate on this a little bit more :)

[doomedramen]

My reasoning for using Vue over React is the templating, if you go with React you are going to have everything bundled into a single js file, hidden away in the background. If you go with Vue you can use the template system to write shared/reusable components that can be used through out the client as well as by tool developers.

[doomedramen]

To clarify, will any part of the client UI be access able to 3rd parties such a tool developers? or ONLY for the core UI, no end user or tool developer access to use parts?

[martenson]

I do not have a horse in this race, I am excited to try any of these.

However I would like to try at least one template-less component, probably with JSX. (This is a personal goal). It could offer some testing advantages at least.

[doomedramen]

So, it has been cleared up to me that this framework choice is ONLY for the base UI, nothing that would be extendable or usable by tool developers.

[martenson]

@wookoouk there will probably be extension points, similar to how webhooks work now (at least functionally)

[hexylena]

@wookoouk

My reasoning for using Vue over React is the templating, if you go with React you are going to have everything bundled into a single js file, hidden away in the background. If you go with Vue you can use the template system to write shared/reusable components that can be used through out the client as well as by tool developers.

you can do all of that with react as well, no? "single js file" - code splitting achieved through webpack, any react component written could be re-used anywhere in the galaxy UI development, or imported and used outside of the galaxy project. I'm not sure how tool developers would be using UI components though.

[willdurand]

We will use simplify formatting using style standardization by Prettier, prettier --format flow --tab-width 4

I also like to have these two options: --single-quote --trailing-comma es5 (single quotes are often preferred and trailing comma is good for git diff).

[willdurand]

If you go with Vue you can use the template system to write shared/reusable components that can be used through out the client as well as by tool developers.

You can have a look at an excerpt of the available react components. It is simply not correct to say that Vue with its templating system implies more shareable/reusable modules.

To clarify, will any part of the client UI be access able to 3rd parties such a tool developers? or ONLY for the core UI, no end user or tool developer access to use parts?

The core is privileged if I understand correctly but the idea to provide easy "extension points" or ways to hook into the interface is kept in mind. It is still plain old CSS/JS ES5 and HTML5 in the browser, so basically everything is doable and "tweakable". Of course, there is a balance between maintainability, longevity and simplicity. Vue or React are equals in terms of inherent complexity though.

[martenson]

• Update on react licensing:

Honestly I think React is completely off the table at this point due to the license issues.

React is under Facebook's BSD+PATENTS license. Apache legal decided to put this in Category-X (do not use). See https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16088663&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16088663

^^ @jxtx on react licensing

• An article about transferring to vue:
  https://medium.com/reverdev/why-we-moved-from-angular-2-to-vue-js-and-why-we-didnt-choose-react-ef807d9f4163

[hexylena]

Just as counterpoint:

Other people have a different read on it, e.g. Automattic's general counsel Automattic/wp-calypso#650 (comment), as mentioned in this lawyer's post https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562

I.e: unless galaxyproject is planning to sue Facebook, the issues with patents will never affect us.

[willdurand]

Yeah, this patent thing is pointless for many reasons, but here it is not even questionable.

[jxtx]

We develop a software product that is used by others including commercial entities that could at any point in the future have IP issues with facebook, a massive corporation with incentives that are in no way aligned with ours. If Apache legal is still sufficiently concerned about this after all the debate and discussion, we should also be.

[hexylena]

@jxtx did you see "Update 2" in the medium post I linked? That gave me pause w/r/t alternatives.

[hexylena]

Edit: I'm not trying to be actively unhelpful with that comment, just that from a legal standpoint there are no good options in the react/vue space if you have this as a concern. Choosing vue will not make the underlying issue go away (the existence of patents on such technology (however nonsensical those may be), and their possible use in litigation against a company that uses galaxy and also sues facebook for their patents) since vue/preact could be killed by facebook's react patents if they so choose (though that seems unlikely)

[nuwang]

I was curious as to why why Angular 4 is not in the running? It has an MIT license, a reusable component abstraction (and quite importantly, component-local css handling and eventually WebComponents), has support for reactive paradigms and can be incrementally integrated into an existing application.

It has been used for CloudLaunch and despite the teething issues in the beta period that an article above also talks about, the experience has been largely positive.

The main advantage I see is that it's reasonably opinionated, which is probably a virtue in an open-source project like this since it encourages a standardised structure (sort of like Django), which allows for a contributor to hit the ground running, and yet is flexible enough to get out of the way when needed (also like Django).

[dannon]

Updating this issue to indicate the consensus as discussed on Gitter and elsewhere: We're going to move forward using Vue.js.

[hexylena]

I guess this is mostly resolved? We've committed to a direction and are running with it :)