Manual 'Till It Hurts

We've hit the part of the cycle where the tooling is now a new prison to break free from.

I guess I'm getting old now??? That said, the JS build process is insane and due for an evolution.

I recently wanted a lil drag and drop web-based mood board. Drag pictures in, have functionality to move around screen.

I searched GitHub and found one that was almost perfect. Open source, so I went to go and make changes. 500MB of build dependencies later, I was troubleshooting deep in react build tooling to just get the dang page to render.

I ended up writing my own with about 200 lines of JS (if that).

My only issue with this idea is "till it hurts" or "until it becomes unworkable" may be a threshold that's hard to notice. If you're building a website just by copying and pasting html as described in the article rather than say using a simple template system you may introduce typos, lose sync between changes across pages, etc. without realizing. "Automating" copying, for example, your header html across pages isn't just about convenience, it's about consistency.

Actual problem: too many people have a hard time distinguishing between a simple website and everything else.

Build tools are great for apps and "not-simple" websites.

Once you get into building a ton of CSS into a theme according to corporate design guidelines, several similar pages that only differ by their contained sections in the body, all kinds of custom widgets to support, etc. then you need build tools.

Otherwise I 100% agree people misuse build tools and then complain that the build tools are bad.

I'm fully expecting a ton of push back from the "js sucks" crowd who don't actually do web dev.

I think this applies at a variety of levels on a project, too.

I used to give my love of imagining futures and my love of building things free rein. But that meant I ended up building a lot of stuff that never got used, or had a bad ROI. Looking back, it just made me sad how much well-engineered stuff never really got used because I was building to my or an exec's vision, not to real needs.

I still go hog wild with imagining, but now I store the results of that in bullet-pointed lists of things we might build. Then I wait for proof of actual need before hauling out an idea (or just coming up with a new one). And even then I may write a bit of throwaway code [1], to see how sustained the need is. We manually solve a problem the first time, throwaway code the second time, and only then invest in proper automation.

I'm much happier working this way, and I get better results, because a) delaying design until actual need means your designs are based on maximum information, b) I have more time to focus on what matters, and c) I'm not carrying around as much out of date code to sort out when I realize the actual need.

[1] Note: To make this work, you have to have the discipline to throw away throwaway code. If you (or your team or your company) have a track record of not cleaning up messes, this approach is probably not for you.

I think this is too simple a rule personally. What you want to optimise for is the discounted long-term cost of not automating vs the upfront cost of automation.

While I'd agree developers often prematurely optimise, advocating to put off optimisation is crippling in many cases – especially if you're building a company with a small team. Being obsessive about efficiency in a startup is an unappreciated factor in what separate companies that succeed from those that don't imo.

It's also not so much that it hurts to not optimise, but that after a while most your day will be filled with mundane but achievable tasks, and this will prevent you from spending your time more productively.

It's the same reason you shouldn't put off fixing tech debt "until it hurts". If you wait until it starts to hurt then you've probably been suffering the efficiency / security / performance costs of putting that work off for some time. Just because it wasn't noiticably hurting doesn't mean it wasn't a cost.

I basically followed that approach with my web (browser) extension: Started with the absolute basics (HTML, CSS, vanilla JS) and slowly ran into situations where I needed more modern features – notably file splitting/imports and types to manage the growing and repetitive JS code.

The approach worked for me and I learned some neat things about vanilla CSS and JS features, but I would also rather start new projects with a boilerplate or framework, because even small projects easily grow in scope and it’s nice to be prepared for the eventuality.

Is doing this really that unworkable nowadays? It wasn't even 10 years ago when I got into programming that every tutorial just started and ended with teching you how to do it manually...

I was just trying this -- you can even do in-browser typescript compilation.

But I was missing hot-reload -- Constantly switching between the browser and my editor.

A refresh timer helped, but wasn't quite the same snappyness.

It goes to show how horrible javascript is that it has the concept of a "build step".

Not taking on any dependencies would seriously slow down most projects I work on.