Scooty

I use TS every day on multiple projects.

1 is almost a non issue. Most libraries have decent types and TS has features for adding types yourself in your project.

2 - I've never had to disable strict mode to get a library working. Worst case you can use things like `any` as an escape hatch out of TS but it is usually tucked away in a black box that is nicely typed. Do you have examples?

3 - Correctness is important for most professional software not just billion dollar NASA projects. Runtime errors cause crashes which wrecks UX.

> This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking.

I disagree. Working towards a successful "compile" isn't much different than TDD. The number of runtime errors I run into is significantly lower with TS than it ever was without which gives a very real sense of security.

You do need to understand the code but without types it can be very difficult to track down all the places that need to be fixed when you need to change your data model. Types are more important for refactoring than writing IMO

What do you do with that snippet when you realize some elements arbitrarily need more or less spacing than others because the designer decided it looks better?

Repeating yourself isn't the end of the world, and on occasion DRY is worse (look up incidental duplication).

I'm pretty skeptical about lock in. If I couldn't use tailwind tomorrow, I think I could rewrite the few dozen minimal utility classes I need in a matter of hours. IMO the implementation is a convenience.

I usually use github gists for this. Though I'm probably in the minority preferring markdown over wysiwyg.

Runtime type checking is necessary to ensure data received from untrustworthy sources matches compiletime types.

Not op, but I've written several apps with a similar setup to what was described. Both email verification and password resets are pretty simple to implement yourself.

For password reset, you just create a record with a unique token and send an email that links back to the app with the unique token in the url.

Email verification is basically the same: send an email with a link that identifies the user and hit the server with the unique token when that page loads.

They're both libraries for building user interfaces. They're related because they both solve the same problems. They also share a lot of core ideas (one way data flow, reusable components, declarative UIs, etc). I'm pretty sure React came first and heavily influenced Vue. They aren't commonly used together because most projects only need a single UI library.

I'm not sure how they're handled internally, but async functions are no longer generators. For a while after generators and before async/await, generators were used as a polyfill.

Making await implicit would make it difficult to manage parallel promises. You would either have to make an exception for Promise.all or add new syntax. It's also not unheard of to have hanging promises (fire and forget).

Types make it easier to catch mistakes early in general. Typescript has a compiler rule 'no-hanging-promises' to help avoid forgetting to await.

Top level await does more than remove a main function. If you import modules that use top level await, they will be resolved before the imports finish.

To me this is most important in node where it's not uncommon to do async operations during initialization. Currently you either have to export a promise or an async function.

The other day I was stopped on the sidewalk by someone who told me they worked for a large environmental non profit that helps save endangered species. He asked if I would subscribe to help. I offered to make a donation and was told they I can't do a one time donation and they "really need subscribers". He even told me I could just cancel after the first payment.

Taking advantage of someone being forgetful is sleazy.

My biggest problem with this claim is typescript doesn't include any support for runtime type checking.

My experience with TS has been great until I need to deal with data that comes from an external system (API, client, database). Then I either have to cast the type (which can lead to bugs where compile and run time types don't match and IMO isn't an option server-side) or I have to effectively duplicate my types by writing type guard functions.

Sitting for too long is the problem not devices. I agree a timer would probably work just as well, but the number of devices has nothing to do with fixing the problem of sitting too much (especially a device intended to help increase physical activity).

What's not to understand? Op uses a Fitbit to keep track of how much time they spend sitting to help avoid injury.

Not sure how devices or privacy have anything to do with the problem.