From OP4JS to Smart Mobile Studio

With the SmartMS release a deal has also been concluded between Creative IT and Optimale Systemer AS, to safeguard their investments and ensure future evolutions, the JavaScript CodeGen portion of DWScript will no longer be developed as open-source, but will be exclusive to Optimale Systemer AS. Sales permitting, this should allow to dedicate more time to improving JavaScript code generation, optimizations and debugging support 🙂

Note that the core of DWScript (compiler and interpreter), as an evolution of the old DWSII project will not only stay open-source (as MPL), but will still be actively developed, as it will constitute the front-end of the compiler, and thus should benefit from the above deal with upcoming language enhancements and ever improving unit tests.


Almost exactly one year ago, as I was throwing around some benchmark and musing on the performance of modern JS engines, Jon Lennart Aasenden was investigating an “Object Pascal For JavaScript”, and asked if DWScript could be used for that purpose. At the time, I had only dabbled with compiling to asm from DWScript and was contemplating possible Code Generation options using LLVM.

Then a chord was struck, angel chanted (well maybe not that last bit), and the CodeGen was re-tasked to spit out JavaScript instead. Optimale Systemer allocated time for Lennart to work on RTL, IDE, testing and investigating what  is now SmartMobileStudio. A tool that takes Object Pascal and can compile to native JavaScript applications, that can run server-less.

There are already dozens of working samples for SmartMS. Beyond the samples that come with SmartMS, see Primoz’s demos, or (shameless plugs), my two experimental games that were done with it: Nickel-Iron, a shooter for iOS, Android and modern browsers, WarTrail, a tower defense game, for iPad and all major browsers. And more things are coming: database connectivity, Node.js support, WebGL

20 thoughts on “From OP4JS to Smart Mobile Studio

  1. Thanks for all your hard work! If only some-other-company would extend Object Pascal language as you are extending DWScript pascal …

  2. It is sad that the umcoming modifications of the DWS JavaScript backend won’t be freely available now.

    I’m quite sure that Creative IT and Optimale Systemer AS would benefit from making all the code and tools Open Source, just like Eclipse or Appcelerator, proposing enhanced service for companies, but leaving hobbiists and OpenSourcers free to use it.
    Of course, everyone has to pay the bill, but I’m not sure the Smart user community would be the same when you have $400 to pay for using Smart / DWS for JS.
    I can freely write this, since most of my known work in Delphi is published as Open Source in (PDF library, SynProject, mORMot). It helped made the code better, and now support starts to be made between users.
    Since Smart has a customer target larger than today’s Delphiers, I guess that Open Sourcing would benefit to all.

  3. In the “Strategic alliance with Creative IT and Eric Grange” article published at it is stated that:

    “Any company currently deploying this technology, or a derivative of it, is bound by international law to abandon it.”

    I think this statement is abusive, and violates the MPL license.
    You can fork a MPL work, if you make keep the resulting work MPL, i.e. published and Open Source.
    IMHO only proprietary forks are prohibited by the MPL.

    Anyone is able to fork the current state of DWS, including the JavaScript generator, and maintain its own MPL branch, as soon as the code is published, and initial copyright holders notified (i.e. Matthias Ackermann and you). Do you agree?

  4. @Mason Wheeler
    It’s not really deleted, you have it in the SVN history.

    But since it’s no longer maintained, while the rest of the compiler keeps moving forward, it will sooner or later start not compiling / behave incorrectly… and since I only maintain one repository, it’s simpler to manage that way.

  5. A. Bouchez :
    Anyone is able to fork the current state of DWS, including the JavaScript generator, and maintain its own MPL branch

    Yes, though a consequence of the CodeGen being MPL, is that apps compiled with it also fall under MPL requirements, since it basically uses snippets which are part of the original MPL source themselves, meaning that even if they do not alter the code, they have to “conspicuously” display their relationship to the MPL source.

    So this affects not just apps using the CodeGen but also apps compiled with it, hence the need for a non-MPL license in the case of SmartMS, as it could prove problematic to enforce (assuming end users would accept it in the first place).

    FWIW this kind of requirements is why Embarcadero rewrote the GLScene snippets they had in FMX, as it would have forced all FMX applications to “conspicuously” display their relationship to GLScene. This could have been avoided by licensing from the copyright holders, but the GLScene contributors were many, and some were unreachable.

    Also since code modifications are covered by MPL, modifying the CodeGen wouldn’t change the MPL status.

    Since Smart has a customer target larger than today’s Delphiers, I guess that Open Sourcing would benefit to all.

    Since I’ve restarted work on DWScript, feedback has helped, though mostly with testing and for the scripting side. However on the JS codegen side, the open-source contibutions remained quite inexistant… and interest only really started to ramp up with OP4JS/SmartMS. In the short term, I’m convinced more progress will be accomplished by being able to devote more time to it.

    There are quite a few loose ends that need to be tied up, and lots of ideas for improvements and evolutions 🙂

    Might be that in an undeterminate future, new CodeGens might emerge, maybe open-source, and for a different targets (not anywhere enough time for it, but I’d like to see that LLVM codegen, maybe OpenCL, or targeting some managed environments).

    I’d say that in the medium term, if someone wants to start working on a codegen, those could be juicy targets, an OpenCL target f.i could fill a gap in the “Pascal anywhere” claim 😉

  6. It’s not my project so i have no say in this, but i won’t continue my investigations to see how i can integrate these technologies into my software.

    You guys need you bills paid. Fair enough, but just like i don’t buy closed source delphi components i’m not integrating this technology if it’s all closed source, unless i really need it and there’s no alternative.

    I don’t -really- need it, so basically, you’ve lost me as a potential user.

  7. Be cearfule Eric!!! You violate MPL Licence.
    First thanks for your great works on DWS.
    DWSII is MPL License, DWScript is evolution of that project and also must be MPL License and any code developed in this project is also and must be MPL, including CodeGen. You can read that in all GoceGen pas files. Nobody can change this license, even you Eric who write all codegen code.
    What will happen if I for example take codegen code from svn and continue to develop as commercial and close source project? This will be MPL License violation. This term of violation includes anybody including you Eric.
    You must rewrite all codegen code again and that code can be closed sourced or sealed to somebody. This is the reasons why Embarcadero rewrote all the GLScene code.
    Last thanks for your great works on DWS.

  8. Tomislav :
    DWSII is MPL License, DWScript is evolution of that project and also must be MPL License and any code developed in this project is also and must be MPL, including CodeGen.

    The compiler core is a modification of DWSII and MPL, the CodeGen didn’t exist in DWSII, and isn’t a modification it’s brand new code which I wrote and of which I’m the original copyright holder,

    MPL isn’t contaminating like GPL, it only covers the source, its modification, and derived works, not projects you use it in (which is why I picked it in the first place, so you could use it in commercial closed-source applications).

  9. Wouter :

    Fair enough, but just like i don’t buy closed source delphi components

    Does it mean that all your works are open-source? And your customers (or boss) only pay you if you release all your work as open-source?
    Just by curiousity, what open-source applications or libraries have you released?

    Also let’s be clear, DWScript itself isn’t and won’t become closed-source, it was never sold, and only the CodeGen is concerned, and it affects all future developments.

    And neither DWScript nor consulting on it have been sold up to that point, so I’ve not made a cent from DWScript, actually, even ignoring the time spent, it’s has been a loss since this site isn’t on a free host.

  10. Eric, I won’t talk about licensing but about LLVM as I find its concept, implementation and usage very interesting.
    Wouldn’t it have been more interesting to stick with your initial idea to produce LLVM code then rely on tools such as LLVM-to-JavaScript to get the JavaScript you needed ? The amazing advantage of this is that you’d have gained not only JavaScript code generation, but native compiling on many platforms thanks to LLVM.
    Any thoughts on this option ? Perhaps it would have required more work and produced less customizable Javascript and that’s why you didn’t choose that path ?
    I guess you’d have produced a direct Delphi compiler competitor.

  11. @john
    DWScript is more mature now thanks to Eric’s devotion to the project, IMHO it’s easier now to produce the LLVM bitcode since a lot of compiler checks are already in place, however, it’s time consuming and the reward is… well not what you’d expect…

    Frankly, I don’t really get what’s all the fuss about the js codegen(besides the little misunderstanding regarding international law post…), the code will no longer be released publicly, so what? continue coding on the existing code and be happy with what you have for FREE.

    Smart Mobile Studio could be the next big thing for Delphi community, by leaving js codegen open-source, both Creative IT and Optimale Systemer AS would benefit from the code being tested on a larger scale, so, I would strongly suggest that both companies should review their strategy, but that’s just my two cents.

    Anyhu’, I’m sure you guys will do the best to focus on SMS’s quality and stability, please don’t follow “the company who we all love” lead with pricing, bad releases and updates after updates of fixes that introduces new bugs, also, if I may suggest taking into consideration schools, maybe a lightweight free or very cheap(say $50) version of SMS would push the product even further on the market?

  12. @john
    There were (and still are) a couple roadblocks with LLVM, the first is that’s it a C API with little support on Delphi, so this would have been necessary to do that first, the second us that it being rather low-level in its output, it would have to be restricted/sandboxed in some fashion for real-world use (script users don’t expect the whole app to come crashing down in case of a bug, unlike Delphi and native developers), so in practice it would have been targeted at JITting inner loops more than whole program.

    As for LLVM to JS (and other byte code to js compilers), they start from a low level representation, and the js code they generate is quite poor as a consequence, they don’t leverage the fact that js is way more high level than any other asm or byte code, because they lost that info earlier in the compilation stage.

    Now I never really intended for a Delphi competitor, one of the reasons I picked DWS originally was that it was in a it’s small way promoting Pascal, and indirectly all Pascal tools, Delphi included 😉 and in the grand scheme of things it’s probably better to open up new territories (like html5 & js).

    At the moment, if I were to pick a new codegen target, it would probably be OpenCL or GLSL, another virgin territory for Pascal, the native side of things is fun, but that’s Delphi & FreePascal territory, and catching up with either of these would already be time intensive

  13. @Eric,

    I would like to know if the latest version of DWScript will compile in D2007 or not?

    I am asking because I am not able to get it to compile it.

  14. @Yogi Yang
    Since I took DWScript over, Delphi 2009 has always been the baseline version (because of Unicode & generics), though I’m developing on XE, and don’t have older versions installed, so D2009-D2010 compatibility is user-contributed.

  15. @onore: the primary function of dws is server-side scripting. It was inspired in it’s day by ASP (this was before .net) that was a server side system for visual basic. DWS is still one of the absolute best server side scripting systems out there, a bit of a hidden gem since it never got the attention it deserves. Eric has done a fantastic job in waking this project from the dead and updating it to modern standards. And it will continue to be updated and improved still.

  16. Onore :

    [Delphi Web Script] Change Name [ DELPHI SCRIPT ] PLEASE!!!!!!

    Considered that two years ago, but:

    • * “Delphi Script” is already taken, and might be problematic in terms of branding, the “Delphi Web Script” has been long established (12 years).
    • * The re-branding and re-prefixing in source would also be prohibitive (don’t have time for it), let alone in user projects.
    • * The original “web” features of DWSII are still actively supported (HTML filter), and current DWS is more capable at them (multi-threaded execution per compiled program).

Comments are closed.