Component per file pattern

I was wondering, what's the reason for choosing the "react-style" source code layout of components - as opposed to a more Svelte-like code layout, where every file is implicitly a component that can be instantiated?
To illustrate what I mean - taking this example:
import { useState } from<EMAIL_ADDRESS>
export default function MyComponent(props) {
  const [name, setName] = useState("Steve");

  return (

      <input
        css={{
          color: "red",
        }}
        value={name}
        onChange={(event) => setName(event.target.value)}
      />
      Hello! I can run in React, Vue, Solid, or Liquid!

  );
}

You could instead have something like:
let name = "Steve";

function setName(event) {
  name = event.target.value;
}

export default (

    <input
      css={{
        color: "red",
      }}
      value={name}
      onChange={setName}
    />
    Hello! I can run in React, Vue, Solid, or Liquid!

);

Obviously this isn't meaningful Typescript on it's own - this pattern assumes a component-per-file pattern (which most people will likely prefer anyway) and the compiler would take care of all the instance-related stuff, binding variables to reactive state containers, etc.
Since your intermediary format is just JSON, implementing something like this wouldn't require much more than the TS parser API and an analysis layer that identifies reactive variables and so on.
Thoughts? 🙂

For future readers: one thing this really helps solve is understanding that:

Mitosis is not react
Mitosis is static, declarative, and each file can only have one component. There are currently a lot of gotchas if you treat mitosis like react and try to add all kind of random variable declarations, multiple components in a file, etc which this helps make the rules more intuitive in clear

after thinking this over for a week I'm of the mindset that Mitosis 100% needs to follow React patterns as much as it can.
The reason is that people don't want to use anything other than react right now because of the ecosystem. New hires know react. College students know React. everyone knows React's API. Anything react-style should be supposed and converted to other frameworks.
Doing so will allow any company to move away from React so devs won't be blocked by "the ecosystem". It's the fastest way to get any new framework adopted since devs can easily experiment with any framework and run their A/B tests to really compare them
cc @steve8708

I wasn't proposing this syntax replace the existing syntax.
Mitosis has multiple output formats - no reason it couldn't have multiple input formats as well.

agreed @PatrickJS 100%. this was the initial motivation and this is really helpful validation. and agreed with you too @mindplay-dk - we can absolutely have multiple syntaxes, just at the cost of documentation etc needing to show multiple ways of doing things
so something we can absolutely explore in the future, noting the tradeoffs

I think its better to lower the scope of mitosis. So going the babel route.
Mitosis provides a as much info on a mitosis file (the json file) and the dev can use that to generate the correct file(s). Mitosis can provide their own versions of each one framework as examples. And mitosis can talk about tradeoffs etc. This will allow the dev to have full control over the output conventions to fit their use. Otherwise mitosis would have to support unlimited amount of output conventions.

Mitosis already accepts it's own middle layer JSON format as input - so it's also not inconceivable that alternative syntaxes could be built as separate programs that emit JSON with this schema.
I don't know how stable the JSON format is though.
It's also no clear to me how feature-complete Mitosis as a whole is at this stage.
Building something that has to chase after Mitosis for every breaking change might be a lot of work.
I don't know, but I do feel like there's a missed opportunity here to do something more or better than React - having a syntax that is derivative of React might be convenient for someone porting components from React to Mitosis, but as Steve said, "Mitosis is not React", and I don't think it aims to be, so the question might be whether this apparently similarity might be misleading more than helpful?
I mean, from what I've seen, front end developers spend considerably longer learning something like React than they do, for example, Svelte. And with the limited feature set, why not use a concise syntax optimized for the features it actually has.
Committed React developers, for the most part, aren't looking for React alternatives anyway - from what I've seen, React gets mandated by technical decision makers, and developers don't generally get to make their own choices about these things in the first place. Sadly, alternatives (even those that are more or less fully React compatible) such as Preact or Inferno barely get the light of day in comparison to React.
If it were up to me, I would design and optimize for the best possible experience, least learning curve regardless of previous framework experience, and so on. Svelte has been quite successful despite looking nothing like React, because it's also much easier to learn.
I don't think you can tempt or entice most business users anyway. Traffic for React alternatives appears to come mostly from hobbyists and personal projects, with Svelte being probably the only recent noteworthy exception.
I mean, if you think React has the greatest syntax and ergonomics ever, then sure, go for that. I would disagree passionately, but hey, each to his own. 🙂

