quii

Well, the point I'm making is the technology choices we make, have an impact on the experience of the user, literally the 2nd paragraph.

OP here! The hx-boost hijacks links to make it feel like an SPA. I added it for fun NGL, removed it now though :)

OP here! The hx-boost hijacks links to make it feel like an SPA. I added it for fun NGL, removed it now though :)

Converting data to a HTML string is not a performance bottleneck you'll be worrying about. I wasn't worrying about it much in 2000, and you really shouldn't need to in 2023.

I think both are valid, as i mentioned in the article, for this particular case, the psuedo content-negotiation felt right

Thanks for taking the time to read the article :) A lot of the comments here seem to implying that I claim "htmx is the one hammer to solve all website needs", even when I explicitly say SPAs have their place in the article.

A hypermedia approach is the nice happy medium between a very static website and an SPA, not sure why so many people are close-minded about this possibility.

Hi, author here.

The project is open-source (https://github.com/quii/learn-go-with-tests) so there's a few options available to you.

In releases, you'll find PDFs and epubs, I'm pretty sure most epub readers will let you use a dark mode. Or you can just read the markdown files on GitHub, which also supports it.

Thanks for this, it's an important comment because it's linking to the master branch but I changed it to main a while ago so master is quite far behind.

I'm not sure how they're mutually exclusive. Also TDD is more of a _design_ technique than a testing technique. I've worked in languages with extremely expressive typesystems (like Scala) and I still practiced TDD

Just because something isn't skilled doesn't mean it's not important or doesn't bring value. The people who do these jobs deserve a decent wage and respect, not psuedo-wage-slavery

Well it's open source so just go take a look

https://github.com/quii/learn-go-with-tests

The point of "just writing enough to make the test pass" is to get you to the point where you have working software (proven by the test, even if the code is "bad")

This is the _only_ point where you can safely refactor, if your tests are failing how do you know you haven't broken something? So long as you keep things "green" you know you're ok

> The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to.

Just don't do this. You're not "done" with the TDD cycle until you make it pass and have refactored.

I reflect this in my git usage too, roughly it goes

- Write a test -> Make it pass -> git commit -am "made it do something" -> refactor -> run tests (if i get in a mess, revert back to safety and try again) -> git add . -> git commit --amend --no-edit

> It seems "safer" to write tests that are going to stay broken until every little corner of everything works properly, even though this is less iterative.

The problem with this is how do you safely refactor when you have potentially dozens of tests failing?

A big point of this approach is it makes refactoring a continuous process and makes it easier because you have tests proving you haven't accidentally changed behaviour.