You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@airavata.apache.org by "Christie, Marcus Aaron" <ma...@iu.edu> on 2017/02/03 21:31:12 UTC

Requirements for an updated portal architecture

Dev,

I’ve been taking feedback from other Airavata developers and working on requirements for a next generation architecture for the PGA. First I’ll list out the requirements as I see them. Then I will propose what I feel is a best fit for these requirements. Feedback on all of this is much appreciated.

Requirements

The following is a list of problems we would like to solve by adopting a new web framework. A new web framework here means both the backend framework for server side code as well as the frontend framework for client side code.

1. Have the ability to independently add new views to the portal. Framework should have some concept of modularity so new functionality can be added without having to make changes to other parts of the portal. This would facilitate new features moving into production faster.

2. Have the ability to make calls to Identity Server (SOAP) and Airavata (Thrift). Would be good if there is support for interacting with other remote computing protocols and HPC resources.

3. Be themable/skinnable and modular. Gateways should be able to customize the look and feel and make the portal their own. Gateways should be able to customize the functionality available in the portal, removing and adding just the functionality tailored for that specific gateway.

4. The backend framework should support different modes of web development: server-side rendered views as well as REST API for client side views.

5. The backend framework should be able to easily integrate with existing scientific codes for visualization and analysis. This would allow developing lightweight domain specific functionality within the portal itself.

6. The backend and frontend frameworks should have active communities and some longevity, helping to ensure continued support in the future.

7. The backend and frontend frameworks should have a gentle learning curve to promote onboarding new contributors. Setting up a local development environment should be relatively easy.

8. The frontend framework should allow the development of more sophisticated client side views:
• Domain specific and interactive views for configuring applications and viewing results
• Domain specific and interactive views for browsing, filtering and managing remote and personal data collections
• More up front validation of application configurations

Proposed solution

With these requirements I feel like Django as a backend framework and React as a frontend framework are the best fit. Here are the benefits I see of adopting Django:
* Django has a builtin concept of modularity, the application [1]. This would allow the independent development of new views for new funtionality (req 1) as well as making it possible to tailor a portal to a gateway’s needs (req 3).
* Django has a very active community and lots of off the shelf applications [2] that can be used to either quickly develop common portal functionality or to add gateway specific features
* Being written in Python means that the backend can easily integrate with Python scientific codes for quick data analysis and visualization tasks
* A side benefit of a Python based portal is the opportunity to develop a first class Airavata client in Python. This could enable scripts to take advantage of the Airavata API or Juptyer like interactions with the API.
* Django is well-documented and relatively straightforward to work with, easing on-boarding of new developers

Regarding React, I see these benefits:
* React is a much more powerful and scalable approach to web UI development than just using jQuery, which is what the current PGA uses. With React we can build UIs with a higher degree of interactivity. And we can build richer, more domain-specific interfaces.
* Unlike other JS frameworks that have a very large API to learn, the concepts and API surface of React is fairly small. The main challenge is learning to “think in React” [3]

Again, feedback on this is much appreciated.

Thanks,

Marcus

[1] https://docs.djangoproject.com/en/1.10/ref/applications/
[2] https://djangopackages.org/
[3] https://facebook.github.io/react/docs/thinking-in-react.html

Re: Requirements for an updated portal architecture

Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.

On Feb 7, 2017, at 11:01 AM, Amila Jayasekara <th...@gmail.com>> wrote:

Hi Marcus,

Nice summary of requirements.

Some questions inline.

On Fri, Feb 3, 2017 at 4:31 PM, Christie, Marcus Aaron <ma...@iu.edu>> wrote:
Dev,

I’ve been taking feedback from other Airavata developers and working on requirements for a next generation architecture for the PGA.  First I’ll list out the requirements as I see them. Then I will propose what I feel is a best fit for these requirements. Feedback on all of this is much appreciated.


Requirements

The following is a list of problems we would like to solve by adopting a new web framework.  A new web framework here means both the backend framework for server side code as well as the frontend framework for client side code.

I am little confused about the overall organization of the PGA. Isnt backend means Airavata ? (sorry i am outdated on most of the things).


Hi Amila,

