Elm and FRP

[Frankie Sardo]

Out of curiosity I started playing with Elm and the Functional Reactive principles. While still a young language and community, it gives you lot of food for your thoughts, and I like the idea of completely replacing html/css/javascript with one single language. It is particularly remarkable how basic tutorials and games are easy to implement with Elm with little to no setup compared to the tiresome process of setting up clojurescript. The clojure/clojurescript community is way more mature and the language itself would have no problems in doing something similar. Any particular reason why this has not been attempted or should be avoided? I'm not trying to be contentious, I'm honestly curious about your opinion.

[David Nolen]

Elm is cool, but still at this point I consider it a toy system. Being able to directly interact with HTML/CSS/JS is absolutely critical. ClojureScript is not focused on FRP research or experimentation - production usage is the main focus.

If you want to build an easier ClojureScript environment so more people can play around with it with fewer setup hassles - go for it! I think there are some similar efforts afoot (Light Table, Session, etc.).

David

On Sat, Jan 4, 2014 at 4:30 PM, Frankie Sardo <fran....@gmail.com> wrote:

Out of curiosity I started playing with Elm and the Functional Reactive principles. While still a young language and community, it gives you lot of food for your thoughts, and I like the idea of completely replacing html/css/javascript with one single language. It is particularly remarkable how basic tutorials and games are easy to implement with Elm with little to no setup compared to the tiresome process of setting up clojurescript. The clojure/clojurescript community is way more mature and the language itself would have no problems in doing something similar. Any particular reason why this has not been attempted or should be avoided? I'm not trying to be contentious, I'm honestly curious about your opinion.

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[Frankie Sardo]

On Saturday, 4 January 2014 21:47:32 UTC, David Nolen wrote:
> Elm is cool, but still at this point I consider it a toy system. Being able to directly interact with HTML/CSS/JS is absolutely critical.

Can you develop this a little bit further? For example I don't see any point for having to care about dom, tags and divs in a UI and anything that can abstract this assembly-like jargon for me is more than welcome.

> ClojureScript is not focused on FRP research or experimentation - production usage is the main focus.
>
>

That is absolutely one of the the reason why I like clojure community. It's not just a theory bubble, it's enterprise-ready. However, this community is particularly sensible to sound, interesting and 'simple' academics ideas and more often than once you see papers popping out as a reference for certain library implementation. I'm not qualified enough to say that FRP is one of these ideas, but it certainly seems so.

>
> If you want to build an easier ClojureScript environment so more people can play around with it with fewer setup hassles - go for it! I think there are some similar efforts afoot (Light Table, Session, etc.).
>
>

:) Indeed. But let's be more clear with one example. Every time I want to do animations/3d/other effects in clojurescript I end up importing a stateful JS library and try to wrap it with clojure calls. With Elm, you may very well think that JS does not exist at all, if you see what I mean. It's a language for building UI that incidentally compiles to JS.

[David Nolen]

On Sat, Jan 4, 2014 at 5:19 PM, Frankie Sardo <fran....@gmail.com> wrote:

Can you develop this a little bit further? For example I don't see any point for having to care about dom, tags and divs in a UI and anything that can abstract this assembly-like jargon for me is more than welcome.

I've been doing production client side work for 8 years now. Anything that abstracts these things away too much has no future in the industry.

 

That is absolutely one of the the reason why I like clojure community. It's not just a theory bubble, it's enterprise-ready. However, this community is particularly sensible to sound, interesting and 'simple' academics ideas and more often than once you see papers popping out as a reference for certain library implementation. I'm not qualified enough to say that FRP is one of these ideas, but it certainly seems so.

How to make FRP really perform well is still an area of active research. Elm is definitely showing that there's a lot of possibilities but I think abstracting away too much of the host is a liability not a feature.

 

:) Indeed. But let's be more clear with one example. Every time I want to do animations/3d/other effects in clojurescript I end up importing a stateful JS library and try to wrap it with clojure calls. With Elm, you may very well think that JS does not exist at all, if you see what I mean. It's a language for building UI that incidentally compiles to JS.

