6 comments

[ 5.0 ms ] story [ 16.1 ms ] thread
Again, we must repeat ourselves by creating a server-generated template in addition to the Ajax script. The button will link to the template, although Ajax will override that if the JavaScript is fully loaded and supported. This is a requirement, by the way, and not a nice extra. It’s the fundament of web development. Not repeating yourself is unprofessional in this situation.

This is terrible advice to anyone in web development. DRY is a principal for a reason that applies to web development just as much as every other form of software development: management of complexity. The more code existing in a system relates correspondingly to he complexness of the system. More complex systems, in-turn, are harder to change and harder to test. DRY limits complexity and makes it more responsive to change by (1) reducing the total amount of moving parts in the system and (2) reducing the scope of the change itself.

The writers arguments are strawmen that don't actually say anything about DRY. Needing to ensure your application works without Javascript can be solved in various DRY ways, one of which being shared client / server JS.

"Not repeating" can trade linearly growing complexity via additional lines of code for potentially polynomial or exponential growth of complexity via dependency graphs. Padleft is an example of butterfly flaps disrupting global commerce even if "Github is down" tweets are the more normal mode of distributed failure via side effects.

There are silver bullets. It's a good idea to dodge them, even for non-werewolves.

host it yourself, and vet your garbage
My apologies for not understanding your comment. Please clarify.
He means that left-pad was an example of an issue with package managers, not an issue with DRY. Running a production system reliant on external services like NPM is a bad idea and is bound to fail eventually. Running an internal mirror of NPM that you control mitigates the issue without breaking DRY.
Mirroring NPM creates a nonDRY context in the network context. Perhaps it makes the software engineering tradeoffs of DRY versus nonDRY in source code explicit: availability versus consistency versus partition.

Repeating the same code in two files/modules/functions/blocks facilitates diverging independent development directions over time. A possible benefit if it turns out the business logic needs to be less similar than I thought originally to handle the two cases: in a building the shared logic of toilet rooms and kitchens is of less importance than the divergent logic of eating versus shitting, even though each is captured by a bubble on the initial space diagram and connected to waste, water, hvac, and electrical systems in the instantiation.

As a strategy, solving padleft type via generalized copying makes package management partition tolerant and available. It comes with the security problems of delayed patching, i.e. CAP's consistency.

TANSTAAFL.