Clojurians Log v2

Hey, We are using Om for a 3 years old app. the app has thousands on lines of code in Om, and we are looking for a way to update the library to Om-Next to enjoy latest features. what is the transition path we should follow?

@itamar as far as I know. Om-next is different altogheter not just a new version of the old om 🙂

I know

this is the reason im asking for an idea of migrating to Next

can Om and Om-next run alongside each other?

haven't tried. But that could be tricky. Also worth considering if you want to go with om-next, fulcro or qlkit 🙂

👍\

will Om be updated with a new react version, or is it deprecated?

Yeah, I’m in a similar position. Considering reagent or something similar; not interested in giving up the abstraction benefits.

@briantrice Why not fulcro ? 🙂

@claudiu anything promoted that acutely feels like a scam.

i think its being promoted because there’s a guy who is actually trying to earn his living off it

I appreciate that, but the marketing language around it is exactly the sort I’ve seen oversell frameworks and kill small startups like the one I’m in right now.

@briantrice I would suggest you try to learn beyond the market, Fulcro is the community work (in great part lead by @tony.kay) from some of the people who actually put Om.next to test. I've been following/using it since it was born (when it was still called Untangled), the project has grown and evolved a lot, it's been years of effort development on it. so if you are considering the options for your next go, this should at least deserve a proper look, it's by far the most mature current option for graph driven UI's available in CLJS at this moment

@briantrice hmmm never thought about that. Been using it since it was named untangled (mostly because of: initial app state & built-in read parser). The amount of work that's been put into it is just crazy, apart from library arhitecture & supporting libs.... support on slack, the docs, videos are really awesome etc. For my startup it's just perfect since it reduces crazy amounts of complexity from the UI. My only pain point with it so far is that I wish it would get more community adoption 🙂

Yeah, I’m just too burned by market-speak frameworks.

@briantrice marketing language? I wonder what you’re seeing that is turning you off? The fact that I think the model reduces incidental complexity??? That’s what the Om Next/data-driven model, combined with Clojurescript does

It’s a library. It’s a few thousand lines of open source code. But, to each his own I guess.

When I hear nothing but positives, it’s nothing but alarm bells that the person involved hasn’t been confronted with the limits of their own vision.

Ah, I see.

“too good to be true”

I’m the sort of person who reads an essay on how to avoid burnout and laughs at how naive the author is at their level of burnout.

I own a Lisp machine, if that helps you understand my mental frame.

Actually, that’ll probably make you ignore me.

I’ve seen this language before, and it ends badly.

Everything has its pain points. The single-atom database brings lots of advantages, but it can be a pain to look at. Clojurescript is still immature on using js deps (shadow-cljs is better), etc. Lots of down-sides…but I see those as more apparent

Whatever. What I want is an honest appraisal of what the hot new framework does not address. And I mean a painful, hard-won wisdom.

good luck on that

Marketing that speaks to me acknowledges that everything ends in frustration or failure. Meet that failure honestly, and I’ll go with you.

There are frameworks that do this. Or at least manage not to oversell themselves. At least don’t smell like you’re overselling.

Core Om does not oversell itself, and I appreciate that.

Here’s an example of an honest appraisal (of GraphQL): https://antoniogarrote.wordpress.com/2016/11/23/graphql-is-for-silos/

sure, but it isn’t by the author of graphql, is it?

Nope. And GraphQL stinks of the author’s self-esteem, which is why I didn’t touch it.

ok. Well, like I said. To each his own 🙂

seems you’re pre-shooting yourself in the foot to avoid others doing it for you instead of doing the (admittedely hard work) of actually evaluating things by studying them.

That’s not what this is about

I’ve been around a few blocks and know how adoption cycles go. I have experience.

I can evaluate these much faster than someone with a decade less experience.

I appreciate the feedback. I’m not much of a marketing guy…suck at it to be honest.

Guess it might be better to just have documentation, and say a lot less.

the irony about all this is that from what i’ve seen @tony.kay seems super up front with what fulcro is not good at. just the other day somebody asked about a use case for it and tony immediately told him that’s not the best use of the framework. the fulcro-datomic repository says straight up “this isn’t high on the list of things to maintain”. i really appreciate that personally.

@briantrice Interesting approach. Think I'm a bit younger than you, had my share with nice ideas that seemed perfect at the time and after I experimented on my project, dropped them really fast: php frameworks, python, immutablejs, flux of the month, redux, graphql etc...

My approach is usually "I know it after trying it out on a small prototype", that's pretty much how I got into clojure without any FP background and given this ugly/alien syntax (first encounter with lisp), just decided to give clojure 1 month of my time. 🙂

For me, js & redux are not it, nor is re-frame, rum, keechma, om-next (although it came close, model is brilliant). Closest thing was om-next so if not for fulcro would have probably tried to build "my own fulcro" on top of om-next or just give ELM a try.

Yeah, and honestly Fulcro may be the right thing, but I have to sift through enthusiastic language and get some buy-in across the team and a plan.

I’ve used CL since the mid-90s and only adopted Clojure/Script in the last 6 months and dig it. But I had to learn a bunch of coding patterns to optimize Om usage that weren’t obvious up-front and would never appear in a small demo app.

Our apps have so many features on one screen that interact with each other that interdependency management is key to whether something is worth adopting.

I’m grateful the examples are better than TODO-MVC at least.

As a reference point, the most complicated web app I’ve shipped to the public is Tableau Web Authoring which was pretty daunting at the time and used in-house reactive-like frameworks.

The biggest downside for me with om-next & fulcro, was the mental shift (felt a bit like learning clojure coming from python, js). The re-frame like stuff just clicked since its very familiar to me.

But the active slack channel, book & videos make the shift as easy as possible, but yep requires a bit of getting used to the mental model thats not familiar, but is pretty darn easy.

Might be just me not being a quick learner though :)