-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A less dom and more template approach #34
Comments
That's probably true but I wonder if that can be optimized by the compiler? I'm not sure how strong it can get 😃 because Regarding DOM-specific things, I agree that it might be weird to have this ideas baked in, but do you agree that it would be mostly used as an HTML template generator having this special case is better?
Also, lately I found maud which returns an owned string. Owned strings should be less efficient, memory wise, than what we do. But they say that practically it is faster. I don't think we should micro-optimize things that will hurt expressiveness and ease of use. What do you think about that? (It's sometimes a problem to express feeling in writing, especially when having a language-barrier. Just to be on the safe side, These are genuine questions, would be happy to get your feedback 😃) |
I'm pretty sure the compiler can't optimize away the use of the
To be clear, I'm not suggesting supporting non HTML things -- I'm just talking about the internal implementation to prefer passing bytes thru rather than parsing individual tags into nodes etc.
With what I'm suggesting, the way to write components will not change. In fact, I'm pretty sure most current code will just keep working (only punning is what I'm unsure of).
This is interesting. I'm not sure what they tested exactly, but would be interesting to find some benchmarks and get clarity on the testing.
Again I want to be clear that the ergonomics of using the library will not be affected by what I'm proposing!
Absolutely! It's good to discuss these things and thanks for letting me know English isn't your primary language :) Feel free to be frank and direct! I'm going to experiment with it, because I'm still convinced it will be easier/faster/better in various ways. I'll also write some benchmarks so we can get some real numbers to compare as well. If it doesn't work out that way, I'll be fine to discard the work :) |
Ah, that sums it up 😄 basically inlining But if that's too difficult and harder to test, maybe we can drop the HashMap/HashSet usages in favor of arrays of tuples (like I thought in #6)? Not sure if this can be optimized away either but it feels lighter 😄 I'll be happy to see the results 👏 |
Yes, basically!
That might actually be something the compiler can optimize away! |
Currently the way the
rsx!
macro parses and outputs something akin to a psuedo-dom style set of element and attributes is similar to what React does. But the current use case of this crate is server side rendering (unless you have plans for this with wasm), a dom like structure is an implementation detail. With this in mind, it would be more performant to pass thru most of the template as static bytes to write calls, and splice in dynamic content where we find it.As an example, for this component:
Old output:
New output:
I think there are other things to consider with this change, like automatic quoting of attribute, punning (which I independently am unsure of) etc. I'll figure that out as I make progress. I'm going to experiment with this idea and see how far I can take it without running into unforeseen issues.
Thoughts?
The text was updated successfully, but these errors were encountered: