Hats off to you on the implementation and for being so technically ambitious.
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.
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.
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.
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.
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.
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.