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.

Why is this such a common thing? Just about every bank I've used has had one of these issues on their website:

- Password can't be long

- Password can't be pasted

- Password must contain symbols

- Password can't contain symbols

I even locked myself out of my credit card (AMEX) account 3 times in less than 2 days because they have multiple different password reset forms, but one of them doesn't enforce their password length limit, so I successfully set my password to a password that was too long for the web/mobile login forms.

It bugs me too. When found that link to post, the first thing I thought was "I'm gonna get a comment about this shitty forced signup". It's a good guide though. In a few hours I went from knowing very little about next (not a React/Web beginner though) to getting my hands dirty in the internals.

Seems like the key is "performance critical regions of code". Yeah optimize code that is performance critical. Don't optimize the other 99%.

Both of these seem like cases where you would know you're in a hot loop. I wasn't really clear in my comment that of course you should optimize loops that you know get run millions of times. I was saying: pick your tools based on the context of the code you're writing. Most simple applications involve tens or hundreds of loops that rarely iterate over more than a few values and don't get run more than once every few seconds.

That's why I said "majority". Obviously you should optimize code that is run frequently. I could be wrong, but last time I checked most applications don't involve even "simple machine learning" and when they do it's in a library or service that abstracts those concerns away.

> emulation and scripting language byte code engines

You get that these are outliers right? The majority of software doesn't need to concern itself with these problems. They're examples of software that deals with analyzing and running other software.

I'm not sure why I'm bothering to respond to these comments. This whole discussion has apparently been system developers telling app developers they need to start micro-optimizing their cold loops because "what if your user clicks the button 12 million times in under a minute".

It's also trivial to come up with countless "80s-level" examples that never iterate more than 100 times.

Iterating over a megapixel image isn't a common scenario unless you're processing a lot of large images. Obviously you should optimize hot code paths.

I was replying to a comment about the performance implications. If you decide on one method over another for performance reasons, I think it's an optimization.

> But is not more readable or even more maintainable.

Both are a matter of opinion and depend on the specific use-case.

For sure. That's what I meant by "it's not in the budget". I would probably choose to rewrite most projects I work on, but I know it's completely unreasonable for most non-trivial projects. I just meant I naturally gravitate towards wanting to rewrite because clean slates are satisfying.

> Adapting mature software to new circumstances tends to take more time and effort than writing new software from scratch. Software people don’t like to admit this, but the evidence is clear.

Software people love rewriting things. In most cases where I have to maintain an old project I would much rather rewrite it, but it's usually not in the budget.

> another commenter ...commented that performance doesn't matter - they are wrong, a switch can be nested in a hot loop ran millions of times and they do matter

I'm curious how often you find yourself dealing with loops that run millions of times? I think the majority of loops I've written don't need to deal with millions of iterations; most of them probably only rarely break 1000 iterations, and I know for sure that a lot of them can't exceed 100 iterations because of limits in the data.

Seems to me that using a switch over another structure for performance at the expense of readability or maintainability is an example of premature optimization unless you're positive the condition is going to be in a hot loop.

The nextjs website has a tutorial that I found very helpful:

https://nextjs.org/learn/

I don't really understand how headlines like this are helpful. Is there an ideal number of dependencies? How do we decide that 1568 is too high? Is it better or worse than 156 dependencies that each have 10x the LOC? How should the CRA devs address the bad big number? Rewrite all their dependencies from scratch and bundle them with CRA?

Instead of guilting developers for their dependency count, maybe we should be auditing open source project dependencies or suggesting better tips for vetting dependencies.

Based on the title I expected a post about the travel agency industry, but instead I got a long winded ad disguised to look like a blog post. I'd be more receptive if the title had just stated that the article is about a new product.

I'm probably in the minority, but I just expect web sessions to persist regardless of what checkboxes I check. If I have to login to anything on a computer that isn't mine, I just open a private session (usually incognito in Chrome).