atheken

This is an professional experience thing.

Types support “programming at scale” - scale in the sense of larger code based or multiple people contributing.

If you’re hacking away at a script for a web page, then yeah, have at it.

If you’re supporting more than a few hundred lines of code or working on a team, you need types to codify and communicate information that can be verified with a compiler.

Whenever you see a larger codebase that is not strongly (or statically) typed, you generally will see unit tests that are verifying the types/structure of outputs.

Yeah, dropping typescript and then codifying type information in jsdoc is comical.

The only thing I would say about your experience is that “dropping TS for go” is a little bit misleading, and it doesn’t really sound like it bears on the general debate of “TS vs. JS” - go and other static languages generally fit a different niche in my opinion, and can be a better option for certain kinds of systems.

If you’re building anything of even moderate complexity, or with more than one person, you really need the types and modularity that TS provides.

I guess it’s also worth noting that JS has actually been influenced/adopted some key features from TS over the years, so it’s possible to do a few things with it to make stuff that’s a bit more maintainable.

This one is a bit tricky, because you have to think about logging as an output or a side-effect. And as an industry, we’ve been learning that we should limit the amount of side-effects that our code generates.

If logging is getting ingested by downstream systems like CloudWatch, or other structured logging systems, it is potentially going to be used to detect service issues and track overall service health. These are logs that are serving a functional purpose that is not purely a side-effect, or for debugging forensics.

If this is the case, then you should have a unit test asserting that a log entry is emitted when a method is called. If writing that test is a low or non-priority, then even if it’s a “breaking change,” then that’s a sign that it’s not actually going to break anyone.

I’m sure there’s some monadic view of how to package up the “side-effect” logging as part of a function’s output, but it’s probably annoying to implement in most languages.

You are treating this as a binary/zero-sum game. Will we get to 100% use of tabs (or spaces)? No. Will we get a "perfect" viewer made and then adopted by all visually-impaired people? No. Making people aware that a fairly mundane choice has a negative impact on others might change their behavior, or at least challenge it.

Change like this is incremental, so just having the conversation, and asking you to consider that making a small change to your config might help some people down stream is something. Asking you to bring this point to the next conversation about tabs vs. spaces, is helpful.

I’m saying that spaces are slightly better than tabs if you don’t have any relevant disabilities

This is my fundamental issue with your original statements, and this thread: It's a subjective choice that you think is slightly better than removing a barrier/major annoyance for an entire group of people that may want or need to interact with your code. It's closing the door on possibility for a minor personal preference.

Let’s agree that we aren’t going to affect this change in this comment thread, so which one is more “pragmatic” is beside the point.

What does matter is whether we decide to have an inclusive view on this issue, and are willing to make extremely minor modifications to our settings and workflows to be more accommodating for others.

I am encountering more and more cases where people behave in inexplicably selfish ways, and this just feels like another one. It’s low/no-cost to do, yet could yield benefits to others. Low cost/risk, high potential reward.

Starting with “we’re not going to even consider raising awareness and let the market decide” is just a very cynical way to approach the world, and I’d argue is even actively harmful to the people that hold that view.

There’s a difference between doing something that’s “easier” and what’s right.

Whether there is more legacy code with spaces or tabs is irrelevant. Most of the code that will be written hasn’t been written yet.

I disagree with you on “micromanagement” of spaces vs. tabs, that is nonsense. Set up a formatter for commits and set your IDE to display how you want.

The pragmatic view on one or the other is that for a one group of people, using tabs appears to be significantly better, and for everyone else, it barely matters at all, except as personal preference.

That being said, I’m not vision impaired, so I don’t know what the preference would be.

The reason we’re even talking about it is that someone that has studied it from an accessibility perspective has asserted that tabs would be preferred.

So your fix is “convince all the people that want/need the better handling to use a specific editor?” - perhaps it’s a smaller number of people, but do you not see the irony there?

I honestly don’t care about tabs vs. spaces, but if there’s a low cost change in my setup that makes it easier on others, why not?

Hello fellow old person. I mostly agree, and I think we’re starting to see some convergence on the core patterns that will define the “best way” to deliver web apps for years to come. The various offshoots of React are really just evolutions to see what fat we can trim and tighten it up. But functional-reactive UIs as a general thing are here to stay and better than all the other ways we’ve wired up GUIs to date.

I think Roc has some ideas like this.

On a sandboxing level, I suppose we’d be talking about Unikernels (which seem cool, but the tooling didn’t look simple enough to experiment with them)

I don’t know the specifics of the golf problems, but I’m mostly in c#, also notorious for “having too much boilerplate,” and it looks like it’s 3rd by char count.

My guess is that languages with comprehensive standard libraries can do more with less custom code. As you should expect.

Important/generalized patterns reveal themselves over time. I generally push for people to just write the specific thing they need for the given context and then if the same pattern shows up elsewhere, promote the code to a shared library. It’s really hard to anticipate the correct abstraction right from the start, and it’s easy to include a bunch of “just in case” parameterization that bloats the interface and adds a lot of conceptual overhead.

That being said, with low-leverage/complexity code like html views, repetition isn’t as problematic. Although, I do think that HTML components have matured enough to be the correct unit of abstraction, not CSS classes.

Demo videos are not “documentation.” They are “demos.”

If you want someone to repeat your steps, it should be code or CLI commands. You can write more descriptive text, but as soon as you reference pictures to show something, you’re introducing ambiguity that text/code can avoid.

UIs change faster than videos and screenshots, as you said, can’t be searched, and are generally less accessible than text.

The source files for documentation should also live side-by-side with the code in the repo. As soon as it goes anywhere else, it immediately goes out of date.