Building a professional design tool on the web using C++ and Emscripten(medium.com)
medium.com
Building a professional design tool on the web using C++ and Emscripten
https://medium.com/figma-design/building-a-professional-design-tool-on-the-web-6332ed4f1fcc
14 comments
People normally associate WebGL with 3D game content, but it's for 2D too! I decided to build our own GPU rendering pipeline for the performance and document size benefits you mentioned and also so we can guarantee top-quality, consistent rendering across platforms. A GPU rendering pipeline is actually a pretty normal technology choice for a cross-platform desktop app. It hasn't been too hard to find people with that expertise to work on the editor. We're looking at people with game development or browser development backgrounds.
Interesting approach... It reminds me a bit of Glamor, which is 2D X Windows primitives on top of OpenGL.
http://keithp.com/blogs/glamor-hacking/
http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/52-B...
http://keithp.com/blogs/glamor-hacking/
http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/52-B...
Yeah I find it's an interesting approach (as opposed to more traditionally building the sharing/collaboration features into a desktop app)..
I'll also be curious to hear more about what limits the chosen approach end up imposing..
I'll also be curious to hear more about what limits the chosen approach end up imposing..
I supposed if you built things right(have a nice clean separation of the display logic) you could plug it into Electron.
I feel like you'd need to architect for the Render/Main Node.js thread split upfront though, bolting that on would be difficult.
I feel like you'd need to architect for the Render/Main Node.js thread split upfront though, bolting that on would be difficult.
Slick.
Bonus is that Android/iOS is probably just a matter of hooking into just GL, Input & Filesystem APIs.
I'd really love the hear the painpoints of emscripten in production for an actual application. Most of the uses seems to be either games or demos.
Bonus is that Android/iOS is probably just a matter of hooking into just GL, Input & Filesystem APIs.
I'd really love the hear the painpoints of emscripten in production for an actual application. Most of the uses seems to be either games or demos.
The biggest pain points when using emscripten are debugging, compilation time, and code size. Debugging means poking through what is the JavaScript equivalent of assembly code but without a debugger that understands it (no segfaults on null access, strings are just numbers, etc.). The emscripten toolchain doesn't include an incremental linker yet and compilation time is limited by C++'s dumb compilation model. C++ also generates a lot of code if you use the standard library and templates (this is C++'s fault, not emscripten). In practice, we have an Xcode project hooked up to build the same C++ code and use that as our IDE. That way we can mostly treat emscripten as just a build target. I would only do it if it's worth the tradeoff.
I am currently developing a 3d engine in Emscripten, and to deal with the debugging problem I've developed from the beginning for Windows. The project links with ANGLE to expose GLES2 APIs, and it has both Windows and Emscripten versions of the platform-dependent systems like file access and input. With all this, I spend most of my time in Visual Studio.
Also, for the sake of avoiding complexity, I made a point from the start to never use the STL, and compilation times have stayed nearly instant because of that. Code size is also really tiny when there aren't a million template types floating around.
This comes with the caveat that I'm more comfortable developing without the STL; for other developers or other projects, abandoning the STL may be a tradeoff not worth taking.
Also, for the sake of avoiding complexity, I made a point from the start to never use the STL, and compilation times have stayed nearly instant because of that. Code size is also really tiny when there aren't a million template types floating around.
This comes with the caveat that I'm more comfortable developing without the STL; for other developers or other projects, abandoning the STL may be a tradeoff not worth taking.
mischanix has a good point. Why not whip up a local native version and use that for feature development and debugging? Then you can just do final QA on the emscripten version.
And if it works well enough the native version might be a good option for your power users to get better performance.
And if it works well enough the native version might be a good option for your power users to get better performance.
We're using Xcode instead of Visual Studio but that's essentially our process. Right now we're focusing our effort on getting the product right on the web first so native is currently on the back burner. A native version will definitely be a good option later on for power users.
It's against HN's rules to get friends/colleague to upvote posts, so please don't do that. It tends to get stories flagged and accounts penalized.
This is an interesting article so we've turned the penalty off.
This is an interesting article so we've turned the penalty off.
Does that policy also apply to downvotes?
Absolutely. If you (or anyone) think you see signs of organized downvoting, please email [email protected] so we can look at the data.
I am sceptical about the ability of this software to grow.
I'm wondering why you exactly decided to go this route? I was expecting your app to be very graphically intensive or have some other kind of demanding requirements. When I went to the site it appears it's some kind of collaborative design tool? Not saying these tools don't require a top-notch UI. Maybe for manipulating and scrolling/scaling huge canvases? Coming from a mapping background, I can totally see this as something lacking in the browser. There aren't many primitives for creating these kinds of image-based interfaces.
There's certainly a trade-off between having super-fast performance and a completely custom rendering engine and adopting a not-often used delivery mechanism and stack (C++/asm.js). I'd imagine it's hard to find people who have all that expertise, it's hard enough finding a good frontend dev in the conventional technologies of the web.
Good luck on your product launch, can't wait to use your UI and play around with it.