Skip to content
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

Closed
andrewvarga opened this issue Jun 10, 2020 · 6 comments
Closed

Components, contributions #85

andrewvarga opened this issue Jun 10, 2020 · 6 comments

Comments

@andrewvarga
Copy link

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.

@makepaddev
Copy link
Contributor

Hi Andrew,
So, we are building the makepad-IDE to be really its own way to fully build applications, not just a widget in a webpage. Technically we could, but i just don't stand behind that path. We'd open a huge can of worms of 'widget-grabbers' who don't care don't wanna learn just 'make it do X'. Of course its MIT and you can do whatever you want, but i don't really wanna go and support or promote this way of using the tech.
Also yes, the tree can go much faster if you use virtual viewporting. However then the fancy live folding animations are much harder :)

@makepaddev
Copy link
Contributor

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.

@andrewvarga
Copy link
Author

I understand and respect that. I feel inclination to try to build a whole app with makepad but I'm wondering about development speed. If someone is as well-versed with rust / makepad as in web tech, how much slower do you think it is, and is it even feasible at this point to build a simple app like gltf.app?
For example:

  • The welcome window has a list of thumbnails, some of them being animated gifs, which in html is just some elements in a div. Would this be something that would need to be implemented in makepad?
  • How hard would layout be, compared to css flexbox?
  • Slight drop shadows around windows / color widget popup (not critical to have)
  • Would it be possible to use web-only apis easily, like "requestPointerLock" for infinite dragging on number inputs
  • Are standard components like Select, Checkbox available? If not, what is the usual way to contribute? If a component is written and meets the quality guidelines, is there a way for it to go back to a standard component library?

@makepaddev
Copy link
Contributor

  • In short: its too early to do that right now, we are still replacing the shaderstack and have a lot of widgets to build
  • animated gifs would need a gif decoder, and a bunch of logic: widget to build
  • layout is 'i think' a lot easier and simpler than flexbox, but teaching how it works is the challenge. We aim to build education systems for this
  • Slight drop shadows, as long as you can do it with a shader are easy
  • Makepad really has a JS file that bridges any needed API's to Rust. This would just need to be added
  • We have 'button' right now and a text control, but nothing else yet. First we'll get our live editing up then more widgets will be added. Right now i don't recommend making them yourself, you can try of course but i'm moving things underneath a lot for now.

@andrewvarga
Copy link
Author

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.

@makepaddev
Copy link
Contributor

Yep, many things will happen over the next 6 months. Its ambitious so we take our time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants