Small is Beautiful

Small JavaScript that is. Or how to go from 350 kB down to just… 25 kB 23 kB.

Smaller JavaScript can help in up to three ways:

  • faster download: faster application installation or startup.
  • faster parsing for the browser: faster startup.
  • smaller identifiers: faster execution for non-JITting JavaScript engines.

And smaller also means you can have far more complex applications for a given size budget.


Taming the Chrome Web Store

Chromium LogoWell, “taming” is probably too ambitious given the jungle that the Chrome Web Store is, especially as this post is restricted to publishing a standalone DWScript/JavaScript app into the Web Store in a few simple steps.

Interestingly enough, it seems that publishing Metro apps for Windows 8 will follow a similar process, according to the developer preview.

I’ll use the Flock Demo as an illustration, and turn it into a packaged app, that lives in Chrome and can be access off-line.


First look at XE2 floating point performance

With XE2 now officially out, it’s time for a first look at Delphi XE2 compiler floating point performance (see previous episode).

For a first look I’ll reuse a Mandelbrot benchmark, based on this code Mandelbrot Set in HTML 5 Canvas. What it tests are double-precision floating-point basic operations (add, sub, mult) in a tight loop, there is relatively little in the way of memory accesses (or shouldn’t be, to be more accurate).


DWScript to JavaScript

Not exactly breaking news for those following the OP4JS news or the DWS SVN, but a new experimental set of classes is available for DWScript, which allows compiling DWScript source into JavaScript.

This allows to have Pascal code like this one for instance, be compiled into this html page (or see the outcome in jsfiddle), and be executable client-side by any modern browser (the demo uses HTML5’s Canvas). In the DWS source repository, you’ll find it in “MandelbrotJS” (requires Delphi Chromium Embedded to run).

The goal is to allow using a strongly typed, compile-time checked language in a Web-client environment. The code generation is also intended to be as lightweight as possible, without depending on a huge framework, and generate quite readable-looking JavaScript.

In the classic Delphi spirit, it’s all about allowing both a high-level usage, while still being open to low-level usage whenever you wish or need  to.

The compiled Pascal functions can be used for DOM events or called from JS, or vice-versa, and you are f.i. able to use it only for the more complex routines or libraries for which straight JavaScript’s lack of strong typing and prototype-based objects would make it a developer-intensive and bug-prone approach.

This is still work in progress, only a (growing) subset of the DWS runtime library functions are supported at the moment, but most of the language is in working condition, including var parameters, classes, meta-classes, virtual methods & constructors, exceptions, bounds checking, contracts, etc. Currently, more than 85% of the DWS language & rtl unit tests pass (most of those not passing are related to Variants, destructors & ExceptObject).

The JS CodeGen can be invoked directly or via DWS filters, so you can have a single-source DWS code with portions running either server-side or browser-side.

FWIW, the DWS CodeGen classes were originally intended for compiling to SSE2-optimized floating point, either directly to x86-64 or via LLVM, but JavaScript is at the moment opening more opportunities, and modern JS engines are making decent use of SSE2 already. Last but not least, in the near term, it’s probably best to let the dust of the upcoming Delphi XE2 settle a bit 😉