[gambit-list] JavaScript backend

Blake McBride blake at mcbride.name
Sat Jan 2 20:42:17 EST 2016


Hi Marc,

Thanks for the reply.

I started development of a Web based business application in 2006.  The app
is in production use.  The front-end is about 450 screens written in
Flash.  The back-end is written in Java (over 9,000 classes) on top of an
SQL database with 250 tables accessed through Hibernate.  The front-end and
back-end communicate through SOAP web services.

Since Flash is now dead, I need to re-write at least parts of the front-end
in JS to support tablets and phones at least.  I have front-end JS code
that communicates with the back-end SOAP Web services so I theoretically
wouldn't need to touch the back-end.

I have a preference to utilize scheme if I can, but the back-end is already
written and works.  It doesn't make sense to mess with it given the
investment.

The problems I had with Gambit (as well as many other systems) is as
follows:

Once a user logs in, my app has a consistent visual / UI framework.  Beyond
this framework, there are 450 different screens that appear within the
framework (like in one of the div's).

A.  I cannot load all 450 screen at system startup.  I must lazy load them
as they are called up.

B.  The initial UI framework code should contain all of the Gambit
machinery and libraries so that each of the 450 screens can be small,
light-weight, compiled separately yet have full access to the entire Gambit
facility.

With respect, my investigation into Gambit as a possible solution in the
past led me to the conclusions at that time it was not possible to produce
separately compiled modules that leveraged off of a single main module for
the Gambit machinery and libraries.

I suppose some time has passed and I wanted to see if the situation has
changed.  I can only use Gambit if:

1.  I can compile and load each screen separately

2.  I only have to have one copy of the Gambit machinery and library so
that the separate screens are small.

Thank you.

Blake


On Sat, Jan 2, 2016 at 7:06 PM, Marc Feeley <feeley at iro.umontreal.ca> wrote:

> asmjs is cool and Gambit has already been compiled to it thanks to
> emscripten (see “Gambit in the browser”:
> http://feeley.github.io/gambit-in-the-browser/).  The performance is not
> bad, perhaps 10x to 20x slower than when Gambit is compiled by gcc to
> native code.  The main problem is the size of the JS that is generated when
> compiling Gambit-C with emscripten to JS.  The gsi interpreter yields
> roughly 10 MB of asmjs code.
>
> As far as code size is concerned, a better solution is to use Gambit's JS
> backend with the Gambit library.  The code generated is roughly half the
> size when minimized (and it could be even less if some thought went into
> how identifiers are encoded).
>
> Even more savings can be had by doing away with the default Gambit library
> and writing a custom library specialized for the application.  Gambit’s
> library has lots of functionality that is not normally needed by typical
> applications.  For example, the predefined map procedure can handle an
> arbitrary number of list parameters.  If the application only uses the
> single list version, then this definition would be sufficient:
>
>  (define (map f lst)
>    (if (pair? lst)
>        (cons (f (car lst)) (map f (cdr lst)))
>        ‘()))
>
> That 4 line version is 1/20th the size of the map defined in the Gambit
> library (which handles multiple lists, has type checking, precise error
> messages, same list length checking and is safe for multithreading).
>
> So perhaps what’s needed for Gambit to be more successful for web dev is
> the creation of such a “slim” library for Gambit to replace the default
> feature-full library.  Gambit’s “tree shaker” would also help to eliminate
> the unused procedures of the slim library (unfortunately this only works
> for “whole program” compilation, so separate compilation would only be used
> for the development phase).
>
> Anyway, if this interests you please let me know.
>
> Marc
>
> > On Jan 1, 2016, at 11:44 AM, Blake McBride <blake at mcbride.name> wrote:
> >
> > Just some opinions.
> >
> > asmjs.org defines a portable subset that allows JS platforms to compile
> into very fast code.  Targeting that subset, and within their spec, is
> probably a good idea.
> >
> > JS has, and is becoming increasingly, a very, very important platform.
> With ajax and rest services, code increasingly independent from the
> back-end is being developed.  So, in a very important sense, JS has become
> its own platform, just like X86, and X86_64, along with Linux, Windows,
> Mac, etc.
> >
> > Many apps consist of two major parts:  the back-end processing, and the
> front-end human interface.  While one can write the back-end processing in
> any of dozens of languages targeting X86 or a VM, and the OS, there is
> really only one target for the other half - the human interface - and that
> is JS.
> >
> > While many languages are now targeting the JS platform (I am using the
> word "platform" to mean X86, X86_64, either, plus the OS) including,
> believe it or not, Smalltalk, there are few that can, IMO, be used in a
> real world application for several reasons.  But, these issues will likely
> be resolved soon.
> >
> > With respect, Gambit, at least in the past, was in many ways another toy
> solution - one with a functioning "Hello world" application but missing
> important features that make it usable in a real-world situation.  I would
> love to be a part of that solution, but alas, life doesn't offer me that
> level of freedom.  I am only capable of using a system that is reportedly
> working, reporting bugs, making small adjustments, and providing feedback.
> Regardless of my attitude, preferences, and intentions, I cannot provide
> more.
> >
> > Look at node (JS for the back-end) and its vastly increasing
> popularity.  Since developers are being forced to use JS on the front-end,
> it's bleeding over to the back-end.  I think solutions that take JS
> seriously at this stage will prosper greatly.
> >
> > Now, having said all that, I would love to see Gambit target JS as a
> high-priority, first-class target.  If that were the case, I would be happy
> to contribute what I stated above.
> >
> > Thanks!
> >
> > Blake McBride
> >
> > _______________________________________________
> > Gambit-list mailing list
> > Gambit-list at iro.umontreal.ca
> > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20160102/a0c0f994/attachment.htm>


More information about the Gambit-list mailing list