# Why Marko doesn't use JSX

## Why would we use JSX?

- Familiarity with JSX coming from other frameworks that use it
- Solid probably owes some of its success to "looking like React"
- Vue added JSX for this reason?
- We get tooling for "free"
- Tools we've had to build (and now maintain)
- typescript checker (mtc)
- prettier
- htmljs-parser
- tmbundle (syntax highlighting)
- Language Server
- VS Code Plugin
- What we're still missing
- eslint
- treesitter
- Other Editor Plugins (IntelliJ, etc.)
- Various syntax highlighters
- AI tools are familiar with JSX

## Still don't get everything for free

- Using a different runtime vs React means we still need runtime integrations (other frameworks that use JSX still have to build all of these).
- Existing Tools we'd still need even if we used JSX
- Typescript Definitions
- Jest/Mocha/Vitest
- Testing Library
- Lasso/Rollup/Webpack/Vite/etc. (or at least a babel preset)
- Component Libraries (ebayui)
- Utilities (graphql, etc.)
- Storybook
- Meta Framework (Marko Run)
- Tools we wish we had that would still need to be built
- Figma Code Connect
- AI tools may still try to write React JSX instead of Marko JSX (and could potentially be _more_ confused by the similarities?)
- Tooling that is for JSX often makes React-specific assumptions
- VS Code has a [refactoring tool](https://x.com/gnapse/status/1630685389395566600) that breaks Solid code
- "Getting the right types for the JSX has been a bit of struggle since Solid compiles it very differently than a Virtual DOM" - [Ryan](https://github.com/solidjs/solid/issues/74#issuecomment-531573713)

## Benefits of Marko's Language over JSX

- Tag Variables
- Components can render _and_ provide values
- Tree-aware helpers
- React team [wanted to add new syntax](https://gist.github.com/trueadm/17beb64288e30192f3aa29cad0218067#file-adopt-syntax-js-L8) to support providing values from a child component without extreme nesting, eventually landed on adding "hooks", introducing a new concept with some [stipulations](https://react.dev/reference/rules/rules-of-hooks)
- Every "hook" can be written as a component with renderprops in React, it would just be more verbose to use
- Also highlights a benefit of controlling the language: we can continue to extend it where it makes sense - React has lost control of JSX (which has its pros and cons)
- No special `ref` (or `key` in Marko 5)- Native Elements just expose their HTMLElement as a variable
- Superior Typescript Support
- Control flow type narrowing (vs. [Solid](https://github.com/solidjs/solid/discussions/1527))
- Typed element references
- in React you have to do [this](https://www.totaltypescript.com/strongly-type-useref-with-elementref) (which most people don't even know you can do to infer the correct type), but Marko's tag variables automatically infer their type
- Static Analysis
- JSX implies sequential execution order (even the React Forget compiler maintains this, despite injecting various optimizations & cached expressions)
- The Marko language lends itself to fine-grained compilation much more effectively than JSX does
- Authoring experience
- [Less code](https://component-party.dev/)
- Copy-paste HTML

## Why we don't think we should use JSX

- Some people choose and enjoy Marko (and other non-JSX frameworks like Svelte/Vue/Angular) _because_ it's not JSX
- Compiling to a JavaScript output that represents the _semantics_ of the Marko Language has proven to be a successful approach to leveraging tools built for the JS ecosystem, then mapping errors/messages back to the original `.marko` using SourceMaps
- This strategy was employed for TypeScript Support
- Same strategy used by David Campion to support ESLint
- Would save us _some_ work, but not as much as one might think