Good question, I didn’t define that well. Here, by “backend framework” I mean the web server, the software the consumes HTTP requests and generates responses.  Backend frameworks examples: Django, Flask, Spring MVC, Rails, Laravel, etc.  The frontend framework is the JavaScript code that runs in the browser and typically communicates with the backend framework to provide dynamically updating content in the browser.  Frontend frameworks examples: Backbone, React, Ember, Angular, Vue, etc.

Thanks,

Marcus

Re: Requirements for an updated portal architecture

Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.

On Feb 7, 2017, at 11:09 AM, Amila Jayasekara <th...@gmail.com>> wrote:

Sorry, mistakenly pressed "Send" button before I finish typing :-).

Oops I answered your first question in the other email :) Further replies below.

On Tue, Feb 7, 2017 at 11:01 AM, Amila Jayasekara <th...@gmail.com>> wrote:
Hi Marcus,

Nice summary of requirements.

Some questions inline.

2. Have the ability to make calls to Identity Server (SOAP) and Airavata (Thrift). Would be good if there is support for interacting with other remote computing protocols and HPC resources.

I was under the impression that IS has a REST interface also. Anyhow I am not sure about this.
Also, what you meant by "support for interacting with other remote computing protocols and HPC resources" ? Can you give few examples ?
IMO, if Portal need any information from the HPC resource it should go through Airavata for security reasons and also for communication reasons. If resource host a web server to extract information, it is find get information directly from resource (without going through Airavata)

I think you are right that in general those requests should go through Airavata. Here are some examples I was thinking of:
* remote filesystem explorer over SFTP, GridFTP, Dropbox, etc. using the user’s own credentials
* pull in and display public catalogs of datasets

4. The backend framework should support different modes of web development: server-side rendered views as well as REST API for client side views.

6. The backend and frontend frameworks should have active communities and some longevity, helping to ensure continued support in the future.

7. The backend and frontend frameworks should have a gentle learning curve to promote onboarding new contributors. Setting up a local development environment should be relatively easy.

Proposed solution

Again, feedback on this is much appreciated.

Its kind of hard to evaluate any product without actually prototyping. Django seems promising. However, I found this [4], on Django. Not sure whether those are really valid arguments.

Yeah, I think prototyping is important. I’m currently working with Jun on just such a prototype for the GeoGateway.

I’ve seen similar complaints about Django in the past, but I’m not sure how much they still hold. That link you posted is almost 5 years old. A lot of the complaints I’ve seen are about Django’s ORM, but the PGA would for the most part not be using that since data is persisted through the Airavata API.

[4] https://news.ycombinator.com/item?id=4076834

Thanks,

Marcus

Re: Requirements for an updated portal architecture

Posted by Amila Jayasekara <th...@gmail.com>.

Sorry, mistakenly pressed "Send" button before I finish typing :-).

On Tue, Feb 7, 2017 at 11:01 AM, Amila Jayasekara <th...@gmail.com>
wrote:

> Hi Marcus,
>
> Nice summary of requirements.
>
> Some questions inline.
>
> On Fri, Feb 3, 2017 at 4:31 PM, Christie, Marcus Aaron <ma...@iu.edu>
> wrote:
>
>> Dev,
>>
>> I’ve been taking feedback from other Airavata developers and working on
>> requirements for a next generation architecture for the PGA.  First I’ll
>> list out the requirements as I see them. Then I will propose what I feel is
>> a best fit for these requirements. Feedback on all of this is much
>> appreciated.
>>
>>
>> Requirements
>>
>> The following is a list of problems we would like to solve by adopting a
>> new web framework.  A new web framework here means both the backend
>> framework for server side code as well as the frontend framework for client
>> side code.
>>
>
> I am little confused about the overall organization of the PGA. Isnt
> backend means Airavata ? (sorry i am outdated on most of the things).
>
>
>>
>> 1. Have the ability to independently add new views to the portal.
>> Framework should have some concept of modularity so new functionality can
>> be added without having to make changes to other parts of the portal. This
>> would facilitate new features moving into production faster.
>>
>> 2. Have the ability to make calls to Identity Server (SOAP) and Airavata
>> (Thrift).  Would be good if there is support for interacting with other
>> remote computing protocols and HPC resources.
>>
>
I was under the impression that IS has a REST interface also. Anyhow I am
not sure about this.
Also, what you meant by "support for interacting with other remote
computing protocols and HPC resources" ? Can you give few examples ?
IMO, if Portal need any information from the HPC resource it should go
through Airavata for security reasons and also for communication reasons.
If resource host a web server to extract information, it is find get
information directly from resource (without going through Airavata)


