AWS Elastic Beanstalk vs React

• AWS Elastic Beanstalk was easy to implement, we only had to insert the application code to have it up and running in a few minutes. This helps us to launch company campaigns for different areas such as marketing, commercial and human resources.
• It has a fast learning curve, since the training material of the platform is public on the manufacturer's portal, furthermore it is easy to interact and intuitive for developers.
• The productivity of the equipment is optimized since they are not worrying about preparing the platform or infrastructure, they only have to attend to what is required by the application and its operation and this maintenance.
• The indicators and metrics that it has, ensure that the application cannot be saturated and have a performance problem, with AWS Elastic Beanstalk the application can scale resources when needed automatically.

Read full review

• React is designed around the notion of generated html as opposed to templated html. This provides more flexibility in building elements on a page, and allows developers to create html that is programmatically configured based on runtime considerations.
• React uses JSX, which is HTML templating integrated into javascript code. This simplifies the generation of complex structures, especially those that vary based on runtime and interactive data.
• React is more efficient because it generates a virtual DOM rather than directly building in in the actual DOM. By building 'offline' in this manner, the DOM generation is faster. After building, it can be installed in one operation.
• React only builds those portions of the display that have changed, making display updates more efficient.

Read full review

• Limited to the frameworks and configurations that AWS supports. There is no native way to use Elastic Beanstalk to deploy a Go application behind Nginx, for example.
• It's not always clear what's changed on an underlying system when AWS updates an EB stack; the new version is announced, but AWS does not say what specifically changed in the underlying configuration. This can have unintended consequences and result in additional work in order to figure out what changes were made.

Read full review

• React could get very frustrating unless you start thinking in React. React enforces a top down hierarchy of data flow and offers no way for the data to communicate backwards. This is a big shift in mindset coming from Angular 1.x. This constraint is really a big factor that determines how to organize your code and how you might want to write your own Components.
• Because of the self imposed top down hierarchy, you end up having a heavy parents with dumb children. Because parents would need to the bulk of the work, they usually manage the state, while passing callbacks to the child components. If not properly designed, this could lead to the callback hell, where you could have callbacks passing through like multiple children.
• As with any library, you will have to iterate through multiple designs to come up with a ways to avoid "heavy parent components" in React. One obvious solution is using some open source tools like Redux, but we opted for a variation of it to suit our needs.

Read full review

• till now we had not Calculated ROI as the project is still evolving and we had to keep on changing the environment implementation
• it meets our purpose of quick deployment as compared to on-premises deployment
• till now we look good as we also controlled our expenses which increased suddenly in the middle of deployment activity

Read full review

• React sped up the time to implement new features, providing much better code-reuse across the team
• React's excellent performance made it so new components ran faster in the browser
• Since React is so popular, it's been easy to recruit new developers to the team who already have a familiarity with the library

Read full review