[gambit-list] JavaScript backend

Blake McBride blake at mcbride.name
Sat Jan 2 23:39:38 EST 2016


Yes, and I use jQuery get and html methods to load the html part.


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

> That’s an interesting app!
>
> As I said, it shouldn’t be hard to do.  In your app, how do you load new
> JS code?  Are you using jQuery and the getScript method?
>
> Marc
>
> > On Jan 2, 2016, at 8:42 PM, Blake McBride <blake at mcbride.name> wrote:
> >
> > 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/6ffd5cda/attachment.htm>


More information about the Gambit-list mailing list