@micha: hi! I see that you posted (input :change ...) as an example, didn't you say all of these were removed and one should use on! and do! ?

hi @xifi

the on! and do! multimethods are for adding your own custom attributes

hoplon ships with a number of basic ones, which you can see defined in hoplon.cljs

but you can override them with do! or on! multimethod dispatches of your own if you don't like those

so once you do for example

iirc I saw a couple do's implemented but on was dispatching to jquery

(defmethod on! :crazy-event
  [elem attribute-key callback]
  (.addEventListener elem "crazy-event" callback))

now you can use

(button :crazy-event #(.log js/console "the event object is:" %))

then whenever "crazy-event" is triggered on that element it'll call the callback

yeah on dispatches to jquery by default

but like i said that's just the default if no other multimethod dispatch matches

if you do (defmethod on! :click [elem key callback] ...) then your omplementation will be used instead

how does the call know if to look into the on! or do! multimethods? What if you defined :crazy-event on both methods?

it dispatches on the type of the value you're setting the attribute to

for example, if the value is a function then it knows to call on! because it's a callback

(div :something #(...))

there's no way that can ever be an attribute, it would make no sense

so it's not ambiguous

i mean there's no way you intended to set an attribute to that value

<div something=???>...</div>

the ??? can't be a function

ah so do only sets attributes. gotcha

I should really start writing more and ask less

it's "unidirectional dataflow"

the output is events, which correspond to on!

and the input generally modifies element properties, via do!

the two are completely decoupled

it's unidirectional in that do! deals only with setting properties on the element and on! deals only with receiving events fired by the element

it's either do!ing something to the element, or calling a callback on! some event fired from the element

http://hoplon.io/img/arch-full.png

the on! side of things is blue, the do! side is red

@micha: that's a quite complicated graph for me But thanks!

so javelin is for the FRP stuff, and castra is the RPC thing. Why use it instead of ajax?

it uses ajax for its transport layer

but i believe that REST in a web app is always just thinly disguised RPC

the REST manifesto has no benefits there whatsoever

the only time a GET request makes sense is when you really have a document

which is like a static resource, and those are outside the scope of castra

you just put those on a CDN and you're done

but when you query a database you're doing a side effecting thing

so POST is the only sensible method

and the path is completely irrelevant with a POST

what matters with a POST is the body, which is completely arbitrary

and outside the scope of REST

so i believe that REST is nonsense when you're communicating with a backend server

it's a flawed, leaky abstraction, adding complexity where none is needed

all you want to do is call a function on the server

with all the transport layer stuff handled automatically

i.e. marshalling and unmarshalling, authentication, etc

funny that rest states rpc as complex and now you say the opposite. I guess there are different opinions on the topic

it depends what you mean by "rpc"

the castra rpc is a limited form

I was asking why all castra requests are POST in a previous post, so I guess you still remembered that

the problem with RPC is when you want to have rpc stubs in the client that are indistinguishable from regular functions

like you want to not have to know if a function is executing on a remote host or not

I asked because I remember someone telling me in short that GET is for when you make no side effects on the server. In the case a query would be a GET, which castra surely does

castra doesn't provide that

there is no such thing as "no side effects" when talking to the server in a real application

there is authentication state, things like that

they're stateful calls, not stateless as GET is supposed to be

also you're querying over a database that is constantly changing

the person's words actually where 'when you fire the GET method n times and you always get the same result'

so there is no parallel with a document with a last modified time

yeah thats just not the case for ajax requests in the real world

if you have an immutable thing you just write it to a file and serve it from a cdn, right?

you don't serve that from your database, that's insane

the database is where you have constantly changing state

so GET is never really appropriate there, or very useful

I understand, thanks! I have another question but I have to ask another question before asking the first question - do you mind all these questions?

or me saying question so many times

I ask a lot

haha no worries!

fire away

This is still all very theoretical, but a thought you could clear for me - in the om talk David said it's good to have all state in 1 var. Before hearing him I actually thought of it as a limitation. I understand it can be useful to have all state in 1 place so that it is easy to dump it as a whole. But it seems to have drawbacks, like how do you "listen" to changes deep in the state. Which is probably what cursors were invented for, right. Still the whole thing seems to me upside-down. Wouldn't it be nicer to keep state in small chunks that are a) easy to understand, b) easy to listen on? And you can always just write something that composes them together into 1 var. Does this make any sense?

the big problem with having everything in 1 atom is that everyting in there needs to be named

it's basically serving the same purpose as the namespace system we already have

but it's worse because there is no way to use scope in there

which is a key thing in building lisp programs

so i don't agree that having all things in one atom is good at all

with hoplon we have as many atoms as we need

and we can connect them together for querying over with formula cells

state can be contained in anonymous cells, which is vitally important

when everything needs to be explicitly named you can't form abstractions

because abstraction by definition is hiding internal structure

yeah, seems more logical to me than dumping everything in 1 var. I mean that's why we have vars and scope etc

which you can't do when you have a global atom where nothing is hidden

exactly

Lisp Can Do It

if you find yourself reimplementing lisp in your program you're probably doing it wrong

who wants to code in a programming language where you can only define 1 global variable

the reason why they like it is because it gives a more or less atomic update kind of semantic

like when you swap the one atom it changes atomically

so that's useful and good

but javelin cells also accomplish that, without requiring a single atom contains all state

on a side-note, I just clocd hoplon, javelin, castra and cljson, wth? It's like 4k loc altogether

that's like java hello world size

haha i know

clojure is amazing

i'm working on this web application in hoplon at work

basically a rewrite of a c# mvc app

seriously, with that loc I don't think you are allowed to call it a framework 😛

