Fork me on GitHub

Morning all.


bon jour tout le monde


Good morning

Andrew Baxter11:07:39

Morning (I'm a little late - does this channel use Universal Greeting Time?).


Good morning Andrew, we are UGT all the way here!

Andrew Baxter11:07:38

Thank you! 👍


I'm just happy to see someone who knows about UGT!

Andrew Baxter11:07:25

Prior experience from the #C064BA6G2 channel, where I used to hang out some years ago. 🙂


aaah that makes sense. we all blame @U0525KG62 for that.

😀 2

what? who? couldn't be me

bruce 2

Good morning 🙂


A fellow team mate has proposed that we refactor our CLJS reagent frontend into Typescript and vanilla React. Not because he likes the Typescript the language more than Clojurescript the language, but because of the productivity gains he thinks it would bring by being part of a (much!) larger community mindshare, have more and better tools at hand, and not having an "extra" layer of esotericism in the shape of a language (Clojurescript) with accompanying libraries and tools that few people know off-hand. Plus, we're building in-house esoteric things because we're in an esoteric ecosystem. I see his points, and I'm swayed by the opportunity to (past the point of the actual refac, of course) accelerate productivity greatly. Not only that, but perhaps developer happiness, as well. But I've so little experience with Typescript, vanilla react and, really, Javascript, having worked solely with CLJS and reagent for 7 years. I do hobby stuff in JS, and I have complaints 🙂 About JS the language, but every choice, even CLJS, is a compromise, and I could work with JS, even if it has a lot of warts compared to sleek CLJS. Has anyone here made a transition like this, in one way or the other? Or have you worked in both worlds and have some perspective on that? Any thoughts you'd like to share?


Hm, I don’t have much recent Clojurescript experience, but I have worked a lot in Typescript and React / React Native. Which pains is this switch is supposed to solve for you? Is it simply a code base bearing the marks of some unfortunate design decisions that are hard to reverse without a rewrite? Do you need a particular library that does not have a CLJS wrapper and is not interop-friendly? Do you no longer find it fun to develop with Clojurescript? I think being completely honest with yourself and your colleagues about the motivations is important, even if they are based on wanting to try something else.


I'm currently working on a typescript/react/next codebase. Happy to swap jobs with your co-worker. 😜 (joke - I'm a contractor / consultant type and sometimes have to work with non-clojure tech 😞 ) ... My 2cents (off the top of my head, obviously): • Typescript is a pretty decent linter for JS but it can't fix a lot of the core problems with JS • There's nothing as good as clojure's core lib - every project imports lodashor rambda or underscore or all three to try and get 1/2 way there, but a lot of APIs seem to be designed under the principal of /most/ surprise, and sometimes you just end up writing for loops 😞 • The typescript community has no culture of immutability by default and it's not idiomatic to try and enforce that (leading to the lack of trust that you get from mutable objects - and no const doesn't mean "immutable", it means final) • People just litter async/await everywhere and don't think about it as a problem. Every await is a side effect and these things should be contained. I've yet to see evidence of a cultural understanding of this. • There are still a lot of decisions you need to make about how you do frontend react and they are often wrapped up in a framework, and they're all subtly different with different trade-offs - making this decision on anything other than gut feel is really hard • The JS community is bad at stability. Breaking changes happen - a lot. • npm/`yarn`/etc have their own special place in dependency hell ... I have a special hate for peer-deps • JS module systems are not really compatible with each other, and some don't support some features (like top-level promises) IDK what your experience would be like. If you have a team of strong clojure devs who write typescript in a disciplined way, I feel like you'd do a much better job than the average typescript team. I really think learning clojure has made the code I write in other langs much better. But I feel like if it was me, I'd want to be solving a specific problem, rather than some vague "benefit from the community". If you want to bring in components or other libs, are there some ways you can incrementally bring in a typescript/tsx component and try it or something? Or are you thinking of it as a big rebuild?

💯 6

We’re converting our small bit of CLJS/Reagent code to TS/React/RxJs. The reasons for this are: 1. Our main frontend code base is TS/React/RxJs. Having a corner of our code base in CLJS/Reagent means that there is a (small) hurdle for devs to work on the whole code base 2. We have not seen much benefit in terms of dev-speed with the CLJS bit. That may or may not be CLJS’s fault 3. It’s an additional complication in an already complicated build pipeline On a personal note, I see that CLJS was way ahead of the curve in 2015 when figwheel came out. Today, I’d argue that dev’ing in TS/React is almost as smooth as deving in CLJS. Apart from the lack of paredit of course, which for me is instrumental.


Probably TS has a 'green path' for which everything works and makes sense, but its reality is chaotic and churny, in ways that cljs' ecosystem isn't. Just too many actors, uncoordinated (competing, even) solutions, with greatly disparate skill levels and sensibilities across its community. With cljs one is essentially buying peace of mind. Which can't quite be quantified :)


I don't see how a rewrite would do anything for you other than delay the project another couple of years.


Is there an option to use something like Helix or uix with shadow-cljs? That brings you closer to the React/JS ecosystem without having to deal with all the gotchas


> A fellow team mate has proposed that we refactor our CLJS reagent frontend into Typescript and vanilla React. Just to state the obvious but this is not a "refactor", it's a rewrite -- and most rewrites are failures in various ways (extra cost, delays, complexity of managing two systems during the rewrite, skills transfer, change of idioms, etc, etc). That said, I've gone through several rewrites and the ones that were overall more successful were ones that happened incrementally... ...So my suggestion would be to see if some new, upcoming piece of work could be written in TS and integrated with/called from your existing CLJS code so you lower the risk of starting from scratch. At work, we chose JS/React/Redux/Immutable because at the time we started that frontend project, CLJS didn't feel production-ready -- we'd done some experiments with both Om and Reagent and struggled with tooling and fragility overall. So now we have a big backend Clojure codebase and a big frontend JS codebase and it's fairly functional in style (heavy use of lodash). If we were starting over today? CLJS all the way. For all the reasons folks have given in this thread.

😍 2

i'm looking at starting a new project with TS (FE + BE), largely because we had such a hard time finding clj/s devs on my previous project


@U0522J5HN This is a project in the public sector in a small country. The programmers are generally not Clojure experts or frontend experts, and I think my colleague's main point is that everything you try to solve in Clojurescript has an extra layer of "stuff" that you need to know and understand. You can't google "how to do x in javascript" and directly put that into your code, you have to think about how to convert it into Clojurescript. Plus, there are lots of tools for vanilla React/typescript that are either beyond our reach, or only indirectly accessible via interop libraries or whatever. So, not only is Clojure the language more esoteric than Javascript, but stuff like setting up build processes and depending on JS tools via special interop is another layer of "extra stuff" that you have to learn and maintain. I know Javascript has a lot of warts, dependencies and tools generally move fast and break backwards compatibility, and fads are always coming and going. I know this from an outside perspective because I read about it, and I appreciate how Clojure + libaries/tools is more stable and backwards compatible, and how Clojure is amazingly designed compared to the mix of paradigms and pitfalls you get in JS. But I don't know how bad and unavoidable the bad JS stuff really is. Maybe it's not so bad. I'm not in a position to say 🙂 And I'm not in a position to say how hard it is to get into Clojure as a new team member, either, having done it every day for so long. Maybe I, too, could be more productive in a good JS code base, with good tooling. Who knows? I love the good parts of Clojure so much that it's been hard to imagine going away from it, and that's also dangerous; ignoring the improvements in the rest of the frontend world because I've found a local maximum at some point in time, and have settled in, hard.


@U0P0TMEFJ I think you touch on some issues that I feel are maybe lost on my colleague; that immutability, and using a language designed around it, is a guard rail that's important in a similar manner to using types, like in TS. Also, the functional aspect of Clojure, as well as syntax considerations and, really, immutability, do a lot to reduce code size, enabling you to keep more in your head and reason on a higher level. These things can be a bit hard to quantify, though. On your point of trying things incrementally; I want to try solving specific problems, like using JS tools from Clojurescript. And when I do that, I have to admit that it feels cumbersome to be halfway there; the JS tool has its own documentation for usage that is probably mostly straightforward, and at least you'll be able to find a lot of people in the same boat if you're having problems. Now, when I want to use it from Clojurescript, I have to do something like figure out the interop myself (extra work), or use a wrapper library if one is available and hope that it's maintained and able to keep up with the changes in the JS tool. And the pool of people to ask for help, blogs to read and so on is much smaller.


@U04V5VAUN I find it so slow and unflexible to write JS because of the lumpy syntax! ❤️ paredit. But maybe I haven't found the right editor or plugins, really - I bet I could do much better in JS than I already am.


@U04V5VAUN sounds like the right decision on cutting out CLJS, for your case 🙂


@U45T93RA6 the chaotic world of JS is an aspect I fear, should I ever return to day-to-day JS work... And I see the point that, while there might be "more tools and libraries available in Javascript", that, essentially, filtering out the good and bad stuff and making it fit together (seeing as how the language itself is also a mix of paradigms, so people can write things very differently), might make the extra stuff as much of a time sink as an accelerator. That's really hard to judge from the outside, though.

💯 4

@U017AGUF30R I've been thinking about Helix, too, seeing people write good things about it here. I think I should look more into it 🙂


+1 helix - it makes writing modern react much easier


@U04V70XH6 My colleague has already implemented some small bits in TS, so doing some bits incrementally seems doable. I've no idea how hard it is once you move away from leaf nodes, though. But I don't take stuff like rewrites lightly 🙂 I've seen too many ideas left halfway to their full realisation because the sole implementor was really the only driving force, and they had to or chose to leave the idea (or the job) for whatever reason. This is also a big consideration here; unless there's a big buy-in from all of the involved developers, I fear a looooong churn with a mixed code base. My colleague thinks that our code base size is "not so bad" and has done similar stuff before, but I don't know and I haven't 😄


Maybe it's worth trying to quantify the positives and negatives? The maintenance burden is undeniably higher in a typescript project. Dependencies change and break on a regular basis. Trends change constantly and there's always a shinny new tool to switch to that's the silver bullet and will let you deliver code instantly while solving the climate crisis </sarcasm>. However, if you're expecting a lot of drive by open-source style contributors and you're prepared to be a project steward, rather than a direct contributor, perhaps a rewrite is preferable?


@U0524B4UW Finding CLJ/CLJS devs, or people willing to learn, is also a concern. I don't hire, so I don't know how big a concern, but it's been mentioned before.


@U0P0TMEFJ sure; I should write a list of pros and cons, or something similar.


I was thinking more of looking back at the work you've done in the last year (say) and trying to categorise it as "easy front-end change" or "only worked because of cljs" or something? and trying to quantify how much of that work could have been easier or more difficult in typescript? Putting something like a number of tickets or hours/days or something against a category of work might make it more obvious that there is a real problem.


I don't know how hard that is to do? ... But maybe you could get your co-worker to contribute / do-it, seeing as they're suggesting a big rewrite 😉


@U0P0TMEFJ The churn/breakage of dependencies can be somewhat mitigated by being very conservative about updates. At work, we're pretty cavalier about updating dependencies on the backend because Clojure devs value backward compatibility, but on the frontend we are several versions behind on a lot of our dependencies and we know we need to actually plan project time around any updates because we expect they will be breaking. Sure, we'd love to be on React 18 instead of React 16 which would open the gates to a lot of other changes but we know that will be a painful upgrade and we'll need to plan time for it in between, you know, actual value-adding work 🙂


It will help having a team that hasn’t swallowed a book on design patterns. My team is currently obsessed with Enums. Probably because PHP just got them :man-facepalming:


@U04V70XH6 - Sure. But that's still a mitigation action that needs to be taken, and the pressure to upgrade grows over time, at least partly driven by exactly the scenario that Reefersleep mentioned - the desire to find examples on the web and copy and paste. It's a choice to be made and it has consequences (some of which may be small). I think it's really hard to give useful advice from outside the organisation that's considering a change, and the main factors that influence people's preferences are not technical. There are lots of contextual factors that contribute to a "good decision" ... If it was my company, I'd be fighting tooth and nail to stick with cljs, but I'm an opinionated nutter on the internet handing out advice ... what do I know? 😜 ... I think my advice is to try and find a way to make an objective decision that everyone can agree on. Maybe that's to do with the type of work that goes on and the churn of employees, or whatever, I don't know.


@U0P0TMEFJ it was my company, and i would much rather be working in clj/s were there no other constraints, but i had a really hard time hiring for clj/s, so I'm regretfully looking at ts for my next project

Rachel Westmacott08:07:34

On the backend I was lucky enough to be able to choose Clojure for our company. Hiring was a concern, but has not been a problem. We've maybe mostly hired Java devs, but honestly we've been lucky enough to be able to get quality devs from a range of backgrounds who are happy to learn. I don't think any of them have regretted learning Clojure. When we were choosing a front-end language recently we considered Typescript or JS, but it was a bit of a no-brainer for the team to use Cljs - I think mostly because it was Clojure was already the accepted backend choice.


Read the whole thing in a sitting. So that was by the HTMX guy? Smart dude.

😜 2

yeah, I like that guy's thinking!


morning and TGIF 😅

👍 2