I think I know the answer(s), but it’s been a while since I’ve touched on CLJS stuff and I’d like to hear it from you guys, since you’ve been committing so much time towards building a framework to make Om Next succeed: What does Om Next buy you that Reagent doesn’t? Performance wise, “simplicity” wise, query wise, etc. As the Reagent guys point out themselves, they’re very “buzzword-compliant”. And it’s certainly better than Redux by default. But I’m still trying to wrap my head around Redux vs. Relay or Reagent vs. Om Next.

@keatondunsford @mitchelkuijpers wrote abit few days ago. https://clojurians-log.clojureverse.org/untangled/2016-12-06.html

@ianchow That was exactly what I was looking for. Thank you!

I will turn that story into a more coherent thing and put it in a blog @keatondunsford @ianchow 😄

@keatondunsford In my opinion, I'd sum it up as: Om Next makes applications simpler in-the-large. Any webdev system is easy/simple in the small. Start mixing in all of the complications larger applications run into and you find yourself wanting to put your eyes out every time you look at code. Untangled makes some of the necessary decisions that Om Next leaves open, making the use easier. So, Untangled is aimed at that sweet spot of minimal incidental complexity, maximal ease. There is a learning curve...so don't mistake that part for the ease 😉

nothing anyone can do about needing to learn in this profession

at least until we have the complete set of software legos 😉

Totally, and I love that. I’m totally sold and have been for months. Just need to come up with a way to convince my new team to embrace Om.

sadly I've found the hardest problem is the interest in learning. If you can get them to do the getting started videos and the dev guide exercises, then you have a chance.

If you're trying to show examples and convince them, you'll likely fail. They have to get their hands dirty to get it....it is just too different from everything else. FP + co-located queries + rendering as a pure function + graph database on the client + ...

Luckily my startup chose to use React and Flux for their MVP, so they’re at least in the ballpark. Also, our product is pretty unique and literally functional by nature. I’m now working for Urbit. Urbit’s building a “personal server” that’s as easy to use as an iPhone on top of a clean-slate functional operating system running on an combinator interpreter whose spec gzips to 340 bytes.

I mean, you should be having discussions about how this-or-that compares in the long-term maintenance, testability. Maybe a discussion on the pros/cons of cljs itself. Instead you end up talking about isolated features in small contexts because no one knows enough to talk about the large.

The entire OS is built in a purely functional language we created, called Hoon, which is like Haskell without category theory.

@keatondunsford well, then you at least are in the ballpark 🙂 Way ahead of most, and having done a lot more work than we have, probably. We just assembled the parts.

On the frontend, we’re essentially making the browser the UI, and need a strong API to be able to build frontends that interface with your Urbit. It seems obvious, if we’re going to redo the whole thing, to move in the GraphQL direction. And it makes even more sense to move in the CLJS direction. Hence, Om Next.

Btw if anyone is interested in this, I made an #urbit channel here in the Slack. Urbit is a ridiculously cool project, and we need more frontend contributors. I’m spearheading the frontend initiative.

(shameless plug)

So, since your staff already "gets" FP, it should really be a pretty easy sell. What kind of resistance are you getting?

some of the key things that raised our eyebrows were: Bruce Hauman's talk/demo on figwheel (showing hot code reload in running apps), his devcards stuff (I need to make a video on how we use it...so cool), the idea of rendering as a pure function (which react + fp + immutable data leads to).

Getting a "support VCR viewer" for nearly free.

clj/cljs (one language and data format for front, back, and network xmit)

elimination of controllers, REST, explicit plumbing, state in the UI (Untangled provides plumbing and some add-ons Om Next leaves unspecified)

LISP homoiconic: macros rock when you need them. Other languages suck at this.

Ability to write a specification framework that can render on any number of browsers at once (untangled-spec). The combo of cljs.test, clojure.test, figwheel, and a little bit of glue code led to a very nice result for testing. Works on server same way.

Possible to write all nearly everything as pure functions, which are much easier to test (when written well)

open source language and libraries all on JVM and JSVM.

clj/cljs popular enough to not be too risky

Full interop with React, though you want to be careful what you import, because...you know...state 🙂

Tends to encourage job applicants that are excited about learning and FP...which is a big plus IMHO

Really good developer tooling for an alternative language: (Cursive or NREPL + vim/emacs)

Dynamic language with great interactive dev support: REPL, figwheel, devcards, live updates of specs, IDE features like refactoring, navigation, structural editing.

Google closure compiler integration/optimization/minification/modules

And that's just a list of features....like I said, there are also a lot of real benefits in-the-large.

@keatondunsford all of these points are great (especially for people that already believe them) but it’s so hard to convince people with rhetoric alone IMO

yep...that's why I said get your hands dirty

at my company i just went ahead and made a prototype of the product we were going to build in my own time

using om next

then after showing off a prototype that had promise, it was easy to ask for a one week spike to see how far we could get and how the team would feel about it, most of that week was spent with me doing hands on teaching

maybe you could try building a prototype first also?

i think that was main catalyst for us

I'd highly recommend using Untangled for the prototyping...otherwise you'll get bogged down in the weeds

^ this is so true

IMO it’s best to fork a working full stack demo project of untangled (TODO list mvc maybe?) and go from there

