Evan Wallace is a Figma co-founder and esbuild maintainer who builds WebGL demos and writes about graphics and design tools.
Commenters credit him for the WebGL Water demo and recommend his Figma writing, noting his work on Figma and esbuild.
They don't link to the Form S-1 prospectus from their announcement, but it's publicly available at https://www.sec.gov/Archives/edgar/data/1579878/000162828025033742/figma-sx1.htm
Their highlighted metrics page: $821M LTM revenue, 46% YoY revenue growth, 18% non-GAAP operating margin, 91% gross margin.
It's an incredible success story, and the engineering they did upfront (primarily led by co-founder Evan Wallace) that set the stage for their success is the stuff of legends. https://madebyevan.com/figma/ has links to numerous blog posts breaking it down, but here are some choice quotes:
> [Evan] developed the hybrid C++/JavaScript architecture for Figma's editor that made it possible to build a best-in-class design tool in the browser. The document representation and canvas area is in C++ while the UI around the canvas is in JavaScript (the team eventually settled on TypeScript + React for this). This let us heavily optimize the document representation to reduce memory usage and improve editing speed while still using modern UI technologies for fast iteration on our UI. C++ development was done using Xcode (not in the browser) to provide a better debugging environment.
> Even though the contents of Figma documents are similar to what HTML can display, Figma actually does all of its own document rendering for cross-browser consistency and performance. Figma uses WebGL for rendering which bypasses most of the browser's HTML rendering pipeline and lets the app work closely…
This is an insightful article, although I don't necessarily agree with the view that "everyone" needs to know everything from first principles to be good at their job.
Talking about abstractions, during my past month, I was reading nand2tetris, and it's a compelling experience if you understand the exercise you are doing, which is not about building a computer from first principles; it's much more than that.
It makes you really understand what's going on behind the layers of abstracting that have been raised. Sometimes, understanding every layer of complexity is impossible, but depending on the area you are in, we need at least to try to understand the roots of it.
However, this is not for everyone; ask a musician if they are really in the weeds of why the instrument is producing music (the physics behind it!). They are probably aware that it's vibrating air, but, in general, they won't know the theory behind it.
Everything is built on abstractions, and that's OK, with time we will add even more on top of what we have; now, the issue is when those abstractions lock you in with a mindset that prevents you from creating something new without relying on those same abstractions that help you build stuff.
Many discoveries and inventions were made because they knew the layer of abstractions on top of it, and they just started again from scratch. Even Figma, the software, is built on a new core of concepts based on how the web was working back in the time [1]
[1]…
Thanks for sharing - this architecture post is also a great read: https://madebyevan.com/figma/building-a-professional-design-tool-on-the-web/:
> Our vision for the future of design tools is one where both the tool and the content are easily available to anyone, anywhere
> The reason this is hard is because the web wasn’t designed as a general-purpose computing platform.
> We fully control memory layout and can use compact 32-bit floats or even bytes when appropriate instead of JavaScript’s 64-bit doubles...The generated code is completely in control of allocation, which makes it much easier to hit 60fps by avoiding GC pauses. All C++ objects are just reserved ranges in a pre-allocated typed array so the JavaScript GC is never involved.
> One big issue for us was that certain browser configurations couldn’t allocate large ranges of continuous address space for the huge typed array that contains the entire emscripten memory space. The worst case was 32-bit Chrome on Windows which sometimes couldn’t even allocate a 256mb typed array because ASLR was fragmenting the address space. This has since been fixed.
A great example of making a single bold architectural decision (building a design tool on the web instead of as an app) in service of a vision (prioritize live collaboration), and then thoughtfully resolving all of the performance tradeoffs that stem from this route.
Gosh there are a lot of these programs, aren't there?
For some reason I find it really hard to read these tree map visualisations. I know the theory and all that, but for me they just aren't an intuitive way of displaying that kind of information. For me a radial graph (i.e. pie chart like) is much easier to grok - I don't even have to think about it, I just get it. Seems like there must be plenty of people who don't think the same way though, given how many different tree map disk viewers there are out there!
For what it's worth I use Diskitude (http://madebyevan.com/diskitude/) on Windows and Daisy Disk (https://daisydiskapp.com/) on Mac. Both are great!
This looks like great stuff if you follow the pointers, but lists don't make good submissions to HN (which itself is already a list). They tend not to lead to deep discussion because comments are about lowest common denominator of the items on the list, and this is usually pretty generic. What's better is to pick the most interesting item on the list and submit that instead. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=denominator%20list%20by:dang
Edit: let's do that in this case. I've changed the URL from https://madebyevan.com/algos/ based on https://news.ycombinator.com/item?id=33764875.
That's beautiful. WebGL makes you realize that all the "designers" fooling around with CSS are playing in the kiddie pool.
Of course, as soon as you use WebGL, users expect the visual quality of an AAA game. What you tend to get is crap like this.[1] It's possible to get the GPU to do great things for you.[2] But that's a programming exercise. Good 3D content is expensive. Most of the WebGL demos available either have very little content, or are recycling old video games.
All this technology, already deployed, and little good content for it.
[1] http://montagejs.github.io/beachplanetblog/
[2] http://madebyevan.com/webgl-water/