I have to come up with some names for the different technologies soon. Smart now have two terms for compiler and also two levels of RTL: the low level RTL that is a part of Eric’s compiler, and a high level RTL which is our “VCL” clone. Im thinking of naming our component library the VJL (visual javascript library), and instead of refering to the compiler infrastructure as “the compiler”, it is more fitting to call it “the build tool”.
One vs. many
As the test group knows, the build-tool takes your source-code, invoked the compiler and finally glues everything together into a final, solid HTML5 document. Since our system was originally designed for iOS development only, and since Smart components (including forms, which is our version of pages in a way) are purely javascript based – a fully operational “app” really only needs one HTML file.
In Alpha 2 i removed the injection of code directly into the document.body section and introduced “Application.Display.View” to the VJL. The reason for this was make the application regard “the screen” abstractly. So by altering what “display.view” points to – you can make your apps live inside any DIV you wish.
A couple of testers have reported back that it could be handy to separate the RTL from the program code. There are a number of scenarios where you might, for example, want to run multiple Smart apps on the same document. If you run a website and want to get rid of Flash for instance, it would be nice to code the new banner in Smart and also host a game or a cool menu written in Smart as well.
Having talked it over with Eric it became clear that this should be reasonable to achieve, but it will come at a price: namely that it defeats the latest compiler switch named “smart linking”. When you smart link your apps, only the code you have used is included in the final binary (in our case “binary” is javascript). It’s the same technique Delphi and C++ uses to make programs as small as possible.
So if we include the feature then it will disable the smart linking option. I am experimenting with this now, by dumping the entire RTL into a separate file. If it doesn’t produce any negative side effects (except a small speed penalty and some bloat) then I’ll include it as an option. Eric might slap me over the head for playing around with this – but it would (in my view) complete the parallel of “Delphi” for javascript.
Reusable libraries
One of my long term goals is to add a new project type to Smart for writing libraries. Which would be the javascript incarnation of DLL’s. Since we have our own IDE we could generate a class-map for the library – which you could then import later so the Smart IDE can keep track of what the libraries export. A bit like a Windows TLB file when working with COM objects.
We should be able to poll this off by isolating the compiled code in it’s own name-space. It would then have it’s own RTL and library – but due to the nature of Javascript, it should actually work 🙂 It would mean a little tweak to the RTL but we are constantly tweaking anyhow.
Why are libraries important? Components, that’s why. By pre-compiling and obfuscating your code – you could write and sell your own components. The other benefits are self evident I think.
Having the RTL+VJL in a separated file does make sense. When you take a look at generated JavaScript, most of the content is shared among projects. Smart linking won’t be a big issue, in this case – since we’ll have the choice to embed all JavaScript or not.
As far as I understand your article, obfuscation will still be available when using reusable libraries (I guess a kind of mapping will be maintained together with the library, in order to “link” the project code to it). Very nice.
I do not like very much your new .opp project format. AFAIK forms source code is Base64 encoded within, and XML is definitively not human friendly. Link to external files (e.g. .html, .css, .pas or .png) should be much better, also for Source Code Management systems. I’m not sure this is better than binary format.
What could be possible is to have a .zip container native for the IDE, just like .jar files, to “publish” a project. But having several files for the working copy does make sense to me. I’m using Total Commander daily to maintain a huge number of files for several projects, and with modern SSD and hardware, this is not a problem. And you’ll have less bugs. Just my two cents.
Obfuscation will be limited in a shared library scenario, as all the RTL/VJL methods & classname would be in clear (and thus, verbose).
So it’ll be for other purposes than optimization of bandwidth (this isn’t like jQuery or the rest, which don’t have a smart-linking option)
In the current alpha the smart-linking isn’t fully in place, with it an app like MissileCommand, which uses some VJL controls goes from 350kb “raw” to 100kb when obfuscation, smart-linking & minification are active, that translates into a mere 25kb if you enable HTTP compression or have the app packaged as a mobile app!
And it should be possible to smart-link even more: virtual methods aren’t eliminated yet f.i., like in Delphi, but they could be when never used, and devirtualized in others cases, the codegen is a bit too verbose in some cases, etc.
@A. Bouchez: If you right-click a unit in the project treeview, you can click “export file” and it will be saved as an external unit (handy when sharing code). You can also stuff common units into the new “libraries” folder.
So you have the option between saving a project as one solid file, or as a project file + source units (classical pascal).
The XML had to be added because otherwise we would break backwards compatability for each new feature we add.
As for the seperation of RTL/VJL, it makes sense from a conceptual point of view. It would be like compiling a delphi app with packages (shipping the memory manager in older delphi’s).
Let’s say you have a website and want to use smart as a replacement for flash. So you code a fancy banner advertisement for the page. But you also want to use a cool menu system you have coded in smart as well. Why ship two version of the same system?
But the developer’s log here is just random thoughts on my part. Things might not work as i want them to – but all things starts with an idea 🙂