The project is a web gadget previously made using vanilla script and JQuery, It is a part of the "Quicktext" platform and offers an in-app live & customizable messaging widget. We made that remake with React eco-system and Typescript and we're so far happy with results. We gained tons of TS features, React scaling & re-usabilities capabilities and much more!

What do you think?

I've an eCommerce platform building using Laravel, MySQL and jQuery. It's working good and if anyone become interested, I just deploy the entire source cod e in environment / Hosting. This is not a good model of course. Because everyone ask for small or large amount of change and I had to do this. Imagine when there will be 100 separate deploy and I had to manage 100 separate source. So How do I make my system architecture so that I'll have a core / base source code. To make any any change / update on specific deployment, it will be theme / plugin / extension based . Also if I introduce an API layer then I could handle the Web, Mobile App and POS as well ? Is the API should be part of source code or a individual single API and all the deployment will use that API ?

When I started TipMe, I thought about using React frontend. At the end, plain, simple jQuery won.

I had to build this iteration of the site fast and by using jQuery I could keep using Django as a full stack development tool. One important point is Django form (combined with Django Bootstrap3) means that I don't have to reinvent form rendering again, which will be the case with React.

Over time, more interactivity seeped into the site and React components start making its way into the codebase.

I now wish the site is built using React so that I could add more user friendly interfaces easier (no more fuddling with server states) but I would still say jQuery helped me get past those early days.

React was a very contentious decision among the Meteor community. We started off with Blazejs, which itself was based off of Handlebars. We liked the HTML-like syntax of Blaze and how nurses, doctors, and other clinicians could become familiar with it. However, the code wasn't very reusable and it was neither modular nor composeable nor testable, and became a major headache to maintain. React solves the problems of composeability and reusability and testing isolation, at the price of having worked the problem backwards and having wound up with a quirky syntax that runs within Javascript that looks similar to HTML but isn't. Nonetheless, React is quickly become a classic example of functional programming techniques, what with its' pure components. All in all, an enjoyable technology to work with that brings some sanity to front-end user interfaces.

We chose React on the advice of the Meteor Development Group, which acts as our upstream technical advisors. We had a prior investment in BlazeJS, due to it's optimistic UI, latency compensation, and real-time updates. However, the BlazeJS code wasn't composable and didn't lead to good reuse, as it was already overly abstracted. It also carried with it a lot of baggage from the default HTML DOM. We have enjoyed React's functional components, deterministic rendering, testability, composability, and widespread support. It's taken some time to get used to, but fits in very well with a functional programming style. We had also taken a look at AngularJS components, but they were always half-baked in comparison to the active React community.