How long until v1.0.0?

[l-mak-monninger]

I'm interested in converting a project to a full Rust stack, and Yew seems to be the best frontend tool out there right now. However, as you note, you haven't reached v1.0.0 yet. How far off do you think that is?

[WorldSEnder]

Given that the next release is expected to feature server-side rendering and a finished portal implementation, I personally see some sort of stability, but we'll have to wait how the API is accepted in the wild and if it needs more tweaking. With some uncertainty, the release after that could be the one fixing pet-peeves and small issues with those new features and provide some more long-term stability?

[l-monninger]

Great to hear! I'm actually new to Vue, came from primarily using React. So, far I pretty much like everything from React better than Vue. But, I'll let you know!

[l-monninger]

Actually, since we're a mixed team, I think one thing that's been kind of nice about Vue for the design-oriented half is the way Vue does Single File Components. That kind of html first look, I think, has made it easier to collaborate.

What might be cool someday is a .yew extension for files that will be transpiled to functions. Doing this with strong support for linting within the different sections would obviously be crucial.

[voidpumpkin]

@l-monninger no need for .yew as everything can be done already.

For html we have html!
For logic we have ofc rust.
For styles you can use something that would be like a rs-in-css solution like stylist-rs or something like tailwind

Yew is unopinionated like react so design decisions like this is left for the yew developer to make

[WorldSEnder]

A bunch of libraries follow the "one module = one component" approach, already, even if it's sometimes only internally visible and re-exported to a single module.

[futursolo]

The current architecture is purely based on procedural macro, which means Yew can utilise everything from the rust ecosystem (rustc, cargo, rust-analyzer, rustfmt, clippy, etc.).

Building a new file extension means that we need:

1. Compiler
   (we need to provide backend for LSP server so we cannot simply transform the source code and pass it to rustc.)
2. Code Formatter
3. Linter
4. Language Server
5. IDE Support
6. Syntax Highlight (for all mainstream code editor and IDEs)
7. Rust interoperability.
8. and more (e.g.: convince GitHub to support .yew file highlighting)

(Needless to say, these tools need to be as good as their Rust counterpart to convince developers to switch from procedural macros.)

Unfortunately, I don't think there is a strong enough reason (or bandwidth from developers) to make this attainable.