>
>> 3. Be themable/skinnable and modular. Gateways should be able to
>> customize the look and feel and make the portal their own. Gateways should
>> be able to customize the functionality available in the portal, removing
>> and adding just the functionality tailored for that specific gateway.
>>
>> 4. The backend framework should support different modes of web
>> development: server-side rendered views as well as REST API for client side
>> views.
>>
>> 5. The backend framework should be able to easily integrate with existing
>> scientific codes for visualization and analysis. This would allow
>> developing lightweight domain specific functionality within the portal
>> itself.
>>
>> 6. The backend and frontend frameworks should have active communities and
>> some longevity, helping to ensure continued support in the future.
>>
>> 7. The backend and frontend frameworks should have a gentle learning
>> curve to promote onboarding new contributors. Setting up a local
>> development environment should be relatively easy.
>>
>> 8. The frontend framework should allow the development of more
>> sophisticated client side views:
>>         • Domain specific and interactive views for configuring
>> applications and viewing results
>>         • Domain specific and interactive views for browsing, filtering
>> and managing remote and personal data collections
>>         • More up front validation of application configurations
>>
>>
>>
>> Proposed solution
>>
>> With these requirements I feel like Django as a backend framework and
>> React as a frontend framework are the best fit. Here are the benefits I see
>> of adopting Django:
>> * Django has a builtin concept of modularity, the application [1].  This
>> would allow the independent development of new views for new funtionality
>> (req 1) as well as making it possible to tailor a portal to a gateway’s
>> needs (req 3).
>> * Django has a very active community and lots of off the shelf
>> applications [2] that can be used to either quickly develop common portal
>> functionality or to add gateway specific features
>> * Being written in Python means that the backend can easily integrate
>> with Python scientific codes for quick data analysis and visualization tasks
>> * A side benefit of a Python based portal is the opportunity to develop a
>> first class Airavata client in Python. This could enable scripts to take
>> advantage of the Airavata API or Juptyer like interactions with the API.
>> * Django is well-documented and relatively straightforward to work with,
>> easing on-boarding of new developers
>>
>> Regarding React, I see these benefits:
>> * React is a much more powerful and scalable approach to web UI
>> development than just using jQuery, which is what the current PGA uses.
>> With React we can build UIs with a higher degree of interactivity. And we
>> can build richer, more domain-specific interfaces.
>> * Unlike other JS frameworks that have a very large API to learn, the
>> concepts and API surface of React is fairly small. The main challenge is
>> learning to “think in React” [3]
>>
>> Again, feedback on this is much appreciated.
>>
>
Its kind of hard to evaluate any product without actually prototyping.
Django seems promising. However, I found this [4], on Django. Not sure
whether those are really valid arguments.

Thanks
-Thejaka


>
>>
>> Thanks,
>>
>> Marcus
>>
>> [1] https://docs.djangoproject.com/en/1.10/ref/applications/
>> [2] https://djangopackages.org/
>> [3] https://facebook.github.io/react/docs/thinking-in-react.html
>
>
> [4] https://news.ycombinator.com/item?id=4076834

Re: Requirements for an updated portal architecture

Posted by Amila Jayasekara <th...@gmail.com>.

Hi Marcus,

Nice summary of requirements.

Some questions inline.

On Fri, Feb 3, 2017 at 4:31 PM, Christie, Marcus Aaron <ma...@iu.edu>
wrote:

> Dev,
>
> I’ve been taking feedback from other Airavata developers and working on
> requirements for a next generation architecture for the PGA.  First I’ll
> list out the requirements as I see them. Then I will propose what I feel is
> a best fit for these requirements. Feedback on all of this is much
> appreciated.
>
>
> Requirements
>
> The following is a list of problems we would like to solve by adopting a
> new web framework.  A new web framework here means both the backend
> framework for server side code as well as the frontend framework for client
> side code.
>

I am little confused about the overall organization of the PGA. Isnt
backend means Airavata ? (sorry i am outdated on most of the things).


