Clojurians Log v2

Hi @fragamus

you were interested in knowing about things related to convincing a team that Untangled/Om Next were a good choice for a project. We have a number of members here that are using it commercially, so I'm sure a number of them would be glad to give you feedback on how they sold it to their team, the challenges they faced, etc. I'd say our biggest challenge has been in the cost of training people in the tooling, change, language, and other skills. If you have a team of FP people, it is a lot easier to adopt. If you're working with JS people with poor skills, I'd probably be pretty wary of trying that big of a jump.

@currentoor is the one that pushed us to try Clojurescript at our company - he can probably tell best how we managed to sell for our team.

Hi @fragamus

It was not an easy sell since we were pretty heavily invested in rails and ember. But everyone that was going to build our new app was interested in using CLJS, which was a pre-requisite. I totally agree with what @tony.kay says, if your team is full of inexperienced/unmotivated web developers I’d reconsider. I built a prototype of the product in my spare time at home, then we had a one week spike at work. We got a lot done and decided to move forward with CLJS.

There was some hurt feelings and plenty of drama but in the end we got a really solid app, we consistently deliver features on time, and developer happiness is the highest it’s ever been. So it was totally worth it. 😄

hi @fragamus We started our product about 2 years ago, and we started with Clojure, Clojurescript and Datomic. We have built most of our product with re-frame which give you some very nice tools to quickly build an application. Then when our app started to grow and we got more “complexity” in our application, our REST services were starting to get bigger and bigger and at some point where REST wasn’t really cutting it anymore. We also had lot's of parts in the application where there where multiple instances of the same thing (we work on a CRM addon) so an example is a company. If we updated a company name we would have to update the same company in four places in our app-state so we started having lot's of bugs where a company name would simply be out of date. Our app-state problems are completely solved by om.next standard database format. We had some views which would fire off 4 separate requests to just render a view. And if you start going that path there are four potential failures, handling these failures gracefully is a lot of work. And what we noticed is that most of our calls to the backend are pretty ad-hoc (so error handling there is also pretty ad-hoc). It was at that point when I saw the first presentation by David Nolen and I was also looking at GraphQL and Relay to see if there was a better way. I started experimenting in my free time with om.next and in a few weeks I ported the most complex view of our application to om.next (which was pretty damn hard) but one thing we noticed is that once we got something working it would not break easily. When we looked at the code for this view and the code of the rest of the application we decided that we liked the model of om.next better and we feeled more confident because we created components with queries and idents. When we started porting a lot more of our application we did start to run into some problems with the remoting part of om.next (which you have to invent yourself). We ran into some problems which were really hard to fix it was at that time when I remembered seeing something about untangled (which I dismissed it at that time, because it seemed to heavy/frameworky). Then I started asking some questions in the untangled slack and started with only integrating the untangled client which resulted in deleting a lot of our own code and getting a lot of stuff for free. No we also kind of integrated untangled in our backend (a part of it which was actually pretty easy). And now we are still in the process of removing re-frame from our application and building all new stuff with Untangled. We use most of Untangeld we use: Devcards (a lot, our UX designer even started writing some UI stuff in there), untangled-spec, i18n, untangled-client and part of untangled-server. Owyeah and the best part is that we have a way easier time onboarding new developers, the do all the tutorials and the untangled excercises and they are pretty much ready to go. We are creating atlassian-connect-addons and are working on base template for ourselves so we can write new addons in the complete untangled stack. Choosing all of your own libraries and stuff seems great when you work alone but when your team starts to increase investing in a "framework" can really pay off. Sorry this mostly a rambling from the top of my brains, but I hope this might help a little.

@mitchelkuijpers what company do you work for and what does your app do?

I work at Avisi (https://www.avisi.nl/en/) and I am working this add-on https://addons.avisi.com/atlas-crm/

@currentoor And what do you guys work on?

Btw the rest of the company is using Java and Angular and some are moving from Angular to Elm. Most of the company is still pretty scared of Clojure and Clojurescript

@mitchelkuijpers nice! We make saas tools for online marketers. https://www.adstage.io/reporting/

That’s the product we made with CLJ/CLJS.

Oh damn that looks nice

Thanks, here’s a sharable read-only version of a dashboard built using our product. https://s3.amazonaws.com/assets-report.adstage.io/58fceb64-9d75-4ed0-bf02-2fdd763cabf5-1481059313381

For the sharable dashboard we used clj-webdriver to server side render them to get fast page load times. Kinda janky but it actually worked pretty well with the stack.

Aha cool, I still want to look into porting untangled-client to cljc so we could potentially do that with untangled. The way atlassian-connect works is that you have a config somewhere that says you get a iframe somewhere in the layout (Confluence or JIRA) and we have some views that get show a lot and that are very important to get on screen as fast as possible, where that would be a very nice optimization. But had not time to look into this (yet).

How often do these views change?

For us, once a dashboard is exported that view is immutable.

Ah we don’t have this luxury unfortunately, because of the host product and the integrations we do

Yeah that makes things more difficult.

But because we use datomic most of our data is hot in the cache most of the time so rerendering each time is not a big problem

oh cool

But pretty cool to see such a data heavy application make use of untangled (and om.next)

Thanks!

I see some big update in the #om room about remote reads but I don’t think this really affects Untangled because we read remote data with mutations am I correct in that assumption?

@mitchelkuijpers remote reads: technically, yes. Reads are triggered by mutations. Technically, they are in plain Om Next, too...you have to do a mutation to modify app state so your parser can say what to read. Untangled is just more direct about the connection.

and standardizes what to put in app state to indicate a read

That was a big realization for me: that the only way to do anything in Om Next dynamically is through a mutation of app state. The parser then being triggered can lead to remote reads, but you don't want them to always happen, which means you need data to say when, which means you do mutations to trigger reads. Period.

thnx @tony.kay as always.

Has anyone wanted/tried to document mutations (and reads I suppose)? Right now I’m putting a :doc string along side :action & :remote, but I was wondering if there’s some other way I should or can be doing it.