Pretending the host doesn't exist is just a non-goal for ClojureScript. As ClojureScript evolves I suspect people will create libraries that will have distinct advantages over their JS counterparts.

David

[Alan Dipert]

On Saturday, January 4, 2014 4:30:39 PM UTC-5, Frankie Sardo wrote:
> Out of curiosity I started playing with Elm and the Functional Reactive principles. While still a young language and community, it gives you lot of food for your thoughts, and I like the idea of completely replacing html/css/javascript with one single language. It is particularly remarkable how basic tutorials and games are easy to implement with Elm with little to no setup compared to the tiresome process of setting up clojurescript. The clojure/clojurescript community is way more mature and the language itself would have no problems in doing something similar. Any particular reason why this has not been attempted or should be avoided? I'm not trying to be contentious, I'm honestly curious about your opinion.

Hi Frankie,
I have shared your interest in FRP and the general topic of dataflow, the end result of which was the Javelin library [1] which may interest you. While Javelin was motivated by production use of Flapjax from ClojureScript, we chose with Javelin to eschew EventStreams in favor of the simpler and generally more familiar spreadsheet metaphor. We also found along the way that FRP falls out of dataflow modulo type inference, the marginal utility of which - in our experience - fell completely away with EventStreams were gone. What we really wanted was consistency - of which FRP Behaviors are the foundation - and with Javelin, we had it.

Like you I am also interested in the prospect of a single-language "environment" with which to program in browsers. I am interested in this because the browser environment is too comprehensive for a browser-agnostic language to provide a means for modularity and reuse in and between these kind of applications. Elm delivers this modularity by extending scoping rules and other Elm language semantics to every corner of the browser platform.

Because the modularity and reuse facilities of ClojureScript don't pervade the browser, and because CSS and HTML fragments are independently global scopes without composition semantics, we recently released Hoplon [2].

Hoplon is our attempt to deliver an "environment", not unlike Elm, that provides the primitives we've found necessary to build and maintain large single-page applications, addressing the modularity problem that Elm also does.

Unlike Elm, Hoplon is not a language. It is a set of Clojure and ClojureScript libraries that compose under a thin preprocessor. Also unlike Elm, Hoplon and its constituent libraries were designed to cooperate with existing HTML/JS/CSS libraries and to be a friendly environment for the average frontend dev.

In a nutshell, if you're into Elm you might just be into Hoplon :-)

1. https://github.com/tailrecursion/javelin
2. http://hoplon.io/

[Frankie Sardo]

Hi Alan, thanks for your thorough answer. I had a look at Javelin and Hoplon and I see there are some very interesting ideas there. I'll be sure to try them out and give you appropriate feedback. 

How's the adoption rate so far, anybody else embracing this approach? What are, if any, the major problems encountered up to this point in mid size applications?

--
Note that posts from new members are moderated - please be patient with your first post.
---

You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/ueRyi982UE0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

[Sean Corfield]

On Sat, Jan 4, 2014 at 1:47 PM, David Nolen <dnolen...@gmail.com> wrote:
> Elm is cool, but still at this point I consider it a toy system.

I think that's a bit harsh. It's certainly a young and fast-evolving language...

> Being able to directly interact with HTML/CSS/JS is absolutely critical.

...it is designed to be either the whole front end or an embedded
portion of it. In the latter case you can use the FFI to interact with
the non-Elm portion of the front end. The new "ports" feature provides
a clean bidirectional API between regular HTML/CSS/JS front end code
and Elm's Signal types. Elm certainly recognizes that interacting with
traditional front end technology is "absolutely critical".
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Sean Corfield]

On Sat, Jan 4, 2014 at 2:38 PM, David Nolen <dnolen...@gmail.com> wrote:
> On Sat, Jan 4, 2014 at 5:19 PM, Frankie Sardo <fran....@gmail.com> wrote:
>> Can you develop this a little bit further? For example I don't see any
>> point for having to care about dom, tags and divs in a UI and anything that
>> can abstract this assembly-like jargon for me is more than welcome.
> I've been doing production client side work for 8 years now. Anything that
> abstracts these things away too much has no future in the industry.