>
> 1. Have the ability to independently add new views to the portal.
> Framework should have some concept of modularity so new functionality can
> be added without having to make changes to other parts of the portal. This
> would facilitate new features moving into production faster.
>
> 2. Have the ability to make calls to Identity Server (SOAP) and Airavata
> (Thrift).  Would be good if there is support for interacting with other
> remote computing protocols and HPC resources.
>
> 3. Be themable/skinnable and modular. Gateways should be able to customize
> the look and feel and make the portal their own. Gateways should be able to
> customize the functionality available in the portal, removing and adding
> just the functionality tailored for that specific gateway.
>
> 4. The backend framework should support different modes of web
> development: server-side rendered views as well as REST API for client side
> views.
>
> 5. The backend framework should be able to easily integrate with existing
> scientific codes for visualization and analysis. This would allow
> developing lightweight domain specific functionality within the portal
> itself.
>
> 6. The backend and frontend frameworks should have active communities and
> some longevity, helping to ensure continued support in the future.
>
> 7. The backend and frontend frameworks should have a gentle learning curve
> to promote onboarding new contributors. Setting up a local development
> environment should be relatively easy.
>
> 8. The frontend framework should allow the development of more
> sophisticated client side views:
>         • Domain specific and interactive views for configuring
> applications and viewing results
>         • Domain specific and interactive views for browsing, filtering
> and managing remote and personal data collections
>         • More up front validation of application configurations
>
>
>
> Proposed solution
>
> With these requirements I feel like Django as a backend framework and
> React as a frontend framework are the best fit. Here are the benefits I see
> of adopting Django:
> * Django has a builtin concept of modularity, the application [1].  This
> would allow the independent development of new views for new funtionality
> (req 1) as well as making it possible to tailor a portal to a gateway’s
> needs (req 3).
> * Django has a very active community and lots of off the shelf
> applications [2] that can be used to either quickly develop common portal
> functionality or to add gateway specific features
> * Being written in Python means that the backend can easily integrate with
> Python scientific codes for quick data analysis and visualization tasks
> * A side benefit of a Python based portal is the opportunity to develop a
> first class Airavata client in Python. This could enable scripts to take
> advantage of the Airavata API or Juptyer like interactions with the API.
> * Django is well-documented and relatively straightforward to work with,
> easing on-boarding of new developers
>
> Regarding React, I see these benefits:
> * React is a much more powerful and scalable approach to web UI
> development than just using jQuery, which is what the current PGA uses.
> With React we can build UIs with a higher degree of interactivity. And we
> can build richer, more domain-specific interfaces.
> * Unlike other JS frameworks that have a very large API to learn, the
> concepts and API surface of React is fairly small. The main challenge is
> learning to “think in React” [3]
>
> Again, feedback on this is much appreciated.
>
>
> Thanks,
>
> Marcus
>
> [1] https://docs.djangoproject.com/en/1.10/ref/applications/
> [2] https://djangopackages.org/
> [3] https://facebook.github.io/react/docs/thinking-in-react.html

Re: Requirements for an updated portal architecture

Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.

Dave,

I think Vue is a great suggestion.  I’m not that familiar with it but from what I’ve seen it does seem to have a lot of the benefits of React while also being easier to use.

Things I see in favor of React:
* older, more mature. I have to admit I’ve seen a lot of “flavor of the month” JS frameworks come and go, so I tend to be biased toward older, more established frameworks.
* backed by Facebook whereas Vue is primarily developed by one guy
* the ecosystem around React, for example, things like React Native which could be used to create native app clients to Airavata while reusing PGA code

Things I see in favor of Vue:
* simpler to get into
* no transpilation required, so the tooling requirements could be much simpler, again making it easier to get into
* “batteries included”: there is an official vue state management library (vuex), official router, official cli

I think it would be interesting to try them both, since I don’t have much experience with React and none with Vue.  Maybe use one for one view and the other for a different view, just to get a feel for them.  Then it should be easier to make a decision. I also advocate for separating the JS models and business logic from any framework code so that whatever UI framework we use is decoupled and just a view layer on top. So switching from one UI framework to another should be relatively simple.

Thanks,

Marcus

