Client side web applications in Racket

[Stephen De Gabrielle]

Hi,

What are my options for doing client side web applications in Racket ?

I've been getting my head around server side - I can auth a user and set a cookie - but I'm not sure what my options for client side web apps:

- Should I be using Whalesong and/or Urlang?

- Is there a right/wrong [WhaleSong | Urlang | JavaScript] framework?

- Can I write both the front and back end in Racket? 

- Is WeScheme a Racket web app? 

I'm not sure where to start - the last time I did any significant JavaScript it was writing a pong game using the adobe svg plugin! 

Any feedback/advice appreciated,

Kind regards,

Stephen

--

Kind regards,
Stephen
--
Bigger than Scheme, cooler than Clojure & more fun than CL.(n=1)
--

[Stephen De Gabrielle]

Thanks

- is there a JavaScript MVC framework that is suitable to use with racketscript? (should I be using react or angular ?)

- can I use Racketscrips with racket web applications stuff for the backend or am I compiling racketscript to nodejs to run on the server?

Thanks again

On Sun, 22 Jan 2017 at 14:11, Jens Axel Søgaard <jens...@soegaard.net> wrote:

Hi Stephen,

If you want to write real Racket on the client side, your best bet is to use racketscript.

     https://github.com/vishesh/racketscript

Try it out here:

     http://rapture.twistedplane.com:8080/

Note that tail recursion is not supported.

Urlang as-is will allow you to write JavaScript using S-expression syntax and

also allow you to write macros using the standard Racket tools such as

syntax-parse. 

An example: http://soegaard.github.io/urlang/space-invaders.html

The plan is to use Urlang as backed for a Racket to JavaScript compiler,

but that project [*] is not ready for use yet (I plan to hack on this during the

summer vacation).

[*]
https://github.com/soegaard/urlang/blob/master/compiler-rjs/compiler.rkt


Whalesong implements full Racket with tco and correct error reporting.

The Whalesong compiler only runs on old versions of Racket and Danny

stopped worked on it years ago. 

/Jens Axel

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Jens Axel Søgaard

[Vishesh Yadav]

Hi Stephen,

> - is there a JavaScript MVC framework that is suitable to use with
> racketscript? (should I be using react or angular ?)

I can not speak for Angular, but I think React should be suitable.
You'll have to use ES5 API instead of classes and JSX, and therefore may
want to build a small layer in between for things to look nicer.

> - can I use Racketscrips with racket web applications stuff for the
> backend or am I compiling racketscript to nodejs to run on the server?

RacketScript provides a small FFI to interact with JS stuff. You can use
some NodeJS library, to write server-side code. Our Playground[1] client
and server is built entirely using RacketScript.

I would also like to add that RacketScript is not entirely Racket. Our
aim is to preserve Racket semantics as much as possible, but drop
expensive features. Specifically, RacketScript does not implement proper
tail calls (we try to convert self-tail calls to loops) and
continuations. Among other things, we use JS numbers, do not support
submodules and make fewer runtime checks.

Note that RacketScript is not ready for production use, and is
constantly changing. Therefore, we do not recommend it for anything big
and serious at the moment. Despite that, we encourage developers to try
RacketScript and share their experiences with us.

--Vishesh

[1] https://github.com/vishesh/racketscript-playground

> <spdega...@gmail.com <mailto:spdega...@gmail.com>>:

> <mailto:racket-users...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> --
> Jens Axel Søgaard
>
> --
> Kind regards,
> Stephen
> --
> Bigger than Scheme, cooler than Clojure & more fun than CL.(n=1)
> --
>

> --
> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users...@googlegroups.com

> <mailto:racket-users...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--

Vishesh

[Daniel Prager]

On the client-side framework front, I found some of the lightweight, post React / post Angular frameworks were easy enough to get going with Urlang, hence definitely worth a look for RacketScript.

I played mainly with Ractive; vue.js is similar. There are others. The main seeking point for me was that these frameworks are much quicker and easier to learn than React and Angular.

Interestingly, the creator of Ractive, Rich Harris, has a new "framework-less framework" out, sveltejs, which incorporates a compilation phase to minimise payload.

Dan

        it, send an email to racket-users+unsubscribe@googlegroups.com

        <mailto:racket-users+unsubscrib...@googlegroups.com>.

        For more options, visit https://groups.google.com/d/optout.




    --
    --
    Jens Axel Søgaard

--
Kind regards,
Stephen
--
Bigger than Scheme, cooler than Clojure & more fun than CL.(n=1)
--

--
You received this message because you are subscribed to the Google
Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to racket-users+unsubscribe@googlegroups.com

<mailto:racket-users+unsubscrib...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
Vishesh

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.

[Neil Van Dyke]

Quoting "https://github.com/vishesh/racketscript/blob/master/README.md":
> RacketScript doesn't support Racket features which are expensive, for
> example proper tail calls and continuations.