It sounds like you believe HTML/CSS/JS cannot be abstracted out to
something better, yet ClojureScript itself is such an abstraction, at
least for JS - and we have SASS, LESS, Stylus, etc for abstracting
away CSS to varying degrees. The "current" way to build web UIs hasn't
improved substantially for years - it involves a huge amount of
ridiculously fussy boilerplate and/or complex styling markup. I sure
hope we _can_ create something better, something more abstract!

I like how Elm attempts to abstract away all that "assembler-level"
markup detail.

[David Nolen]

On Tue, Jan 7, 2014 at 7:43 PM, Sean Corfield <seanco...@gmail.com> wrote:

> Being able to directly interact with HTML/CSS/JS is absolutely critical.

...it is designed to be either the whole front end or an embedded
portion of it. In the latter case you can use the FFI to interact with
the non-Elm portion of the front end. The new "ports" feature provides
a clean bidirectional API between regular HTML/CSS/JS front end code
and Elm's Signal types. Elm certainly recognizes that interacting with
traditional front end technology is "absolutely critical".

I'll be honest that I haven't followed Elm development that closely in the past year. If they've gotten around to that then great! It just wasn't my impression that was the direction they were headed when I saw it presented at Strange Loop 2012.

David 

[David Nolen]

On Tue, Jan 7, 2014 at 7:48 PM, Sean Corfield <seanco...@gmail.com> wrote:

It sounds like you believe HTML/CSS/JS cannot be abstracted out to

something better, yet ClojureScript itself is such an abstraction, at
least for JS - and we have SASS, LESS, Stylus, etc for abstracting

Sure but ClojureScript also doesn't get much in the way of achieving JS semantics directly in the language for performance reasons when you need it. This is not dissimilar to Clojure's relationship to the JVM. It's just not my impression that Elm has a similar outlook or philosophy about the host. Elm treats JS as something to keep at arms length. That's a very big interop tradeoff again in my own opinion.

David

[Gary Trakhman]

I'm not sure how elm addresses this, but my concern with 'abstracting away' vs 'creating better abstractions' has more to do with how much of a 'wall' the abstractions present.

For instance, it's nice and convenient that clojure functions map 1:1 with java classes and objects.  It hasn't abstracted away the java object.  Everything we know about java objects can be used to reason about function impls, too, and sometimes you need to know that.

I've often used cljs from the built-in browser's javascript repl, it's certainly convenient to navigate namespaces via simple object syntax, though I shouldn't ever *have* to do that.  It's easy enough to do so. 

[Gary Trakhman]

maybe an even better analogy can be made by saying:

all else the same, 'advanced mode' compilation is more of  a wall of abstraction than 'simple mode'.  In addition to the benefits, there are downsides, and one of the major ones is obfuscation.  Whether obfuscation is by shortened words, or inlining and other optimizations, it's effect is the same in this regard.

[Sean Corfield]

On Tue, Jan 7, 2014 at 4:49 PM, David Nolen <dnolen...@gmail.com> wrote:
> I'll be honest that I haven't followed Elm development that closely in the
> past year. If they've gotten around to that then great! It just wasn't my
> impression that was the direction they were headed when I saw it presented
> at Strange Loop 2012.

Yeah, I think there's been quite a change of heart over the last year or so :)

Right now there's a lot of work going on around JS interop, embedding,
and improving the FFI. I think 2014 will be a very interesting year
for Elm.

[Frankie Sardo]

Main problem I'm having with Elm at the moment is creating structured Single Page Applications. Responding to signal is fine and easy for games, but if you start to have different navigation patterns such as master/detail flow, enabling/disabling inputs for certain part of the screen could be a major pain. It's not as to say that those applications are a breeze to implement in clojurescript (at least for me, I tried pedestal and modern-cljs and I got lost halfway through the tutorials), but not having global and centralised event management could help in this case.

[David Nolen]

This problem seems well handled by Purnam, Om, and other similar efforts.

David

[Alan Dipert]

Re: Hoplon adoption, we're brand new but I'd say we have a small, enthusiastic, and growing community. So far there haven't been any problems with mid/large-size applications, but then that's what we designed it for :-)

Alan