I just have some general thoughts at this point. Curious to hear your ideas and other people's.
Maybe a nice starting point would be to make it easier for people to experiment with typescripten, to get feedback. Could we add minimal integration on the emscripten side to allow that, just a new option perhaps (marked experimental), and that uses a module from npm? (Or does this need more things than can be packaged in npm?) A thought I had is whether we could eventually replace embind with typescripten (or at least the part of embind that supports calls from C++ to JS). That is, if the core "JS object" class in typescripten had the same API as embind vals do (for accessing things in a *non*-type-safe way, using strings). Do you think that could work? If we could replace parts of embind it would strengthen the case for upstreaming, I think. - Alon On Fri, Jan 7, 2022 at 6:01 AM Sebastian Theophil <[email protected]> wrote: > Hi Alon, > > thank you very much and it's great to hear that you find this interesting. > I would be very interested in integrating this with emscripten of course. > How should we start this process? There are probably a few things that > still need to be implemented for a good MVP, so to speak. > > Regards > Sebastian > > Am Do., 6. Jan. 2022 um 21:59 Uhr schrieb Alon Zakai <[email protected] > >: > >> Hi Sebastian, >> >> This is really nice! I watched your talk as well at CppCon ( >> https://www.youtube.com/watch?v=CLuhogat6aY), very interesting. >> >> For a while it's seemed like we need something in this general area, so >> it's great to see it happen! I think this is a very good design, too (the >> performance issue with strings is the one concern I have, but as you say in >> the talk, that can be optimized - I'd use EM_JS for that probably). >> >> Did you have ideas about integrating this with upstream Emscripten? I >> think that might make sense to do, although maybe as part of a larger >> conversation on our bindings story (atm we have embind and the WebIDL >> binder, which already have some overlap). >> >> - Alon Zakai >> >> On Tue, Dec 28, 2021 at 2:21 AM Sebastian Theophil <[email protected]> >> wrote: >> >>> Hi, >>> >>> I wanted to plug my own project for some time here on the mailing list >>> because it also handles JavaScript - C++ interop and now wajic came up so I >>> thought I pitch in. >>> >>> My project https://github.com/think-cell/typescripten produces >>> type-safe C++ interfaces to JavaScript standard libraries or third-party >>> libraries. It reads TypeScript interface definition files and transforms >>> them into C++ shims based on emscripten. >>> >>> The resulting C++ code is often a straight-forward port from >>> TypeScript/JavaScript, e.g., >>> >>> JavaScript: >>> >>> var elem = document.createElement("p") >>> elem.innerText = "Hello CppCon 2021" >>> elem.style.fontSize = "20.0" >>> document.body.appendChild(elem) >>> >>> C++: >>> >>> auto elem = js::document()->createElement(js::string("p")); >>> elem->innerText(js::string("Hello CppCon 2021")); >>> elem->style()->fontSize(js::string("20vh")); >>> js::document()->body()->appendChild(elem); >>> >>> No macros and the C++ functions return typed JavaScript objects! Because >>> we use the TypeScript interface definitions, the C++ code is typechecked. >>> Passing a number to fontSize will create a compiler error. >>> >>> The project is not yet meaningfully complete but it bootstraps >>> successfully, i.e., the compiler understands the interface definition file >>> for the TypeScript compiler and parser API that it uses itself. TypeScript >>> generic constraints are not yet supported, for example, but should be. >>> >>> Maybe somebody else finds this useful. We have used it internally for a >>> small web app already that needed to call the tableau.com JavaScript >>> API. >>> >>> Regards >>> Sebastian >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/emscripten-discuss/CAN%3D%3DuddahRRPV02%3DT9TaQd2%3D3YzxqHDBAqg8%3DsWJL-Taqh4-SQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/emscripten-discuss/CAN%3D%3DuddahRRPV02%3DT9TaQd2%3D3YzxqHDBAqg8%3DsWJL-Taqh4-SQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSo_RuoctMU1TZObpugbtxS%3DgqrU-41typx2LuDKKMkWw%40mail.gmail.com >> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSo_RuoctMU1TZObpugbtxS%3DgqrU-41typx2LuDKKMkWw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/CAN%3D%3Dudd2f0LqvFaCA%2BO7GUa5Yw6rfnnS8CxOzSHQqgcYdvxGUg%40mail.gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/CAN%3D%3Dudd2f0LqvFaCA%2BO7GUa5Yw6rfnnS8CxOzSHQqgcYdvxGUg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpS0C0fHQT8hJCwuM%3DYzYuGDQ8tGE32kGjm_rFir00%2BVOQ%40mail.gmail.com.