> On Feb 6, 2017, at 1:08 PM, Reagan, David Michael <dm...@iu.edu> wrote:
> 
> Hi Marcus, devs,
> 
> I'd also suggest taking a look at Vue[1] for the front end. See [2] and [3] for a couple of comparisons between Vue and React. I haven't used either yet, but from what I understand they are quite similar. The primary differences seem to be that the React community is larger, but that Vue is easier to get into. In particular, if a goal for the PGA is for developers to be able to jump in and quickly customize it to their needs, Vue's HTML templates might be easier to learn than React's JSX-based component system. It also seems to be easier to slowly add bits of Vue to a site over time, while React really requires full buy-in from the beginning. 
> 
> Dave
> 
> 
> [1] https://vuejs.org/
> [2] https://vuejs.org/v2/guide/comparison.html
> [3] https://medium.com/js-dojo/react-or-vue-which-javascript-ui-library-should-you-be-using-543a383608d
> --
> David Reagan
> Advanced Visualization Lab
> Indiana University
> avl.iu.edu
> 
> The Advanced Visualization Lab is part of the Research Technologies division of UITS; Research Technologies is a PTI Cyberinfrastructure & Service Center.
> 
> ________________________________________
> From: Christie, Marcus Aaron <ma...@iu.edu>
> Sent: Friday, February 3, 2017 4:31 PM
> To: dev@airavata.apache.org
> Subject: Requirements for an updated portal architecture
> 
> Dev,
> 
> I’ve been taking feedback from other Airavata developers and working on requirements for a next generation architecture for the PGA.  First I’ll list out the requirements as I see them. Then I will propose what I feel is a best fit for these requirements. Feedback on all of this is much appreciated.
> 
> 
> Requirements
> 
> The following is a list of problems we would like to solve by adopting a new web framework.  A new web framework here means both the backend framework for server side code as well as the frontend framework for client side code.
> 
> 1. Have the ability to independently add new views to the portal. Framework should have some concept of modularity so new functionality can be added without having to make changes to other parts of the portal. This would facilitate new features moving into production faster.
> 
> 2. Have the ability to make calls to Identity Server (SOAP) and Airavata (Thrift).  Would be good if there is support for interacting with other remote computing protocols and HPC resources.
> 
> 3. Be themable/skinnable and modular. Gateways should be able to customize the look and feel and make the portal their own. Gateways should be able to customize the functionality available in the portal, removing and adding just the functionality tailored for that specific gateway.
> 
> 4. The backend framework should support different modes of web development: server-side rendered views as well as REST API for client side views.
> 
> 5. The backend framework should be able to easily integrate with existing scientific codes for visualization and analysis. This would allow developing lightweight domain specific functionality within the portal itself.
> 
> 6. The backend and frontend frameworks should have active communities and some longevity, helping to ensure continued support in the future.
> 
> 7. The backend and frontend frameworks should have a gentle learning curve to promote onboarding new contributors. Setting up a local development environment should be relatively easy.
> 
> 8. The frontend framework should allow the development of more sophisticated client side views:
>        • Domain specific and interactive views for configuring applications and viewing results
>        • Domain specific and interactive views for browsing, filtering and managing remote and personal data collections
>        • More up front validation of application configurations
> 
> 
> 
> Proposed solution
> 
> With these requirements I feel like Django as a backend framework and React as a frontend framework are the best fit. Here are the benefits I see of adopting Django:
> * Django has a builtin concept of modularity, the application [1].  This would allow the independent development of new views for new funtionality (req 1) as well as making it possible to tailor a portal to a gateway’s needs (req 3).
> * Django has a very active community and lots of off the shelf applications [2] that can be used to either quickly develop common portal functionality or to add gateway specific features
> * Being written in Python means that the backend can easily integrate with Python scientific codes for quick data analysis and visualization tasks
> * A side benefit of a Python based portal is the opportunity to develop a first class Airavata client in Python. This could enable scripts to take advantage of the Airavata API or Juptyer like interactions with the API.
> * Django is well-documented and relatively straightforward to work with, easing on-boarding of new developers
> 
> Regarding React, I see these benefits:
> * React is a much more powerful and scalable approach to web UI development than just using jQuery, which is what the current PGA uses. With React we can build UIs with a higher degree of interactivity. And we can build richer, more domain-specific interfaces.
> * Unlike other JS frameworks that have a very large API to learn, the concepts and API surface of React is fairly small. The main challenge is learning to “think in React” [3]
> 
> Again, feedback on this is much appreciated.
> 
> 
> Thanks,
> 
> Marcus
> 
> [1] https://docs.djangoproject.com/en/1.10/ref/applications/
> [2] https://djangopackages.org/
> [3] https://facebook.github.io/react/docs/thinking-in-react.html

Re: Requirements for an updated portal architecture

