“they” is rather ominous.

Developers are still familiar with the concept, there are even ideas like server side rendering in react to make sites more SEO friendly.

I think the biggest issue is that there is very little business reason to support these users. Sites can be sued over a lack of accessibility and they can lose business from bad ux, so they are going to focus in those two areas ten times out of ten before focusing on noscript and lynx users. SEO might be a compelling reason to support it, but only companies that really have their house in order focus in those concerns.

Ah oops. I got bored before the paywall lol. Probably need someone to dump the contents that is a paid subscriber.

https://archive.is/q6GFm

I made it through. Maybe next time.

I won’t be using them, ha.

Sitting in an airport right now. Great.

Lindsay Graham enters the chat.

deleted by creator

We’re all going to be soo rich once the billionaires get theirs.

This is the one where Trump raped those kids.

I’m walking into spiderwebs, so leave a message and I’ll call you back.

Then I just sigh and go to archive.is and solve their captcha, so I can read the article.

Next step: to the jails and concentration camps for slave labor.

It’s the default for a reason.

I will truly never understand why people pay money to hang out on a crowded boat full of disease.

Accurate.

I think it’s pretty common for people to promote their professional feeds on their personal. It’s just weird that they are their brand.

Unfortunately Soros and Clinton were the only ones on the list. Weirdly, Trump and his biggest donors aren’t implicated.

The rhythm of TDD is to first write a failing test. That starts driving the design of your production code. To do that you need to invoke a function/method with arguments that responds with an expected answer.

At that point you’ve started naming things, designing the interface of the unit being tested, and you’ve provided at least one example.

Let’s say you need a method like isEven(int number): Boolean. I’d start with asserting 2 is even in my first test case.

To pass that, I can jump to number % 2 == 0. Or, I can just return true. Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.

Now I am forced to write a test for odd input, so I assert 3 is not even. This test fails, because it currently just returns true. Now I must implement a solution that handles even and odd inputs correctly; I know modulus is the answer, so I use it now. Now both tests pass.

Then I think about other interesting cases: 0, negative ints, integer max/min, etc. I write tests for each of them, the modulus operator holds up. Great. Any refactoring to do? Nope. It’s a one-liner.

The whole process for this function would only add a few minutes of development, since the implementation is trivial. The test runtime should take milliseconds or less, and now there is documentation for the next developer that comes along. They can see what I considered (and what I didn’t), and how to use it.

Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level. That’s outside the scope of this lemmy interaction.