create-react-app-esbuild VS next-mdx-enhanced

Unfortunately it's not officially supported (as usual in CRA world), so you have to resort to one of the config rewriters. I've been using this⁰ and only had one problem with numeric enums in TypeScript. I don't remember the exact issue, but it was my own stupidity, and was easy to fix.

[0] https://github.com/pradel/create-react-app-esbuild/tree/main...

I recommend this way because it's easier and stabler. Just see this short doc.

Like @next/mdx, you add next-mdx-enhanced to the project by exporting a function in the project's next.config.js file.

I don't have any experiences with the other libraries (e.g. next-mdx-enhanced, next-mdx-remote) so I won't judge the pros and cons of one compared to the others.

React & next.js are worth evaluating. It's a super powerful full stack with everything from server side rendered data (REST APIs even) all the way to complete SPAs, all using the same react components. It's a slick little swiss-army knife that can make anything from a basic blog with markdown content, to a static marketing page, to a full client-first PWA experience.

MDX is another neat step, it's markdown + react components and fits in very well with next.js: https://github.com/hashicorp/next-mdx-enhanced

Vue, and Svelte to just get an idea of what other components systems are like. They're all equally capable and just have different tradeoffs and styles. Keep an eye on Svelte in particular as its next.js-like system (SvelteKit) is working on a major revamp to be serverless-first and is quite interesting. Once you learn one component system it's easy to switch between them all--they're all cribbing and building on top of each other's ideas. The whole space is innovating in a great way.

Web components are tood to learn and compare to component frameworks above. It's still a changing space but points to a nice future where we can all just publish and share components.