I'm curious why the compiled version is still referencing React code, instead of defining a standard JS data structure that JSX would compile directly into? This would remove any dependency to React itself, with the added benefit of skipping function calls at runtime. It doesn't look like there's much happening at instantiation that couldn't be done after the fact on plain JS objects: https://github.com/facebook/react/blob/master/packages/react...
There were security vulnerabilities a while ago that resulted from people being able to upload React-element-shaped JSON objects in certain places strings were supposed to go. IIRC this allowed for XSS, so React added a special symbol (the $$typeof key) that would have to be imported somehow in order to add it to the plain objects.
Unfortunately, in my experience, cats are endothermic. Give a cat a heat source – a sunny patch, a heated blanket, or a warm belly – and they will cling to it until all the heat is absorbed out of it. Cats need heat sources to thrive, so they will be very unhappy if operated as a heat source.
> Times of low-resolution displays are over. High-resolution displays are a commodity now.
I reject that premise. 4K is basically the maximum number of pixels you can get for less than $1K, and that's only a handful more pixels than a 16" MBP screen. It does not make sense for most people to shell out the $$$ just so that they can see the same number of pixels from slightly further away.
It is absolutely not the right time to upgrade your monitor. Wait until 5K+ becomes affordable again[1] so you can actually get the benefits of an external monitor (more usable screen space) without having to sacrifice the sharpness and quality of retina.
This is an odd comment considering how humans have lived hundreds of thousands of years without cars, and only a few decades with them. You’re saying that a solution that’s as old as time - and used by billions of people today - is not as realistic as a technology that hasn’t been developed yet?
We've had wheeled chariots and carts powered by animals for almost as long as we've had civilization (about 5000 years). Cars and trucks are simply more efficient (a defensible statement... https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5102965/ particularly with electrification), self-propelled versions of these.
So absolutely we will have cars and trucks well after we're able to develop driverless versions of them.
Lane change behavior looks completely unrealistic to me. I see cars switching lanes on deceleration into a traffic jam, which doesn't buy you anything (both lanes are stopped) and is extremely dangerous (you're cutting off cars approaching fast from behind and braking at the last minute). Never seen this happen in real life, except maybe at toll booths.
On the other hand, there is no lane switching when traffic on adjacent lanes clears up. In real life, drivers will quickly switch if a nearby lane starts moving. They can't see whether their own lane is also clearing up ahead, and most people won't take any chances.
Huh? I see this happen all the time. If people decide the backup is "shorter" over there (i.e. the last stopped car is a few car-lengths ahead) they will absolutely merge into another lane approaching a backup. Same behavior you see at the grocery store.
I think grandparent was referring to the fact that you can tell the compiler to ignore type errors if you so choose. The TypeScript compiler is perfectly happy to compile the code in your example, if you disable strict type checking and treat type errors as warnings. On top of that, there are simple annotations you can add that let you silence warnings as they come up, e.g. `const testVar: any = {}; testVar.asdf = "asdf";`. This is not too far off from a linter with comments to disable linting when you don't want it. So yes, technically, you can just run JavaScript through a TypeScript compiler.
Yes. As a matter of fact, I'm currently working on a large JS codebase that is a decade old. We switched over all the code to TypeScript in one go, and we are gradually fixing the type errors over time. VSCode does an excellent job of showing you type annotations and type errors inline, so the typing is very useful even if you have thousands of errors elsewhere in the project and never even run the type checker globally.
In fact, out of the dozen or so TS codebases I've worked on, I've rarely seen one completely free of type errors. And yet no team has ever doubted the value of the type system. It's a very pragmatic approach which works very well for many teams in my experience.
We opted to keep it strict (no implicit `any`) through the entire transition but only apply it to ts files, so we are indeed completely free of type errors now. We only have 50 cases of (explicit) `any` in 85K+ LOC and they're in type def files.
Let me be the first person you've met to doubt the value of the type system. I do like the in-editor support, but you pay for it with about 25% more code.
I'm certainly not advocating undoing it, but I personally wouldn't do it again (though the team has mixed opinions).
It's in the blog post, but more were created by the transition than removed. There were less than 10 issues found and none were anything that users were concerned about.
The alternative is that the code exists but it has no warning to indicate the code smell. TS is clearly preferable to that. Further, you're wrong to suggest that blocking the code from running on type errors is "the only reason" for it. TS offers very nice autocomplete support that you can't get without it as well as jump to definition and yes, warnings.
This is true of syntax, but it’s not true of the language semantics. There is plenty of perfectly valid JavaScript that isn’t valid TypeScript, so integrating TypeScript into the ECMAScript standard would require something similar to ES5’s “use strict”.
I can’t find the link which details this right now, but I believe there are/were some cases where Flow’s syntax isn’t strictly a superset of JavaScript (to do with generics and comparison operators). I’m not sure whether TypeScript has the same problem or not.
TypeScript code can be transpiled and executed even if there are type errors (just like how a linter doesn't stop you from running your code), so in that sense, it's also valid TypeScript.
no yet really. But it's good first step to have "true" variadic types support.
Right now I think you still can't represent stuff like `Promise.all` without many numbers of overloads.
Can’t help but think that spite factored in significantly in the decision. There’s a row that conflates “applicant’s history in complying with city regulations” with “applicant’s experience in operating and maintaining shared mobility systems”. Bird, Lime, and Spin all got “poor” for this row, even though they obviously have experience operating and maintaining such a system.
Bird, Lime, and Spin were only operating for a short time (at least in SF, not sure how long they were operating in other cities). Versus Scoot which has been operating in SF since 2012 (I know nothing about Skip; I assume they've been operating elsewhere).
This also isn't just "length of time operating", the same row covers "applicant's history" and "history of their users", and Bird/Lime/Spin all have a very poor history here:
> From April 11 to May 23 alone, San Francisco’s 311 Customer Service Center received nearly 1,900 complaints regarding scooters. Complaints ranged from scooters blocking sidewalk access to unsafe riding in the public right-of-way. San Francisco Public Works had to impound more than 500 scooters that were blocking sidewalks or otherwise improperly parked.
Bird/Lime/Spin have a very poor history only because they’re the only ones with any history at all. They just happened to be around when the controversy started. It seems unfair to penalize them for that, and give them zero credit for previous experience. Scoot’s been around, yes, but with a very different service.
Operating a scooter service was not illegal at the time. It was only made illegal as a retaliatory response. SFMTA and the supervisors would have liked those companies to proactively ask for permission, hence the retaliation. Skip is the only company (AFAIK) that made it a point to ask for permission first – and they’re getting rewarded for it – but I’m pretty sure they only did that with the benefit of hindsight. They were late to the game, saw the backlash against the early players, and saw that as their opportunity.
This is not true. AIUI the SFMTA told these companies that they were working on regulations governing these scooters and that they couldn't deploy them yet. Then one of the companies (I forget who) jumped the gun and deployed them anyway, so the others rushed out to deploy them too.
I don't know if this was strictly illegal, but it was certainly flaunting explicit instructions from the SFMTA.
ISTR it was Lime, and this article from March seems to back that up. The other two launched shortly after because they were afraid to lose first-mover benefits. Woopsie.
