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.

> Most any language's built in psuedorandom number generator is going to be sufficiently random that you will have no trouble.

I once collected a $3k bug bounty over this. Python's use of Mersenne Twister in the lib/random module should not be used for token generation. Mersenne twister uses a relatively small state space and is fully deterministic (it never re-seeds or mixes in new entropy). If you get a couple sequential random values you can reconstruct that state space and predict all future values. I.E. request a password reset 10x in a row and examine the tokens in the emails.

Please only use secure random number generators when creating security related tokens.

Example blog post: https://know.bishopfox.com/blog/2014/08/untwisting-mersenne-...

Is /udev/random considered secure?

Edit: never mind, your article named it as a good choice

Many mainstream languages have separate cryptographically secure rngs. The standard built-in rngs have tons of flaws for crypto work. A plausible attack vector here is something akin to a chosen plaintext attack -- request a stream of password resets to accounts the attacker controls to find the current state of the prng. Usually a couple readings suffice for the language builtins to uncover the rest of the random stream. With that newfound knowledge, it's game over, and the attacker controls the password reset links for _anyone_ requesting a reset -- polling the future reset links to account for other uses of the language's rng and to keep the attacker's internal rng stream in sync with your service.

Other flaws exist like abysmally poor key spaces. If your prng has a period of 64k and the reset links are generated deterministically from the prng, you're going to have a bad time.

The sha1 of microsecond+userdata is interesting. It has the potential to work well, but it's easy to get wrong. Latency measurements, the framework you're using, and other pieces of information can reduce microsecond timings to a few bits of entropy (e.g. there are modern systems that can only measure time aligned to 15millisecond boundaries). Once you take out the PII (most of which the attacker has access to already, so it isn't buying additional entropy), in systems I've seen there isn't that much real entropy in user state (sometimes under 12 bits even with tens of millions of users), and users who haven't interacted with your system much will have much less. If your system is closed source you might buy some security through obscurity, but that never lasts, and the underlying crypto is _probably_ flimsy at best.

It wouldn't take that much effort to go through my claims and find special cases where the strategies would work well, find workarounds for the attacks mentioned, and whatnot. That isn't really the point though. What matters is that getting this right is hard, and even a system which looks good enough might have subtle flaws that render its security all but useless. Maybe if we went back and forth enough we'd find all the problems, but there are already battle-tested solutions that are almost certainly better than anything we're going to come up with here, and in any application where security matters, ignoring those drop-in solutions is probably the wrong choice.

That said, it might very well be the case that having a certain percentage of user accounts compromised is an acceptable trade-off (or even desirable? could you then charge people to monitor their accounts for suspicious activity à la Equifax?). I think that's a choice that should be made consciously though, not as an afterthought arising from a broken security model.

I agree with everything you said. Use what the professionals have created. My point is just that some of these facile methods like my example are worse implementations and should be upgraded. But they aren't completely useless and just as bad as a 4 character password stored in plaintext on the server.

Which is how some people seem to approach security advice... "either it's up to my ideal standard, or it's a completely idiotic implementation that will surely be hacked in a fortnight."

You seem to have some balance and I applaud that. Security is a balancing act between the level of security, development and maintenance difficulty, and user experience and you have to negotiate an acceptable level that at least exceeds the bare minimum of security required.

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.

Thanks, but the parent seemed to imply one was a commercial offering and copied by the other as an open source project. That's the part I was looking to get clarification on.

No, they've both always been 100% open source (ignoring the complaints about React's previous BSD+PATENTS license). React is built by Facebook, while Vue is primarily built by Evan You (+ a team of core contributors).

The "copying" comments are largely due to things like Vue's new proposed hooks API being very much inspired by React coming up with hooks in the first place.

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.

Because of how similar they are, it would make sense to implement async/await using existing generator backends in the VM, right?

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.

I think you missed this part: "instead make developers explicitly say when they wish for the result to be async"

So using Promise.all() would be as simple as:

    const results = Promise.all(async fetch(url1), async fetch(url2))