https://futureofcoding.org/ logo
Join Slack
Powered by
I just ran across makepad, which looks like a very...
# of-graphics
s
I just ran across makepad, which looks like a very promising live coding environment for rust https://makepad.nl/
💯 2
👍 5
The editor works on web (including WebVR https://twitter.com/rikarends/status/1297952305761914884) and desktop, shaders can be written in a subset of Rust. Eventually there will be a pro version with design tools. The FOC features here is that all of the code for the environment appears to be accessible in the live coding IDE, there are macros to allow for live tweaking variables, and code recompiles in real-time. Definitely want to dive into it a little bit more
i
Rik is on my list of people to possibly interview for the show, at some point.
👍 6
Makepad is also interesting as a ZUI.
😄 1
🔬 1
w
I’m actually mystified at the real-time compilation. Is that because it’s a completely different compiler using a Rust skin?
a
Rik took the pain of re-implementing an entire code editor from scratch, even down to glyph rendering. He would tweet the process, which took many months. There would be a tweet every now and then along the lines of "tried such and such parsing/layout/etc library, not fast enough. rolling my own." The result is an editor that is just _fast_*™*. To me, that is the unique FOC aspect of makepad. Speed is meant to enable the kinds of exploration that are only possible when things work fast.
Question: Do you think performance is to some extent a blind spot in the rest of the FOC community?
i
I think so, to an extent. To unfairly pick on just one example, there's the Penrose project that Katherine Ye worked on. In their demos it appears to run so slowly that I think I would rather lay things out by hand. A lot of projects take the approach of making it first, then making it fast, and that rarely works out in my experience. In the case of Makepad, isn't speed the whole point, though? Rik was (AFAIK) just trying to make a better version of an existing thing, rather than invent something new.
r
So i simply wanted to start improving developertools, and bridge the gap to designers
However everyone was doing the HTML thing but i found i couldn't move forward for performance reasons. HTML/Webstack was too slow to meaningfully experiment with new kinds of IDE things
One of the things i wanted was animated code folding (press alt in makepad to see it finally working)
❤️ 2
But wherever i looked the performance was too crap to try it. I've spend the past 8 years iteratively reinventing the whole stack so i could finally move ahead into new territory
The final iteration now in Rust is the first that is fast enough i can actually do something with it
So yes its true i've mostly been spending time to get 'parity' because you kinda have to. But now i can actually move beyond finally. Where that is? Well live editing with visual designtools that manipulate the code is the start
🎉 1
Performantly running in VR, using shaders as UI styling
Solving how you compose/write UI's performantly
There is really a significant amount of new stuff in makepad
And yes i think most research projects ignoring performance end up on the pile of 'cute but useless'
I do have to say though if you have to start where i did its a really long road to get to where i am now.
I've been using makepad myself for nearly a year now i think
It has some rough edges i need to fix but other than that its pretty decent. Writing code in Rust has the magical property that its nearly bugfree when it compiles. (mostly)
a
@Rik Arends IIRC, you've been making makepad in makepad for a while now? Do you have to switch to a different editor in certain situations?
r
No. I haven't for ages
💯 2
If i break it in the rarest of cases i use nano
a
I've spend the past 8 years iteratively reinventing the whole stack so i could finally move ahead into new territory
How do you sustain such a long project, generally? (Edit: 8 years is really impressive)
r
You do consulting inbetween your failures 🙂
💯 2
👍 2
And you don't give up. Because my early experiments showed the performance was there. Even in 2013. The problem was how do you layer a programming model on top that actually scales.
It had to come from Wasm + Rust before that clicked.
That animated code folding makepad has i couldn't do in JS no matter how hard i tried. Its a font-size animation that runs with full layout and everything.
a
In the case of Makepad, isn't speed the whole point, though? Rik was (AFAIK) just trying to make a better version of an existing thing, rather than invent something new.
@Ivan Reese Can't speak for makepad, but I think at some point, perf becomes a new "thing" of its own. Like, imagine what aparatus could be if it was fast.
🍰 1
m
I totally agree that performance is a feature on its own, and MakePad is giving me a lot of inspiration to start from scratch again with my FoC project.. currently I use canvas together with react experimental in concurrent mode, that helps a little bit. Although I also know that I can improve the performance in my current code base, but still.. the performance gain of rust/wasm would be a lot bigger I guess. Thanks for the inspiration @Rik Arends !
r
Yw. Yea i've always seen performance as a base requirement for utility, and the HTML stack just wasn't getting me there at all. Look for one of my earlier experiments why performance is key:

https://www.youtube.com/watch?v=4vtKRE9an_I▾

But also for core technologies as a code editor, if you want to extend its UI it has to be fast. With HTML code editors just drawing a bit of text is pushing the limits entirely.
2 Views
Open in Slack
PreviousNext
Powered by