I can definitely work on a kind of prototype. That sounds fun. I think the question we’re trying to weigh is how effective we can rally a shared component ecosystem for our platform using Om versus JavaScript. To me it seems like the timing is right as a result of JavaScript/React fatigue, functional programming becoming mainstream, way better performance with the Closure compiler, etc.

I’m also kind of interested in the ReasonML/Ocaml approach that Sean Grove (has been involved in the ClojureScript community for a while) has been evangelizing recently.

what do you mean by shared component system?

Like, if the platform is good enough (which it is), as history’s shown with people writing Emacs extensions or CoffeeScript plugins for Atom, I think people would be able to accept the newness of Om.

oh i see

FWIW we don’t use any om next component libraries in our app

but we’ve been able to use js stuff like this just fine https://facebook.github.io/fixed-data-table/example-object-data.html https://hacker0x01.github.io/react-datepicker/

just wrote some om next components to wrap them

we've used victory charts

there are even demos of that in the devguide advanced UI section

and d3, which is also covered some in the UI sections of devguide

we're slowly working on an untangled-components library, which will leverage the CSS tools in untangled-stylekit. Neither of those is close to production-ready yet, though.

The form support in components is going to rock

Our project uses ~20 other projects from the React ecosystem, from CodeMirror to ReactColor. It was all golden once we figured out how to use Webpack 😉

it's really close, actually

@gardnervickers Dude! You have to share that knowledge!

I have not had time to figure it out, but desperately want to

Gladly!

did you get it so you can just require stuff and closure picks it up?

and optimizes it?

@gardnervickers BTW, I'm pushing an update to 0.6.1-SNAPSHOT that should fix your app state problem

Unfortunately it’s left out of advanced compilation but we generate externs with a plugin, lein extern that just searches for method calls.

So the way web/mobile development works today is you build your "app", which by definition comprises both a backend and a frontend. On Urbit, we want to change this paradigm towards an API-centered development ecosystem, whereby all you have to do to build a new service is construct a new API, or add on to an existing one. For example, you might want to add support for a new cryptocurrency in your wallet app, or emoji type in your messaging app, both of which are just general streams of data to which you can overlay any kind of personalizable UI to run these, since all of this application logic is being run on your personal server which you control, whereby you can do things like integrate your Facebook, Twitter and iMessage feeds into one app, or ls your Gmail from the command line, or drag and drop your Google Docs into Evernote. So on the frontend, ideally Urbit would have a kind of Github-style repository of cross-platform, purely functional Om components that you can just drop into your app without worrying about the details of what they do, and allowing for a uniform design feel across your apps that looks really clean and just works. So a bit like WeChat or Material Design in that sense. React Native comes into play because it ultimately allows you to "write once, run anywhere" with just a few tweaks for each platform. I.e. for web apps, you wouldn't even write pure React.DOM code. you'd just use React Native components, or ClojureScript-ified RN components, and port them to the web using a library like react-native-web by the twitter guys, i.e. <view> becomes <div>, <text> becomes <p>, and so on. https://github.com/necolas/react-native-web CSS styling also becomes ClojureScript-ified, and potentially in the future we could integrate something like Facebook's new Yoga library.

I saw that the clojurescript compiler now can handle different module types and (presumably?) run them through advanced compilation. We’re excited to try that out.

Do you use cljsjs at all, or rely on webpack externally for everything?

We use a mix

@gardnervickers please share your webpack secrets 😄

Making a gist one sec 🙂

thanks

0.6.1-SNAPSHOT on clojars. It changes merge-state!, which affect initial-state. It has test coverage, but I've not tried it much with existing apps. Let me know if anyone sees problems. Should clear up litter in app state.

https://gist.github.com/gardnervickers/bb01fff5a3a14406ba2f00042bdae33e We wanted to bring in react.cljsjs and friends so that Untangled and Om wouldn’t complain about it missing. So our webpack has some externals that are kinda like leiningen :provided dependencies from what I can gather. It essentially tells webpack to replace any calls to require(‘react’) with window.React.

Then we have a file under /src/js/main.js which is the top-level file webpack reads from. It’s just a bunch of clauses like

import ReactList from ‘react-list’;
window.ReactList = ReactList;

hm. I was hoping for details on the new support for using other module systems with Closure...it's supposed to work at this point, I think...but I don't know how to set it up.

I think I saw a tweet from David Nolen about that but not much else, I was planning on researching it more. I think with that we won’t need Webpack anymore.

that's my hope

https://github.com/mneise/circle-color/blob/master/scripts/build.clj#L23-L29

Cool, looks like that could be a template to work from.

Btw thank you guys for fixing up my issue!

looks good...it would be nice to see an example trying to use something where the overall library is spread out across a lot of files...maybe you just point at each file?

It’s usually just in a node_modules/ directory, no?

I may try that out this afternoon and write up a devguide bit for it

yes, but possibly a whole bunch of small files that is meant to be post-processed into one

be nice if we can skip the post-process (webpack/browserify)

but curious if we have to point to each individual file in our project.clj

and how/if cross-requires work from the externals

like I said, I'll just try it out now that I see an example

@tony.kay I think there is a branch in the om repo where they show it off

really? That would be nice.

Yeah where they consume react this way

I am on my phone right now, but I think it was done bij @anmonteiro

Not following the conversation but you might be looking for: https://github.com/anmonteiro/om/tree/js-modules

thx

Yes that's the one thnx