5 ms·

Manual 'Till It Hurts

51 points by shprd 2y ago

robertclaus 2y ago
Not taking on any dependencies would seriously slow down most projects I work on.
- nxicvyvy 2y ago
  Maybe your projects hurt.
  - falconertc 2y ago
    Maybe his project simply has expectations beyond being a static website from 1995
- candiddevmike 2y ago
  All of this is performative masochism for clicks, IMO. There is nothing to be learned from here.
  - TimeBearingDown 2y ago
    Performative? It’s a simple trade-off. Some prefer to be frustrated in different ways.
    - candiddevmike 2y ago
      Plenty of people do that without blogging about it for HN upvotes.
      - wpietri 2y ago
        Yes, and it's those people we might best learn from. But that's hard to do, because they're the ones not writing about what they're doing. Possibly because they don't want their sincere views reflexively dismissed for being about the upvotes.
cmiller1 2y ago
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.
- spencerchubb 2y ago
  you shouldn't have to copy paste html. any backend language you use probably has templates
  - falcolas 2y ago
    FWIW, templates imply generation, which implies a build system (even if it's as simple as make or even a bash script). At least that's how I interpret the lack.
    - JohnBooty 2y ago
      No, there are tons of PHP/ERB/etc style templates that do dynamic server-side rendering at request time. There are obvious tradeoffs involved there, but I suspect the majority of web traffic is still served that way.
- wpietri 2y ago
  Yeah, I think this is a real problem for developers. Nobody gets into software development without a pretty high pain tolerance. I think the tricks here are a) developing a sensitivity to particular kinds of pain (e.g., duplication), and b) accepting that you'll have to push through a different sort of discomfort (e.g., refactoring toward DRY code) to avoid it in the long term.
- JohnBooty 2y ago
  It's true. And, the sweat-hours poured into doing things "manually" might all be wasted once you automate. Worse, you might literally doom your project -- once you're doing things the "painful, manual" way for too long, the effort required to correct course might be too great for the project to survive. And yet... I still think simplicity is worth striving for. "Manual till it hurts", radical simplicity, YAGNI, etc. All of it. There are paths to failure there, but there are plenty of paths to failure when we overcomplicate/overautomate from the start too.
lbotos 2y ago
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).
- jerf 2y ago
  Your "getting old now" implies to me that this is the first time in maybe 15 years. To my eye we've got this point every 3-4 years now. I understand why people don't want to "just write JavaScript" but the JS community has a cultural problem with overestimating the benefits of some approach, but much moreso, utterly neglecting costs, to the point of yelling at people who want to talk about them. It is slowly and laboriously getting over that, but I see a long way to go still.
- deleted 2y ago
  [deleted]
- trilbyglens 2y ago
  The react universe is the absolute worst for this sort of thing. Honestly you should have just used a jQuery plugin. You'd be done in 1hr, with nary an npm install in sight.
  - mhuffman 2y ago
    >jQuery Now that's a name I haven't heard in a while. Seriously though, it is amazing how long jQuery basically single-handedly supported the entire public facing internet. I know there was ASP and PHP/WP, but for non-cookie-cutter sites there was about 10-15 years where you could bank on jQuery as a dependency.
    - JohnBooty 2y ago
omgbear 2y ago
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.
wpietri 2y ago
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.
herrherrmann 2y ago
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.
spencerchubb 2y ago
It goes to show how horrible javascript is that it has the concept of a "build step".
deleted 2y ago
[deleted]
kypro 2y ago
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.
sublinear 2y ago
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.
- mhuffman 2y ago
  >Build tools are great for apps and "not-simple" websites. The problem is that bootcamps and similar use project generation tools even for hello world sites while baby-devs are learning. There is no nuance. In one respect this is like jumping into the deep end of the pool and gets you moving quickly, but in another it really leaves them spinning if something goes wrong. And unless ChatGPT or a lucky SO post can tell them, optimization, speed, and cost controls are off the table altogether.
- tommy_axle 2y ago
  The thing is that even on a simple site with html and css while creating it there might be issues that you can quickly catch something that assists you... tools. The page looks broken? Oh, being able to lint that html or css will quickly find any issues stemming from that but hey those are tools to introduce. Not a build tool as in generating an artifact in this case but often checking is part of that pipeline to avoid errors. I agree that it's gotten pretty crazy for certain things over the years but there's a good balance in there somewhere and it's only natural to advance technologically speaking with the addition of tools.
