-
Notifications
You must be signed in to change notification settings - Fork 251
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
Components, contributions #85
Comments
Hi Andrew, |
Another reason is that building full applications in Rust, and Rust alone is simply a superior way to build applications. Much more stable than any JS or C++ could ever be. |
|
I see, sounds pretty good! I understand it's a bit too early then, but I'll be watching over the project, and hope to contribute when the time comes. |
Yep, many things will happen over the next 6 months. Its ambitious so we take our time. |
This is not really an issue but I couldn't find another way to contact.
First of all, awesome project, love the performance!
I was wondering if it's possible and if it's considered a good practise to use makepad to build components as webassembly modules for performance critical components within a web application that is not fully ported over to be built on top of makepad (yet).
My examples is a hobby glTF editor (gltf.app) which has a tree component, but it's quite hard to make it perform well with nodes over 2000 items. I tried makepad by generating 6000 items and the tree component handled it very well. It started to slow down at 20,000 items but I'm sure there's ways to optimize and I don't need those numbers anyway.
In this project it would be useful to develop just this tree component based on makepad, and keep less performance critical parts of the editor in html - at least until I get to rewrite them as well.
The text was updated successfully, but these errors were encountered: