Jump to content

SMS lose weight

Recommended Posts

When we use SmartCL framework, the compiler generate a big runtime overhead to create a single blank visual form application.


So my attempt is try to reduce this overhead setting some directives, for instance, let's add some scope symbols around SmartCL Framework. That's exactly what I've done!


1st time compile: a blank visual form app has generated the uncompressed source 275,392 bytes | 93,502 bytes compressed/obfuscated.


2nd time compile: One thing that I think that could be optimized is the device engine detector, I had to edit SmartCL.System unit, now, the index.html source is 272,294 bytes.


3rd time compile: Since I don't use the fx Animation in my project which inherits from TMovableControl, this is a example of a partial class, I've just added a custom directive, and now I can reduce the final code size 15% (238,673 bytes | 81,475 bytes compress/ob=enabled).

4th time compile: Let's go ahead, this can be useful case you don't use the page transition animation, you can omit this feature, and create a custom directive USE_PAGE_TRANSITION, the final code size is 227,679 bytes | 78,304 bytes compressed.


5th time compile: another thing that I don't use is the built-in Dialog feature, IMHO, it generates a lot of code for a single dialog, I prefer design my own dialogs, so I've added another directive USE_DIALOGS, this can be useful case you don't use this feature, and now the code size is 185,080 bytes | whoopie 64,434 bytes.


6th time compile: alternatively, I can create my own custom widgets and I discovered that I can omit the event handlers. A widget/component inherits from TW3CustomControl witch all visual controls inherit from. I've noticed that inherits the full methods and properties from it's ancestors, and sub-objects, so I've just created another custom directive USE_SMS_CUSTOM_EVENTS, and the final code size is like Delphi 2 :)160,452 bytes. Exactly, 57K obfuscated.


Just to prove if this works, I've just created a custom SMS visual Button widget with ripple effect. It is a variation of the Btn Material design with the ripple effect, and the final file size is around 62K.


If we set verbosity option to none (to remove comments), uncompressed source is 126,173 bytes. SmartMS lost some weight: 275,392 - 126,173 = 149,219 bytes

Link to post
Share on other sites

Perhaps it is time to make some Open Source alternative to the SCL?

SCL has its strenghts, but I guess that interfacing some most widely used frameworks, like Ionic, may help opening SMS to new levels.


We could easily use the SMS compiler and IDE to write and debug business logic in its powerful SmartPascal.

But let the UI be handled with regular frameworks like Ionic.

You would focus on your logic, provide a first draft of the UI, then let the UI part be polished by true designers...

Link to post
Share on other sites

It would be good to have framework, where we can easily integrate existing UI JS frameworks, without wrapping every single control into a SMS control.


In my current project I use jQuery to interact with the UI framework (in my case jQuery UI). In the form designer I just place the containers, to get an overview of the UI layout visually. It's not quite ideal but it works pretty good for my needs.



It would be good to have a SMS optimized jQuery library, which work more natural with SMS.

Link to post
Share on other sites

There seems to be a missunderstanding about the VJL (its not called SCL, but VJL).


First of all, libraries like jQuery has little to offer the standard object pascal model. Like the name implies jQuery is a "query" system, designed primarily for looking up named identifiers in the DOM, sorting them, extracting groups of elements and so on.


JQuery has naturally grown these past couple of years, but its still based on a model where the code "does not know" the handle of element it should act on.


Secondly, when it comes to UI widgets: most frameworks out there are literally "skin deep". They make a button look good, use fancy colors and so on -- but the controls themselves have no depth. in 90% of the cases its just a <div> tag or something else "dressed up" to look like a real control.


This would be the exact opposite of how classical object pascal works. The entire VCL and LCL (and before that, turbo vision and its clones) were based on the notion of classes -- where the class "knows" the handle it represents, from cradle to grave (so to speak).


The entire point of the VJL was to setup a somewhat familiar environment -- so people can port over Delphi and LCL components to HTML5. Focus has not been on integrating with JS libraries so much. That came later.


Having said that, wrapping JS libraries is very easy. Especially using the typescript importer. But the VJL is about writing new components and getting whatever functionality you desire in object-pascal form.


Take something simple, like a listbox.

It's super simple to make this in SMS, and styling it to look exactly like jQUI or whatever takes minutes.

But the value of such controls is not in the "bling", but rather in the depth of the components and amount of methods you can use on the lists.


The initial control base was actually just meant as an example. We figured that most people come from Delphi and will port over various component from Delphi or Lazarus. The look of things is just CSS, which is something you learn in 1-2 days if you get a good book.


Naturally VMT based code is going to be bigger than hand-written non-oop based code. Delphi was also called "bloated" when it came, because back then everyone was doing turbo pascal with 50% assembler.

You can always find ways to "cut down" the size of something, but the question is price.


If all you want is the JQuery UI, that is not an RTL issue, but a styling issue.

Re-implementing JQUI for SMS would be very easy, including whatever effects or visual feedback it has to offer. TW3CustomControl in combination with smartcl.effects.pas gives you a lot of power to create complex and dynamic visual controls. And since we have classes and instances, we get to attack the problems from a better vantage point.


I would suggest that we take a closer look at the jQUI css scheme. Most of it seems portable and can be used to skin SMS applications out of the box. In fact, the form-scrolling animation we use was written to be nearly identical to the JQUI version.

And naturally, last but not least, SMS was created to build mobile applications using Phonegap. It has grown a lot these past 4-5 years, and now it can target both NodeJS and NodeWebkit, but the basic principles of object pascal will always be there.
Classes, instances knowing the handle of their managed controls.

More than anything, we need object pascal versions of popular widgets, not wrappers.



Link to post
Share on other sites

More than anything, we need object pascal versions of popular widgets, not wrappers.


I totally agree with you, but SMS started in 2012 and now we have 2016 and there are almost no UI controls available (I dont' count TWGrid and TWChart, they look pretty ugly and are very limited in the usage). IMHO, SMS would great benefit of haveing an easy option to wrap exisitng UI javascript libraries. In my case, if I didn't have the option to use a 3rd party UI framework, I couldn't use SMS for my project.


Unfortunately, all 3rd party UI frameworks require jQuery to hook up, or some other alternatives, which I don't know.


Take something simple, like a listbox.

It's super simple to make this in SMS, and styling it to look exactly like jQUI or whatever takes minutes.

But the value of such controls is not in the "bling", but rather in the depth of the components and amount of methods you can use on the lists.


If it is so super simple, why doesn't it already exist? I created a combox in pure SMS, but it took some time to have all the features I needed.  Furthermore, working with the DOM has also some pittfalls. When the dropdown list is shown, you have to place it on the right view (div) level, otherwise it will be truncated by the parent view (div). And using absolute coordinates, are not the some on all browsers (some include the border width and some not).  Doing all the style hooks (focesd, pressed, active, ...) is not hard but needs also some time. ... and this is just a simple control.


I also developed a Popup Menu control, but without using jQuery I wouldn't be able to do it, since I needed the .one() click feature of jQuery in order it disapears, when the user clicks somewhere else. I am sure there is an option, to do it in pure SMS, but all google search pointed to jQuery.one() click. So, I was not able to find anouter solution, with my limited javascript knowledge.

Link to post
Share on other sites
  • Moderators



Developing nicely styled components in pure 100% sms no wrappers is not trivial, but not that hard either

Hardest part is the actual visual design of your component, not so much the behaviour coding (although yes, it does take time)


For myself I'm not against using external frameworks like jQuery. 

The question here was though, is it possible to do without.


I think the answer to that is yes.

You've probably seen a number of proof-of-concept components built from scratch listed on http://forums.smartmobilestudio.com/index.php?/topic/4083-component-styling/   - source code included


As to your question on the one-click feature for popup menus etc, see http://www.lynkfs.com/components/styled/menu/ which implements the following code

  Handle.ReadyExecute( procedure ()
//  any click outside this component sets visibility to false
    browserapi.document.addEventListener("click", procedure()
        If (browserapi.event.clientX > self.left+self.width) or
           (browserapi.event.clientX < self.left)            or
           (browserapi.event.clientY > self.top+self.height) or
           (browserapi.event.clientY < self.top)             then
             self.visible := false;

which seems to work ok

Link to post
Share on other sites

There seems to be a missunderstanding about the VJL (its not called SCL, but VJL).


More than anything, we need object pascal versions of popular widgets, not wrappers.


AB is talking about the SCL SmartCL framework




Perhaps it is time to make some Open Source alternative to the SCL?


Personally, I think this is a great idea, maybe a open source Lite IDE version, without Designer, instead of "Forms" this version would just have the "HTML" tab,  with autocomplete/auto close  HTML tag syntax, we could import/create HTML files (views).


I think it would be awesome consider to use the open source Framework7/ionics/material design - only the CSS part. The whole functionality would be implemented in pure smart pascal.  This will give us plenty of benefits.

Link to post
Share on other sites
  • 1 month later...




║ BROWSERENGINE ║ SmartCL.System  ║               5.390 ║

║ EVENTS_OFF    ║ EVENT HANDLERS  ║              28.869 ║

║ CANVAS_OFF    ║ REMOVE CANVAS   ║              13.755 ║

║ FXANIM_ON     ║ FX ANIMATIONS   ║              36.719 ║

║ DIALOG_ON     ║ DIALOGS FEATURE ║              41.950 ║

║ PAGEANIM_ON   ║ PAGE TRANSITION ║               4.530 ║






(-)UNUSED FEATURES.................:(130.919 bytes)

║ -------------------------------------------------   ║

(=) FINAL..........................: 140.000 bytes  ║

║ OBFUSCATED/PACKING..................: 50.641 bytes  ║



...the estimated reduced file size: 93%


I'm probably being excessively conservative about the file size. So my attempt is try to reduce the overhead even more, and create a light SMS. Let's go a little further and use the closure compiler service, and and it's seems to be there a lot of unnecessary stuff yet.


See this SMS based form blank project  43.816 bytes.





Link to post
Share on other sites













You can enable/disable a feature anytime (prefixing a directive with a .dot), basically you have to define the Conditional Defines slot under Project | Options | Compiler | Custom conditional defines




f.i. this config will exclude "canvas graphics" + "dialogs" + "fx animations" + "page transitions effect" from the source code. Ensure to have .EVENTS_OFF directive to enable event handlers(at design time). At compile time, removing .dot from the directive .EVENTS_OFF will clean up a lot of stuff.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...