Do you have plans to revist the tail call question within RacketScript?
TCO is essential to idiomatic Scheme, and (while Racket is not Scheme,
and has grown other noteworthy strengths, and people have less interest
in learning algorithm crafting than they used to) I think TCO still has
a lot of merit, and should not be discarded lightly.

Not many people will mind if you discard first-class continuations,
however. :)

[Philip McGrath]

My understanding is that implementation is still lagging, but I believe ES6 specifies proper tail calls, yes?

-Philip

 

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.

[Jon Zeppieri]

> On Jan 22, 2017, at 4:33 PM, Philip McGrath <phi...@philipmcgrath.com> wrote:
>
> My understanding is that implementation is still lagging, but I believe ES6 specifies proper tail calls, yes?
>
> -Philip

Yep. Right now (among browsers) I think only Safari ships with it. -J

[Stephen Chang]

> Do you have plans to revist the tail call question within RacketScript?

Yes we do. The readme includes that statement just to be upfront with
users about racketscript's philosophy and what to expect when trying
racketscript.

That being said, RacketScript currently converts self-tail-calls to
loops, which is already on par with some industrially-used functional
language js compilers, so we conjecture that racketscript's tail call
handling is already sufficient for a wide variety of applications.

Of course, we would also be happy to learn of any deficiencies. Even
though Racketscript is still immature and unstable, we welcome
feedback and contributions from the community to help shape
Racketscript's development.

> TCO
> is essential to idiomatic Scheme, and (while Racket is not Scheme, and has
> grown other noteworthy strengths, and people have less interest in learning
> algorithm crafting than they used to) I think TCO still has a lot of merit,
> and should not be discarded lightly.
>
> Not many people will mind if you discard first-class continuations, however.
> :)
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to racket-users...@googlegroups.com.

[Matthias Felleisen]

It’s not TCO, it’s PITCH (proper implementation of tail calls) — there is no optimization going on :-)

> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

[Neil Van Dyke]

Matthias Felleisen wrote on 01/22/2017 07:07 PM:
> It’s not TCO, it’s PITCH (proper implementation of tail calls) — there is no optimization going on :-)

As usual, Matthias is correct.

As I was typing the original sentence, I had the thought "TCO isn't the
right term", but I was lazy or trying to suppress my novella tendencies,
so hit Send. "TCO" might still be a good search term to complement
"proper", for anyone who wants to read up on the evolution of thinking,
from back when algorithm implementation was emphasized more. It's among
developer skills that sometimes are very important, but are currently
undervalued, when most of the software development industry chatter we
hear concerns the large volume of commodity clerical work for which
employers are currently paying good wages.

[Neil Van Dyke]

[This message is a resend, because the first attempt hasn't gone
through, after several hours.]

You can also do HTML 5 (possibly Offline), together with whatever JS
libraries you want for UX and for cross-browser differences (especially
for client-side storage of larger data), and have it talk with your
HTTPS Web server that's implemented in Racket using XML or JSON.

Your webservice XML/JSON messages will normally be in terms of the
model, nothing view/controller-specific. Which is good for many
reasons, though sometimes you can make a good argument for cheating, but
be very careful with cheating, because you will tend to pay for it for a
long time.

Depending on your app, you might also find (as I did, with a complicated
data-driven app), that it can help to have Racket generate much of the
static client-side HTML/JS/CSS.

This can let you do things that clerical-worker-oriented frameworks do
not, and more efficiently. It does mean, however, that you need
non-clerical-workers to do much of the work, unlike many Web frameworks.

[Ethan Estrada]

On Sunday, January 22, 2017 at 6:13:28 AM UTC-7, spdegabrielle wrote:
> Hi,
>
>
> What are my options for doing client side web applications in Racket ?
>

There are far more client side options for general Scheme implementations that compile to or run in JS. There is a decent list here:

https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS#scheme-like

They are not Racket and won't have access to all the Racket libraries, but something in the list may be good enough for your client side needs. If you use the `r5rs` lang server side in Racket (instead of `racket` or `racket/base`) you may even be able to share some code between the front and the back end using a more general Scheme implementation for the client side.

[Stephen De Gabrielle]

Thank you all!

I'm still getting my head around how modern (client side)web applications are developed and work on the users browser - the last web application I worked on was perl and fast-cgi.

My understanding of modern web apps is 

a) you are served a base (x?)HTML(5?) page and JavaScript by the webserver

b) the JavaScript then populates the DOM with any dynamic elements

c) the JavaScript responds user events and  polls the server, updating the DOM accordingly

I think I can do JavaScript side with RacketScript or Urlang* combined with HTML without resorting to one of the web frameworks.  I'll try a Frankenstein monster combining 'Instaweb with space invaders  to see if I can serve JavaScript  and go from there.

 Thanks again for the kind responses,

Stephen 

* I'm undecided because I only know a little js, and know nothing about nodejs