Material UI vs Meteor

As our team will be building a web application, HTML5 and CSS3 are one of the standardized combinations to implement the structure and the styling of a webpage. Material-UI comes with all sorts of predesigned web components such as buttons and dropdowns that will save us tons of development time. Since it is a component library designed for React, it suits our needs. However, we do acknowledge that predesigned components may sometimes cause pains especially when it comes to custom styling. To make our life even easier, we also adopted Tailwind CSS. It is a CSS framework providing low-level utility classes that will act as building blocks when we create custom designs.

Fonts and typography are fun. Material Design is a framework (developed by Google) that basically geeks out on how to assemble your typographical elements together into a design language. If you're into fonts and typography, it's fantastic. It provides a theming engine, reusable components, and can pull different user interfaces together under a common design paradigm. I'd highly recommend looking into Borries Schwesinger's book "The Form Book" if you're going to be working with Material UI or are otherwise new to component design.

https://www.amazon.com/Form-Book-Creating-Printed-Online/dp/0500515085

This basically came down to two things: performance on compute-heavy tasks and a need for good tooling. We used to have a Meteor based Node.js application which worked great for RAD and getting a working prototype in a short time, but we felt pains trying to scale it, especially when doing anything involving crunching data, which Node sucks at. We also had bad experience with tooling support for doing large scale refactorings in Javascript compared to the best-in-class tools available for Java (IntelliJ). Given the heavy domain and very involved logic we wanted good tooling support to be able to do great refactorings that are just not possible in Javascript. Java is an old warhorse, but it performs fantastically and we have not regretted going down this route, avoiding "enterprise" smells and going as lightweight as we can, using Jdbi instead of Persistence API, a homegrown Actor Model library for massive concurrency, etc ...