the entire project in hoplon is about the same amount of lines of code as a single spark template file in the c# app

cool How does it compare speed-wise?

hoplon app is way faster

because it's a lot simpler code, so we don't do as much unnecessary database stuff

the c# stack with the MVC and activerecord type ORM is really hard to work with

how does cljs compare to js btw? I didn't see any comparison on that

so you end up doing all kinds of unnecessary or suboptimal things just to get somehting that isn't filled with bugs

well i make business applications

people load the app and work with it for a long time

think gmail

so what's important is features, reliability, and speed once you're already loaded

like gmail

like java you mean

if the page takes 900ms to load or whatever nobody cares

because you only do it once

like this slack app

nobody cares if it takes 5s to load slack

because you just keep it open

i think all business applications are like this

so i don't spend much time obsessing about perf benchmarks or anything

they're meaningless to me

what i care about is developer productivity

wait slack isnt cljs no?

that was just a general example right

no, i'm just saying

yeah

when you have 4k LOC total you can add features and maintain your application way more efficiently

I think a lot about productivity when I have to write these VBA monstorsities at my work

which is where my bread and butter really is

s/think/dream/

reminds me of @alandipert 's comment from your clojurewest talk about the pile of garbage that circles around in the oceans

hahaha

yes

VBA is the dark side of the undead technology

my priorities are:

first make it possible

then make it elegant

then make it fast

you can't really do those in any other order

so it's cljs -> css -> boredom

or you end up with spaghetti

oh you meant code, not the app

how do you mean?

i mean it's way easier to optimize an elegant thing that works correctly already

than it is to make something fast and crazy into something elegant

> premature optimization is the root of all evil right

like i want my application to perform well, but it only needs to perform well enough

that still needs to be balanced against other equally important concerns

like features, maintenance costs, etc

@onetom: true

i'll think a little more and be on later

i'm not a huge fan of .core, i think if we're going to have something redundant in a package name it should be meaningful

the way a hoplon segment would be

e.g. (ns hoplon.javelin) vs (ns javelin.core)

i suppose i would advocate:

hoplon/hoplon -> hoplon(/hoplon) -> hoplon.hlisp?
hoplon/javelin -> hoplon(/javelin) -> hoplon.javelin
hoplon/castra -> hoplon(/castra) -> hoplon.castra

the last one is namespace

@alandipert: consider the redundancy question in this light:

so it should contain dots

hoplon.core
hoplon.test
hoplon.svg

im not a fan of .core either

BUT it allows more symmetry again...

you can't have single segment namespaces in clj or cljs currently

so just hoplon or javelin isn't really an option

@micha: thanks for the chat! See you later guys

@xifi: see ya!

later!

hoplon.good-word-for-things-that-interface-with-browser

@xifi: you had great questions. my team will benefit from it too!

@onetom: thanks!

alandipert: hmmm core?

core is the known workaround name

hoplon.html

but it also has other things in there

it's mostly hoplon.dom

it sounds like a heresy though

hoplon.hlisp

lol

yeah, and then it wont be a surprise if u alias it to h

but it's not really such a focused namespace

it has other stuff in there, which we could extract into other namespaces i guess

but then again, it's not something which a beginner can easily guess or keep it mind...

if you're using the hoplon boot task you don't need to know about those namespaces really

when you're starting out

alandipert: here is a challenge which might cast a better light on the question: would you rename javelin.core to hoplon.javelin?

is javelin a sub-component of hoplon or is it a general purpose library on its own?

what does a github org group together? what does an artefact group id group together?

micha: what's the usual problem if i get this javelin.core is not found?

java.util.concurrent.ExecutionException: clojure.lang.ExceptionInfo: failed compiling file:/Users/onetom/.boot/cache/tmp/Users/onetom/p/hoplon-mini-example/n7y/yuvvjw/boot/cljs/main969.cljs {:file #object[java.io.File 0x4bf0aa08 "/Users/onetom/.boot/cache/tmp/Users/onetom/p/hoplon-mini-example/n7y/yuvvjw/boot/cljs/main969.cljs"]}

             clojure.lang.ExceptionInfo: failed compiling file:/Users/onetom/.boot/cache/tmp/Users/onetom/p/hoplon-mini-example/n7y/yuvvjw/boot/cljs/main969.cljs

    data: {#object[clojure.lang.Keyword 0x4b6d72ef ":file"] #object[java.io.File 0x4bf0aa08 ".../main969.cljs"]}

             clojure.lang.ExceptionInfo: Could not locate javelin/core__init.class or javelin/core.clj on classpath.

    data: {#object[clojure.lang.Keyword 0x4e7f763e ":tag"] #object[clojure.lang.Keyword 0x4d29351 ":cljs/analysis-error"]}
          java.io.FileNotFoundException: Could not locate javelin/core__init.class or javelin/core.clj on classpath.

(ns boot.cljs.main969 (:require tailrecursion.hoplon.app-pages._index_DOT_html))

(do)

@onetom: i would, because hoplon is the name of the effort and group of people aware of that effort who have the most interest in javelin

i suppose the hlisp part is the 1 of 3 parts that isn't useful outside of a "hoplon" app

since it depends on javelin

i guess castra does too

so it would seem that if anything, hoplon is defined more by javelin than anything else lol

maybe we should switch the names

http://javelin.io 😉

someone actually have it but no content on it

anyway, this compilation error is super annoying and i have no idea what causes it. this same code works in an other project:

(ns business.logic
  (:require-macros
    [javelin.core :refer [defc defc=]]))

(defc person "Bobak")
(defc= greeting (str "Hello " person))

it stopped working even with

[tailrecursion/boot-hoplon "0.1.3"]
[tailrecursion/hoplon "6.0.0-alpha7"]