mid-kid 2y ago
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...

51 points by shprd 2y ago

robertclaus 2y ago

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

nxicvyvy 2y ago
Maybe your projects hurt.
- falconertc 2y ago
  Maybe his project simply has expectations beyond being a static website from 1995
candiddevmike 2y ago
All of this is performative masochism for clicks, IMO. There is nothing to be learned from here.
- TimeBearingDown 2y ago
  Performative? It’s a simple trade-off. Some prefer to be frustrated in different ways.
  - candiddevmike 2y ago
    Plenty of people do that without blogging about it for HN upvotes.
    - wpietri 2y ago
      Yes, and it's those people we might best learn from. But that's hard to do, because they're the ones not writing about what they're doing. Possibly because they don't want their sincere views reflexively dismissed for being about the upvotes.

cmiller1 2y ago

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.

spencerchubb 2y ago
you shouldn't have to copy paste html. any backend language you use probably has templates
- falcolas 2y ago
  FWIW, templates imply generation, which implies a build system (even if it's as simple as make or even a bash script). At least that's how I interpret the lack.
  - JohnBooty 2y ago
    No, there are tons of PHP/ERB/etc style templates that do dynamic server-side rendering at request time. There are obvious tradeoffs involved there, but I suspect the majority of web traffic is still served that way.
wpietri 2y ago
Yeah, I think this is a real problem for developers. Nobody gets into software development without a pretty high pain tolerance. I think the tricks here are a) developing a sensitivity to particular kinds of pain (e.g., duplication), and b) accepting that you'll have to push through a different sort of discomfort (e.g., refactoring toward DRY code) to avoid it in the long term.
JohnBooty 2y ago
It's true. And, the sweat-hours poured into doing things "manually" might all be wasted once you automate. Worse, you might literally doom your project -- once you're doing things the "painful, manual" way for too long, the effort required to correct course might be too great for the project to survive. And yet... I still think simplicity is worth striving for. "Manual till it hurts", radical simplicity, YAGNI, etc. All of it. There are paths to failure there, but there are plenty of paths to failure when we overcomplicate/overautomate from the start too.

lbotos 2y ago

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).

jerf 2y ago
Your "getting old now" implies to me that this is the first time in maybe 15 years. To my eye we've got this point every 3-4 years now. I understand why people don't want to "just write JavaScript" but the JS community has a cultural problem with overestimating the benefits of some approach, but much moreso, utterly neglecting costs, to the point of yelling at people who want to talk about them. It is slowly and laboriously getting over that, but I see a long way to go still.
deleted 2y ago
[deleted]
trilbyglens 2y ago
The react universe is the absolute worst for this sort of thing. Honestly you should have just used a jQuery plugin. You'd be done in 1hr, with nary an npm install in sight.
- mhuffman 2y ago
  >jQuery Now that's a name I haven't heard in a while. Seriously though, it is amazing how long jQuery basically single-handedly supported the entire public facing internet. I know there was ASP and PHP/WP, but for non-cookie-cutter sites there was about 10-15 years where you could bank on jQuery as a dependency.
  - JohnBooty 2y ago

omgbear 2y ago

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.

wpietri 2y ago

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.

herrherrmann 2y ago

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.

spencerchubb 2y ago

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

deleted 2y ago

[deleted]

kypro 2y ago

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.

sublinear 2y ago

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.

mhuffman 2y ago
>Build tools are great for apps and "not-simple" websites. The problem is that bootcamps and similar use project generation tools even for hello world sites while baby-devs are learning. There is no nuance. In one respect this is like jumping into the deep end of the pool and gets you moving quickly, but in another it really leaves them spinning if something goes wrong. And unless ChatGPT or a lucky SO post can tell them, optimization, speed, and cost controls are off the table altogether.
tommy_axle 2y ago
The thing is that even on a simple site with html and css while creating it there might be issues that you can quickly catch something that assists you... tools. The page looks broken? Oh, being able to lint that html or css will quickly find any issues stemming from that but hey those are tools to introduce. Not a build tool as in generating an artifact in this case but often checking is part of that pipeline to avoid errors. I agree that it's gotten pretty crazy for certain things over the years but there's a good balance in there somewhere and it's only natural to advance technologically speaking with the addition of tools.

mid-kid 2y ago

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...