James Bender

Full disclosure; I worked for both Telerik and Infragistics in Developer Relations for these projects. From my point of view, neither is a clear "winner" in this space. Kendo has some nice features and Ignite doesn't have and vice versa. We ended up picking Kendo because we needed to settle on one of these, and most of our clients already owned Kendo because it came with some other Telerik product. That's it. It could have very easily gone the other way, but Telerik kinda won the ground war here, so...

Having said that, the only tool we really use is the grid (the rest of them are no better than Flowbite/HTML5/etc. controls. And even then, we really need to be leveraging the advanced functionality of the grid before telling the client they'll have to buy a support license.

We have a few clients that have some backend processes that require a bit more horsepower than Node/JavaScript can provide. We've settled on Rust for those situations due to the active community, the performance, and that so many on the team found the language easy to get used to. To be clear, we do NOT use this for general web development. We use it for long-running, resource-intense processes where we would like it to finish in minutes as opposed to hours.

I started out when the industry was asking "Who's going to win the platform wars? Will it be Java or .NET?" It was JavaScript. In spite of pressure from many "blue-pills" in our organization and my personal orbit, JavaScript has a firm grip on the forseable future of web development. It's easier to find developers at any bill rate, there's so much tooling around it that makes it easy to use, and there's an undeniable "cool factor" which makes it a win across the board.

For Android development in situations where it makes more sense than Java.

For Android development. Google recommends it over Java, and most of the Android developers I've spoken to prefer it as well.

I used (tried to use) PayPal on one project and it was a total nightmare. At the time there was no cohesive "one" web-based product, you had to choose between three and the lines between them were very muddled. We reached out to developer support several times and they were no help at all. The documentation was old (incorrect) and confusing. Granted this was several years ago, but the pain remains. Given a choice of using PayPal and sticking hot needles in my eyes, I would first ask "How big and hot are these needles we're talking about?" Stripe is SO much easier!

While we've added this to the stack, we're not using it 100% of the time. There's definitely a "tipping point" in terms of the number and complexity of forms where Formik starts to show value. Beneath that point, it actually creates a larger package size and becomes more verbose and overwrought when creating a simple form. YMMV.

Same syntax, faster execution, and some React-sugar. Easy choice. Except for the snapshot testing. Great idea, but a lot of developers over-rely on them and use them in places where they shouldn't. They are a handy OCCASIONAL enhancement for unit tests, not a replacement for them.

Bootstrap is a great idea until your designer wants something that doesn't fit neatly into a 12 column paradigm. Then things start to get difficult. We've had to add customizations and tweaks to Bootstrap-ed HTML that by the time we were done, we would have been better off just going straight CSS. Bootstrap helps with responsiveness, but again, it's an "80/20" solution at best. And that 20 percent can be a nightmare. Plus, most clients have this odd belief that you just drop Bootstrap into an app, and abracadabra, your site is totally responsive over every type of screen and form factor in existence. This is not the case. We have had MUCH better and faster results with Tailwind CSS. Our designers are happy we're not trying to force them into a Bootstrap-friendly design, and even with responsive sites, development has been easier and faster.

Our application data all goes in SQL. We will use something like Cosmos or Couch DB if one or both of these conditions are true: * We need to ingest a large amount of bulk data from a third party, and integrating it straight into an RDBMS with referential integrity checks would create a performance hit * We need to ingest a large amount of data that does not have a clearly defined, or consistent schema. In either case, we will have a process that migrates the data from Cosmos/Couch to SQL in a way that doesn't create a noticeable performance hit and ensures that we are not introducing bad data to the system. Because of this, there is a third condition that must be met: the data that is coming in must be something that the users will not need immediately, i.e. stock ticker information, real-time telemetry from other systems for performance/safety monitoring, etc.