On 1/19/17, John Spikowski <supp...@scriptbasic.org> wrote: > Eric, > > I'm not interested in using Emscripten of IUP C code to work on the > web. Try to translate a simple "Hello World" in C to JavaScript using > Emscripten and you will be blown away how much support code is > generated. > > My goal is building a 'HTML' IUP driver and use a popular JavaScript > framework to produce the UI. > > John
Yes, I’ve tried Emscripten before. And I agree with you that there is quite a bit of bloat. (But I also am really picky and frustrated how slow and bloated software has become and things that are big to me are small to other people.) This is an SDL program I wrote in pure C and then ported to the browser using Emscripten. Use Firefox or maybe Safari (I’m having problems with Chrome) http://playcontrol.net/tempdownload/BlurrrBinaries/FlappyBlurrrEM/FlappyBlurrr.html However, a few points to consider: - Most web frameworks are pretty bloated too. There is some obfuscation of this fact because they dynamically download extra framework code on-demand sometimes, which sometimes masks the true extent of how much data they actually downloaded. - Web browser cache hides most of the return visit reloading - Content data like images and videos can quickly dominate over your code data. So if you have a rich media site, the code size is a rounding error in the total size of your web site. (If you don’t know much about ASM.js or Web Assembly, I highly recommend this talk, “The Birth & Death of JavaScript”. It’s both entertaining and informative. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript) - Web assembly is where the browsers are going. ASM.js was intended as the prototype/proof-of-concept. And now all the web browser makers seem to have agreed to support Web Assembly as the standardized successor to asm.js. Once all the major browsers roll out support, expect an explosion of apps written from all languages (C, Python, Lua, Ruby, Swift, Go, etc.) being compiled for the web browser. - Everyone will just get used to it and accept the bloat, kind of as they do now with the big giant bloated web frameworks being used to create desktop apps, like Node WebKit, Electron, React, which are like 100MB just for Hello World. My above Flappy Blurrr Emscripten example was 10-15MB which is still a magnitude less than that and most of that is due to the data from the images and audio files, and not the code. - Web assembly might have a tighter byte code format than what ASM.js has to do now (which is pure text JavaScript). Some of the code bloat could be reduced. Anyway, as to alternatives to Emscripten, I don’t think I understand your idea. I’m trying to figure out how you envision this, but I keep falling short. Can you explain to me the technical details of how this works, because in my head, I can only see two ways to make IUP work in the web browser. 1) Emscripten-like technique that can compile IUP’s C source base (along with your app’s C source base) to JavaScript (or Web Assembly) 2) Re-implement all of IUP in JavaScript. Your app must also be written in JavaScript. This has the major downside that you can’t easily compile a native app (Windows, GTK, etc.) any more. So for example, take this very basic IUP program: Ihandle* lbl = IupLabel("Hello,world!"); Ihandle* btn = IupButton(“OK”, ""); IupSetCallback(btn, "ACTION", (Icallback)DoSomethingCallback); Ihandle* vb = IupVbox(lbl, NULL); Ihandle* dlg=IupDialog(vb); IupShow(dlg); It actually depends on quite a significant amount of IUP core procedural C logic to do work. In addition to creating the native widgets for Label, Button, and Dialog, there is a bunch of layout code computed in IUP’s core C base to figure out where to place the label and button in the dialog. While HTML may have some static layout capabilities to do relative layout, the first problem is that IUP’s implementation is dynamically computed. The code is re-running things, like to see if the size of each of the individual widgets has changed, or if the widget has special properties set that may affect its layout position. I am having trouble seeing how to detect. express and convert this more general, procedural, (and Turing Complete?) layout algorithm into something that can be expressed as static, declarative HTML. Next, the button action itself I’m not certain of. So in an IUP program like above, I have my DoSomethingCallback implemented in C. Again, how can express/convert the full power of that arbitrary C function procedural implementation to do the same thing in static, declarative HTML? Or maybe I’m misunderstanding your statement entirely: “My goal is building a 'HTML' IUP driver and use a popular JavaScript framework to produce the UI.” Maybe I’m over-emphasizing what you actually want to do with HTML? But the reason I’m doing that is because, otherwise, this is kind of what Emscrpiten already does: Emscripten takes C code and converts it into JavaScript and HTML, creating a runnable website. So the only remaining nuance I see is that maybe you want to emphasize that you want Emscripten’s Javascript output to generate 3rd party JavaScript API calls instead of the baseline official standardized APIs that all these libraries are built on top of. I personally would be hesitant to do that since “the popular” Javascript framework seems to change every 6 months in the browser world. (We want the IUP implementation to last a long time and be stable.) And in the end, it doesn’t make the code size any smaller because you need Emscripten to convert code, and then you must add the 3rd party library Javascript implementation on top of it. And there may be redundancy in what IUP’s base can already do (like layout) and the 3rd party library can do, which means duplication bloat. However, I’m not strongly opposed to the idea of using a 3rd-party JavaScript framework either. This is actually an implementation detail that is much finer detail than what I was originally describing. I was just trying to explain how the overall architecture works. The specific JavaScript backend implementation isn’t terribly critical in terms of the big picture of just getting IUP to work in the browser. (Caveat: I’m saying this as somebody who doesn’t really know web programming and differences between all the third party libraries, so I could be underestimating the design impact.) And we could theoretically create sub-variants of Emscripten backends of IUP. So maybe one is based on pure baseline, official, standardized APIs, and another uses JQuery, and another uses Electron, and another uses React. There could be compiler instructions (#ifdefs) to select which JS backend to compile in. But anyway, I’m interested in understanding better your approach. Thanks, Eric ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
