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

On Tuesday, January 7, 2014 6:06:40 PM UTC-5, Frankie Sardo wrote:
> 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?
> 
> 
> 
> 
> 
> On Mon, Jan 6, 2014 at 2:26 AM, Alan Dipert <al...@dipert.org> wrote:
> 
> 
> 
> 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/
> 
> 
> 
> 
> 
> --
> 
> 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.
> 
> To post to this group, send email to clojur...@googlegroups.com.
> 
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to