To be clear, IMHO, Deno looks fine for what it is. The features are great. The cons ironically mostly boil down to "it's not node", i.e. ejecting a non-trivial app from CRA into some vite setup is doable with some effort, but migrating to Deno is, charitably, likely a monumental task that nobody would ever undertake, even considering the upsides.

At the risk of diving too deep into opinion territory, I'm not all that enthusiastic about isomorphic JS (and I say this as a someone who's worked on a isomorphic framework). The promise of low learning curve is certainly appealing, especially for those still in the learning phase, but at least in my experience I find that isomorphism falls a bit short in practice because server and client semantics are just... different.

When I talk about compatibility, I'm specifically talking about non-platform compatibility, i.e. library authors need to consciously target Deno if they want to support it, and the way to do so may be entirely non-trivial (e.g. the lengths that postgres.js goes to, compared to slonik, comes to mind). But most of the JS ecosystem lives on NPM and imports things willy-nilly with no regard for whether their thing will work in Deno because that's the path of least resistance. This is not Deno's fault of course, just an unfortunate reality.