yeah we dropped cljsjs and use npm + shadow directly

ditto : i haven't used cljsjs in a long time - and really haven't missed it all my recent cljs code has been built with shadow, and consuming js libs direct from npm is much nicer

Thank you for chiming in. I haven’t had much of a chance to work with shadow.

shadow was a game changer for us, i highly suggest seeing if you can get it in 🙂 the migration process from cljs-build + cljsjs to shadow-cljs was pretty painless too

I use shadow now across the board too, but afaik plain cljs.main should now also be able to consume npm deps

10x developer 😱

Or maybe 0.1x developer?

I have been loving working on the same codebase now for five and three years (for 2 different products). There is a fair amount around the outside that changes, and we keep stripping the core of the product back to make the things on the outside more flexible, but I've really been enjoying working on a product rather than a project.

The product is the same, but the legacy codebase is really dated and it shows. The Frontend is especially vile, jQuery and handlebars and a homemade framework full of magic and bugs.

A few weeks ago I was working on a part of our code base that was originally written in 2012 and after poking at it for a while I was like "What idiot wrote this code?!?! 🤯 " and of course it was ten-years-younger me when I was still really coming to grips with Clojure architecture 🙂

I definitely look back at some of the early decisions we made (we started writing Clojure code in 2010/2011) and roll my eyes... but we did eventually dig ourselves out from underneath a bunch of global state (that took several years) and with our "recent" move to Polylith, we've managed to pull apart the big-balls-of-yarn legacy subprojects that were poorly organized.

If we were starting over, knowing what we know now, we'd definitely make some different decisions around how we organized DB handling code (although some of our attempts at separating all that out over the years have been less than successful). We recognize a lot more patterns in our code these days and would know to implement them differently today.

All true. I am already sad about some earlier decisions I took with the project. I’m super annoyed though when I see a huge block of code that was clearly never re-read by the authors. Very hard to wade through, very hard to change, impossible to build upon (hence the rewrite).

I should really submit a talk sometime. Rewrites have a bad reputation but sometimes they are the right thing to do.

I remember there’s a book on “How to maintain a legacy codebase” and after a long and laborious arguments, the whole book is summed down to…

… “Good luck”

/me currently rewriting a 7 year old codebase, and very much enjoying doing so

@U04V70XH6 if I don't roll my eyes at at least some of the code I've written in the past, I know that I've stopped learning and growing.

When I joined World Singles (back in 2009), it was to rewrite the legacy platform, which was ColdFusion, and they wanted the rewrite in modern ColdFusion (OOP, frameworks, etc). Then we started rewriting it again from the bottom up in Clojure, then we switched from a monolithic web app to REST APIs and smaller web apps (with the main website being a brand new React.js app) so that was another rewrite. We're on our third gen billing engine and our third gen chat system as well. Lots of rewrites over the years. I think the "bad reputation" that rewrites have is not fully deserved -- if you're rewriting things for the right reasons and using the right tech/architecture approach. A friend of mine has recently initiated a complete platform rewrite to Kotlin (from ColdFusion) and he's putting in place a whole new approach to development at that company -- so it's not just a rewrite of their code, it's a rewrite of their process too 🙂

My legacy in the codebase: good Other people's legacy in the code base: bad --- It really depends on what you plant, build and cultivate 🙂

Well, here's some code I was looking at today

I spent 30 minutes trying to figure out exactly what kind of data this gets passed in. Some variable names are copy-pasted from another, similar-looking function, but they do not reflect the actual "thing" they point at.

• models.voters implies multiple voters, but there's only one • ideaRes implies an idea result, but this is actually a user • What is modalFlagType? Well, it gets passed in as an html attribute in a few files. Hard to grep, but possible. • flagType is unused. • Why are there three different ways the data comes in from the backend? Is it significant or an artifact of the past? Can I change the backend to simplify this code, or would it break something else? • OK, it's kind of clear that we collect a bunch of userids - which we use later to query the backend for these users. Why does the frontend do this work, and not the backend?

There's more!

• why do we iterate over the userids in reverse? (I actually just saw that) • why is there a nested loop? Why not use a map? • this.readyState(true) has been the source of numerous race conditions • same as view.render()

Oh, the template language is some old version of handlebars that I think someone customised. Upgrading to a newer version breaks various pages. Oh, and if you mistype something, there's nothing in the console. Not even an error, you just get a white screen.

Sorry for venting 🙂

Venting is good for you 🙂

@U7PBP4UVA I feel your pain! And to be honest that's my experience pretty much any time I have to deal with JavaScript (which is luckily not very often) because it's so stateful and so imperative most of the time...

@U7PBP4UVA if puns cheer you up: you are in such a bad state that it is imperative that you rewrite the code. if puns make you angrier: my apologies.

That's... punny 🙂

feel so seen reading through this 🙂 over 10 years with the same codebase. a few namespaces are being used exactly as written 10 years ago. many.... are not 😆