I think we're on the same page because everything you said is exactly why I made my point about React.
The issue is the direction/goals of mitosis is not clear and I would prefer it to be more practical rather than idealistic. The idea of having a Universal Component is not new and many people have tried in the past and each with different approaches. The latest one being from chrome itself via web components which turned out to be DoA. Each large company has tried creating universal components and end up creating a universal component framework but adoption and maintaining that meta framework is a hassle. What makes mitosis different is that it's actually not a framework at all but a way to convert a developer's intent into json that can be converted into anything. Not only can we convert the same UI used in dynamic apps in static apps but can also use the best framework for that medium. The other benefit is also migration to new framework API changes since you're just reworking how the code is converted. For Mitosis to truly see its' full potential the mitosis files also need to live in the packages (or at least a way to get those src files) which will allow the dev to reconfigure that component (during build-time) to their coding conventions. This also allows devs to work with legacy code and even outdated mitosis files since they would just transform the json into the updated coding convention.

I don't know how stable the JSON format is though.
It's also no clear to me how feature-complete Mitosis as a whole is at this stage.
Building something that has to chase after Mitosis for every breaking change might be a lot of work.

Once the goals of Mitosis are clear and the API is more stable then it will make more sense for Mitosis to allow devs to create their own generators and unbundle their generators which will remove the burden of creating those variations to the devs

Committed React developers, for the most part, aren't looking for React alternatives anyway - from what I've seen, React gets mandated by technical decision makers, and developers don't generally get to make their own choices about these things in the first place. Sadly, alternatives (even those that are more or less fully React compatible) such as Preact or Inferno barely get the light of day in comparison to React.

I 100% agree with you and every dev that I spoke with wish they could use something else. The problem is that adoption in js world is driven by the job market. If companies are hiring for "foo tech" then there will be more demand for "foo tech".

If it were up to me, I would design and optimize for the best possible experience, least learning curve regardless of previous framework experience, and so on. Svelte has been quite successful despite looking nothing like React, because it's also much easier to learn.

I also agree with you here. I believe a middle ground needs to happen but more from a practical perspective.

I don't think you can tempt or entice most business users anyway. Traffic for React alternatives appears to come mostly from hobbyists and personal projects, with Svelte being probably the only recent noteworthy exception.

I convinced a Fortune 50 company to use mitosis for their design-systems but we're running into a lot of problems with what the world looks like if we have mitosis components. (aka we're missing some ecosystem requirements)
The biggest drivers for this was:

microfrontends - in these large orgs it used to be that they use every framework for different projects which allowed they to experiment but slowly it's becoming react/angular only and soon being react only. The main benefit of microfrontends is being able to migrate and experiment with different tech that will influence the system.
design-systems - they want to do a better job at consistent UI and the idea of a UI standard with Mobile peaked their interest enough to invest in using mitosis
no code investment risk (code eject) - how simple it is to not use the tool. Removing risk from the initial development since the team can continue developing for each framework output (if mitosis suddenly stops being supported).

I mean, if you think React has the greatest syntax and ergonomics ever, then sure, go for that. I would disagree passionately, but hey, each to his own. 🙂

I think other frameworks do a better job (syntax and ergonomics) but technical decision makers don't see/care about that aspect (only the devs working on the code do).
The opportunity here is not that React API is great or anything but that the technical decision makers need a way to have low/no risk to justify using anything that's not React. The battle is the ecosystem and in my opinion a practical perspective is the only way to break that (only hobbyists and personal projects) bubble

because of how component alias across frameworks works this has to be one component per file and we can update this later once we have better workaround for other frameworks