Blitz.js is an amazing solution to being able to write a full-stack JS/TS product. It’s very easy to get started, easy to understand, and provides everything smaller or medium-sized projects need out-of-the-box. I’ve also used the documentation and so far most questions I had were answered in it in an easy to understand and implement way. I’ve personally used it to build an MVP for a simple web app with a couple of views, including list, detail, edit, and delete. I unfortunately didn’t get to use it for a bigger project yet, which makes sense given that it’s a pretty new and bleeding-edge framework. This might actually make it hard to convince a bigger company to adopt it for anything, but usually as the technology matures this gets less and less of an issue. Speaking from my own experience with learning blitz, I’d say that for a mid-level (or higher, of course) frontend developer, getting started with blitz and being able to develop your first feature should only take a couple hours. Personally, it took me 6 hours of experimenting on a random project to be prepared enough that after another 12 hours, I had an entire MVP for a small web app ready, including sign-in, sign-up, adding items, showing items, editing, deleting, modals, and integrating a UI framework (Chakra UI in this case). I’d say that’s an insanely fast learning curve for a full-stack web application framework. In my opinion, this is due to it being structured in an easy to understand way and the fact that it even eliminates the need to write an API. Blitz blurs the line between backend and frontend, so that instead of making an API call, you’d just import the relevant backend code and the framework handles the entire API calls transparently in the background. This gives blitz the advantage that you won’t need to do a lot of the boilerplate around obtaining data. In combination with the automatically generated typescript types, it also meant that my project’s pipelines and local development environment immediately noticed when there’s still outdated code related to recent changes. For conventional setups with different frameworks or languages for front- and backend, that would be a lot of effort to get perfectly right. For blitz, this effort is reduced to basically zero. Frontend-wise, blitz.js builds on top of React, which is a very solid foundation and has best-in-class tooling and library support as well as perfect prop validation via TypeScript types which plays well with blitz’ automation regarding typing the backend "api calls". The main downside in my experience is that it’s convention over configuration, which would make some enterprise-level requirements like multiple database backends besides postgres impossible. However, this is a great benefit for smaller projects that don’t need this surplus complexity and where developers are mostly glad that all the necessary decisions were already made for them. The documentation is great, and the project is (as of 2021) still in very active development. All-in-all, I’d recommend blitz for any small to medium-size project, and I think that it’s especially useful for MVPs as those can be built in hours or days.
React is a solid choice for any size of project or company. It’s very stable, flexible, and most importantly has the best tooling, IDE, and library support out of any modern frontend framework. I’ve personally used it pretty much since it came out, back when one would still have to manually configure babel to transpile the JSX. I still prefer it for any purpose due to its great tooling support and due to JSX being the standard by now that’s supported by everyone. I think the basic architecture of react as well as the flux pattern are well thought-through and offer a solid foundation to build upon. It’s especially great for companies as the job market for react developers is one of the largest and hiring experienced people (given adequate salary) should not be an issue. Most experienced frontend developers have already worked with react and it should be easy to get them familiar with react codebases. Personally, I think this is a great reason to choose a framework, as I’ve worked with companies that unfortunately picked lesser-known (and IMO objectively worse) frameworks like vue. That leads to them either having to hire non-vue developers or not being able to find anyone who fits the position well. In fact, most of the best developers they managed to hire were react users that just used their knowledge to work with vue. However, it’s often worse to find someone who’s good at something just to have to teach them something else, so react has a big advantage here. Tooling like eslint, typescript, sass, etc. is easily integrated and react as well as JSX/TSX templates are natively supported by all major tools. This is a big contrast to other frameworks I used like vue, which are struggling on this aspect due to their non-standard file types (vue single-file-components) and custom template syntax. I’ve personally struggled for days upon days with solving basic issues like building vue libraries with composition API, linting vue files, dead code elimination, compiling JSX-in-vue, integrating typescript, etc. that would’ve been trivial to do in react. React thankfully has none of these issues as the proper tooling already exists and is well documented. The biggest issue with react is also it’s biggest strength. You can use it with pretty much any patterns or library you’d like. This means that it’s incredibly flexible, but also that it can be a bit of a hassle to pick the exactly right choice for your particular project. Personally, this has impacted me by having to pick (and explain to the team) between different store patterns, sub-frameworks, libraries, etc.. It also frequently happens that for some reason I had to end-up switching mid-development to a different pattern or library, because the one that was previously chosen had unfixable issues. This effort goes down dramatically over time though, and most teams will be okay with picking the most common choices (e.g. redux). All the react developer tools I used are great and a lot less buggy than the competition (looking at you, vue dev tools). All in all, it’s a solid choice for any project in need of a frontend framework. There’s even full-stack frameworks like blitz.js available for small to medium-size or MVP-style projects.
To me the hype around Vue is completely overblown. It's just like React, except that it lacks the same community, a massive variety of libraries, and is not backed by a massive public company (Facebook). It's always seemed to me that people want to be trendy and use Vue because it was new and "cool" not because it was superior to React.