1. Maybe the most important decision before starting off
Why could choosing a suitable framework & programming language even decide whether your project will be successful or not? Actually, it's quite simple. Every programming language as well as framework has been created for a specific or a set of use-cases for which existing tools weren't sufficient enough. While some projects require high-security standards, other applications might need to be as fast as possible. Furthermore, time-to-market also plays an important role nowadays.
As there is an uncountable amount of programming languages and related frameworks out there which all try to address their own use-cases, you might realize that choosing the wrong one, could actually even compromise your project as your specific use-case might not be covered by that tech-stack sufficiently. Please note, that this blog post doesn't cover embedded devices or other less common platforms specifically to keep everything as simple as it can be.
2. Explicitly specify which devices you want to support
Over-Engineering is bad but what's even worse is not being prepared for new requirements which might affect your whole code-base or even infrastructure (e.g. data model). One mistake I see a lot is companies coding new applications for only one specific device category (e.g. mobile, or even just Android) as time-to-market seems to have priority no 1. Don't get me wrong here, fast development cycles can also have a signifikant impact whether your project will be successful or not, but don't neglect on which platforms your application should finally run. That's especially important to save a lot of time and resources in the long-run as you could choose e.g. hybrid-frameworks to have only one code-base or at least to share some code between both projects.
2.1. Desktop / Mobile
That's an interesting one. Most developers just start coding for one specific platform and have some vague conception if and how they want to support other devices at a later point of time. This approach could possibly help you to deliver a product faster than your competitors, but will certainly degrade the efficiency of developing new features in the long run as your employees have to fix unexpected platform-specific bugs (e.g. usability, UX, responsiveness, native features [e.g. geo-location, camera]), need to introduce work-arounds or because you even have to maintain two completely separated code-bases (e.g. when framework/programming language doesn't support mobile or reverse).
2.2. Android / iOS etc.
I'm guilty of this one too, but that's not an excuse. Software Engineers who don't consider themselves as iOS developers (and that's in general the majority) will usually neglect iOS native configurations, tests & plugins in case you choose to use a hybrid-framework such as React-Native, Ionic, Flutter, etc. This has multiple reasons. On one hand most developers don't have a MAC which is needed to debug, build and test an iOS app natively (otherwise some 3rd party emulators or Mac Virtual-Machines [which are also quite hard to setup & to maintain] are needed). If you choose a web-based mobile framework such as React Native with Expo or Ionic, you have at least the possibility to debug your "iOS" application in your browser or on your Android phone as it would look like on your iOS device (at least there shouldn't be too many differences). Just to emphasize this again; keep in mind that using a hybrid framework might cause your developers to neglect that platform which they are less comfortable with.
2.3. Special Purpose Devices
Smart TVs, Smart Watches or other less common devices often have an Android OS, which makes it quite easy to enlarge your audience. Nevertheless, you should always keep your use-case in mind as many apps are semantically useless on some devices (e.g. Pokemon GO on Smart TVs).
3. Set your priorities
Specify the actual use-case of your application. What do you want to achieve? What criteria will your customers use to rate your software? I've listed some general examples & recommendations to get you started, but please keep in mind that in the end everything depends solely on your specific use-case. Please note, that I've listed exclusively frameworks, I've personal experience with as I don't want to provide you with superficial knowledge. Furthermore, the actual performance, security etc. depends on the quality of the code your developers have written and not purely on the framework's characteristics.
3.1. "My application needs to be fast."
If your app needs to handle real-time data or has to run on low-end devices then you should always consider developing your applications natively. Fortunately, this doesn't necessarily mean that you cannot avoid having separate code-bases for each platform!
3.1.1. Mobile frameworks
Flutter -> If productivity and time-to-market isn't an issue then you could consider Flutter for native cross-platform development. Flutter uses Dart (syntax comparable to TypeScript) and will be compiled to native code which makes it pretty fast. Unfortunately, Flutter is still quite young which drastically reduces the amount of sufficient & up-to-date libraries, blog posts & forum postings you'll find related to your challenges.
3.1.2. Web frameworks
React with NextJS -> Yes, React is a library but NextJS isn't. Using React in combination with NextJS can be a quite powerful combination too as NextJS allows you to statically render, pre-render or even render your page on server-side (= SSR). Furthermore, React has a huge community which boosts developer productivity.
3.2. "My application needs to be secure."
The answer to this might differ depending on what kind of security you need. Keep in mind that frameworks which are widely used and have been around for a while tend to be more secure than fresh frameworks & programming languages.
Rust with Rocket -> Yes and yes, both are quite new and could be considered experimental. Therefore, the community is still relatively small. Moreover, Rust is even for more experienced coders quite challenging which could reduce developer productivity more than you might expect. Nevertheless, Rust is awesome as it made the "impossible" a reality -> A secure AND fast programming language. Because of memory management (e.g. Garbage collectors, ..) software engineers always had to choose between security and speed, this has now changed with their new memory-management concept called 'Ownership'. Because of this, many people (including me) see a lot of potential in Rust (which is currently backed by Mozilla).
There are a lot frameworks out there and I'm sure that some of you might have listed different frameworks here. That's fine. I've just listed my personal favorites which I have used in past projects. Moreover, I want to emphasize this again -> The actual choice of a programming language / framework depends on much more aspects than listed above such as your internal resources (e.g. which programming languages/frameworks do your software engineers have the most experience with -> developer productivity/time-to-market, ...).
German stream about choosing the right framework for your project.