Posted by "Reagan, David Michael" <dm...@iu.edu>.

Hi Marcus, devs,

I'd also suggest taking a look at Vue[1] for the front end. See [2] and [3] for a couple of comparisons between Vue and React. I haven't used either yet, but from what I understand they are quite similar. The primary differences seem to be that the React community is larger, but that Vue is easier to get into. In particular, if a goal for the PGA is for developers to be able to jump in and quickly customize it to their needs, Vue's HTML templates might be easier to learn than React's JSX-based component system. It also seems to be easier to slowly add bits of Vue to a site over time, while React really requires full buy-in from the beginning. 

Dave


[1] https://vuejs.org/
[2] https://vuejs.org/v2/guide/comparison.html
[3] https://medium.com/js-dojo/react-or-vue-which-javascript-ui-library-should-you-be-using-543a383608d
--
David Reagan
Advanced Visualization Lab
Indiana University
avl.iu.edu

The Advanced Visualization Lab is part of the Research Technologies division of UITS; Research Technologies is a PTI Cyberinfrastructure & Service Center.

________________________________________
From: Christie, Marcus Aaron <ma...@iu.edu>
Sent: Friday, February 3, 2017 4:31 PM
To: dev@airavata.apache.org
Subject: Requirements for an updated portal architecture

Dev,

I’ve been taking feedback from other Airavata developers and working on requirements for a next generation architecture for the PGA.  First I’ll list out the requirements as I see them. Then I will propose what I feel is a best fit for these requirements. Feedback on all of this is much appreciated.


Requirements

The following is a list of problems we would like to solve by adopting a new web framework.  A new web framework here means both the backend framework for server side code as well as the frontend framework for client side code.

1. Have the ability to independently add new views to the portal. Framework should have some concept of modularity so new functionality can be added without having to make changes to other parts of the portal. This would facilitate new features moving into production faster.

2. Have the ability to make calls to Identity Server (SOAP) and Airavata (Thrift).  Would be good if there is support for interacting with other remote computing protocols and HPC resources.

3. Be themable/skinnable and modular. Gateways should be able to customize the look and feel and make the portal their own. Gateways should be able to customize the functionality available in the portal, removing and adding just the functionality tailored for that specific gateway.

4. The backend framework should support different modes of web development: server-side rendered views as well as REST API for client side views.

5. The backend framework should be able to easily integrate with existing scientific codes for visualization and analysis. This would allow developing lightweight domain specific functionality within the portal itself.

6. The backend and frontend frameworks should have active communities and some longevity, helping to ensure continued support in the future.

7. The backend and frontend frameworks should have a gentle learning curve to promote onboarding new contributors. Setting up a local development environment should be relatively easy.

8. The frontend framework should allow the development of more sophisticated client side views:
        • Domain specific and interactive views for configuring applications and viewing results
        • Domain specific and interactive views for browsing, filtering and managing remote and personal data collections
        • More up front validation of application configurations



Proposed solution

With these requirements I feel like Django as a backend framework and React as a frontend framework are the best fit. Here are the benefits I see of adopting Django:
* Django has a builtin concept of modularity, the application [1].  This would allow the independent development of new views for new funtionality (req 1) as well as making it possible to tailor a portal to a gateway’s needs (req 3).
* Django has a very active community and lots of off the shelf applications [2] that can be used to either quickly develop common portal functionality or to add gateway specific features
* Being written in Python means that the backend can easily integrate with Python scientific codes for quick data analysis and visualization tasks
* A side benefit of a Python based portal is the opportunity to develop a first class Airavata client in Python. This could enable scripts to take advantage of the Airavata API or Juptyer like interactions with the API.
* Django is well-documented and relatively straightforward to work with, easing on-boarding of new developers

Regarding React, I see these benefits:
* React is a much more powerful and scalable approach to web UI development than just using jQuery, which is what the current PGA uses. With React we can build UIs with a higher degree of interactivity. And we can build richer, more domain-specific interfaces.
* Unlike other JS frameworks that have a very large API to learn, the concepts and API surface of React is fairly small. The main challenge is learning to “think in React” [3]

Again, feedback on this is much appreciated.


Thanks,

Marcus

[1] https://docs.djangoproject.com/en/1.10/ref/applications/
[2] https://djangopackages.org/
[3] https://facebook.github.io/react/docs/thinking-in-react.html