
Om Next – David Nolen [video] - ivank
https://www.youtube.com/watch?v=ByNs9TG30E8&
======
spion
Quite amazing. This talk is not just about Om Next - its also about
ClojureScript.next. Featuring:

    
    
      1. AMD, CommonJS, ES6 module support
      2. CLJS in CLJS (yup, that works - including the standalone nodejs based REPL)
    

Thise in combination are especially huge.

With core.typed being an option as well (once your system starts growing and
the design solidifies) looks like the clojure ecosystem is really positioned
to be one of the technically strongest available for web development.

And of course, replacing that awkward REST mess seems painfully obvious now
(except for duplicated data which seems like something that might yet need
solving). Hindsight is 20/20

~~~
lewisl9029
Does 1) mean we can make use of advanced optimizations (like dead code
elimination) on libraries written in one of these formats without any
additional configuration?

If so, that would resolve what I consider to be one of the biggest barriers
for CLJS/JS interop.

~~~
jacobolus
Yes, that’s what swannodette said in the talk. Skip to 33 minutes, or see
[https://github.com/clojure/clojurescript/wiki/Google-
Summer-...](https://github.com/clojure/clojurescript/wiki/Google-Summer-of-
Code-2015) and the blog posts at
[https://mneise.github.io](https://mneise.github.io)

------
Spendar89
Swannodette never disappoints. If you're interested in this approach, you
should check out re-frame: [https://github.com/Day8/re-
frame](https://github.com/Day8/re-frame). The README is a great resource,
regardless of whether or not you intend to use the framework.

~~~
Spendar89
And for anyone who'd like to jump right in:

[https://github.com/Day8/re-frame-template](https://github.com/Day8/re-frame-
template)

Includes Figwheel, and (optionally) Secretary.

------
winstonewert
He mentions getting rid of cursors, but I'm not clear how he would replace the
modification side of cursors. i.e. I can see how a system like he describes
supports nicely querying data, how do it help a component that needs to
trigger modifying data?

~~~
Spendar89
I imagine you would trigger something like a datomic transaction, which
returns a new version of the database.

------
elwell
> 41:15

Pretty sure Apple won't approve of being able to update iOS apps outside of
their regular release cycle. If they don't care, I should be doing that now
with my HTML5 app.

~~~
elwell
Actually it may be fine, if it falls under this exception:

    
    
      3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

------
andrewchambers
Clojurescript in Clojurescript is demoed in the last 5-6 minutes of the video.
I think this is an awesome way to ship a repl with applications.

------
akilism
Yeah, that was a great talk.

I really want to try out Om Next. I've been building a bunch of stuff in Om
lately and the Falcor/Relay/GraphQL/Om Next stuff is really going to be great
to have at my disposal.

The clojurescript compiling clojurescript stuff looks great too.

------
bsaul
Why does the idea of having frontend guys directly query the db without any
kind of interface scares me ?

Seems like going the nosql to sql route once again( nosql is great until you
realize query language and schema constraints are actually a good thing).

Having some kind of pipe structure and interface between your db and your GUI
that can be used as a contract,or as an intermediate level to do data
rearranging, and can be documented, without having to know all the db schema
internals really seems like a sound approach. Now of course some people
tackling very special problems may reach the limits of such an approach, yet i
hope it won't become mainstream too soon.

~~~
lewisl9029
> Why does the idea of having frontend guys directly query the db without any
> kind of interface scares me ?

I don't think giving frontend a direct path to the db is what the talk is
advocating.

You still need a backend in front of the db, even in the special case of using
Datomic as the db, to handle things like auth. The difference seems to be that
instead of having the backend serve a messy web of REST endpoints for the
clients to consume and compose individually, the backend would serve a single
endpoint that can speak this new query language. The client can then
declaratively request exactly the data it needs in the shape that it needs it
in, eliminating an overwhelming majority of network related boilerplate on
both the backend and client.

I'm personally extremely excited to see this become mainstream. So much of the
front-end code I write on a day-to-day basis involves fetching data from
various endpoints and shaping it into a logical structure for my components to
display. It's tedious work that provides no intrinsic value. I can't wait to
not have to write any more of that and focus my time on solving actual
problems.

~~~
cageface
How does caching work in this scenario? Caching REST responses is fairly
straightforward but caching arbitrarily complex queries to a single endpoint
seems much more difficult.

Sorry if he answers this in his talk. I haven't had a chance to watch it yet.

~~~
fnordsensei
One solution is to not cache queries, but cache data, as in the case with
Datomic.

~~~
drcode
Of course then you're sacrificing some of the authentication, potentially.

~~~
sgrove
It's worthwhile watching Nubank's talk on how they manage these things with
Datomic on the backend [0] - providing a "complete" (filtered) database to the
client, http caches for queries based on tx-time, and syncing mobiles data via
transactions-since. Takes care of said concerns nicely - I'm just implementing
this stuff today however, so I'm not sure how well it'll work in practice.

[0] -
[https://www.youtube.com/watch?v=7lm3K8zVOdY](https://www.youtube.com/watch?v=7lm3K8zVOdY)

------
drcode
So, in principle I like everything with David's new approach... the main
question I have is "How well do 'recursive queries' work when the data
relationships between my components is really complex?" I think I will only be
able to answer that question by trying this approach myself and seeing how it
performs for my needs.

(Another question is: "How am I going to use this when my server's database is
a blockchain and not a conventional database [1] like datomic?" but I know
that's a niche question I'll have to figure out for myself.)

[1] Just kidding (mostly)

~~~
spion
Thats indeed something that doesn't seem to be discussed much, even if you
look at graphql's presentation -
[https://www.youtube.com/watch?v=WQLzZf34FJ8](https://www.youtube.com/watch?v=WQLzZf34FJ8)
there seems to be a lot of redundancy when "my friends including their events"
is fetched.

I imagine that a scheme based on an UUID and deduplication would work - when
constructing the response an object repository is kept and if an object with
the same uuid appears twice its replaced with a reference to them.

Going against the "don't extend JSON" best practice, that would be:

    
    
      {
        "friends": [{ 
          "name": "Name", 
          "events": [#uuid1, #uuid2]
        }, {
          "name": "Another name",
          "events": [#uuid1, #uuid2]
        }],
      }
      #{
        "uuid1": {"name": "MyEvent", "description": "..."},
        "uuid2": {"name": "OtherEvent", "description": "..."},
      }
    

And it can support cyclic references too, as a bonus. Ignoring best practices
is so... liberating.

Ultimately this is just compression though. Its possible that gzip will be
quite sufficient for most cases.

~~~
emidln
Transit [1] can do this for you.

[1] [https://github.com/cognitect/transit-
format](https://github.com/cognitect/transit-format)

------
avodonosov
I am skeptical about "component knows what data it needs". For example, I have
a component with two combo boxes: in the first combo box I select a country
and the second combo box is filled with cities of that country.

Now I need a similar thing: in one combo box I choose car brand, and the
second combo box is filled with models of that brand. Can I reuse my existing
component? If the component knows what data it displays, it can not be used to
display different data.

~~~
Skinney
If you need a generic component, then make a generic component. No one is
forcing you to specify dependencies in all of your components.

~~~
avodonosov
OK :)

------
zubairq
I personally built my entire framework on top of Om, so always good to hear
what David has to say:

[https://github.com/zubairq/coils](https://github.com/zubairq/coils)

------
agumonkey
I guess the Gregor Kiczales slides are here:
[http://www.cs.ubc.ca/~gregor/papers/kiczales-
oopsla-07-for-v...](http://www.cs.ubc.ca/~gregor/papers/kiczales-
oopsla-07-for-viewing.pdf) (page 16)

------
andy_ppp
I was thinking about this the other day and the web just magically solved all
my thoughts and wrapped it up into a perfect video.

Really excited about building my project in this (and learning clojure and Om
Next).

------
drudru11
Is there a description of how react avoids event listeners? How does it
observe changes in a model? I've never heard that aspect associated with react
before.

~~~
mateuszf
It doesn't avoid them. You listen to events, and then you change your model.
Based on new model view is rendered using the code you provide (one way
rendering - model to code). Then React compares the two instances of rendered
view (before the event and after) and renders the changes if there are any.

------
pwr
Has anyone an idea how pagination would work/look like with the presented
query syntax?

