201–210 of 226 posts
If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.
TypeScript is great. I built https://www.findlectures.com over a year, starting in plain Javascript. Once the codebase was large enough that got stuck I added TypeScript, and it's been great for isolating defects. It's nice paired with React (vs PropTypes) because the checking happens a lot earlier and is much richer.
Nice site. I know what I will be doing tonight, when I arrive home. Thanks :)
Earlier quoted context omitted.
I think it is unfair to compare async/await on top of poorly performing code with async/await generally. Fast synchronous code being faster than slow asynchronous code is kind of tautological. async/await keeps your UI thread unblocked. Or, more generally, it keeps your threads unblocked. I have an ETL process that benefits from async/await greatly: I can stream more data in/out of the database with fewer threads. Th…
Why is it tautological? There is no performance gain for most people using async/await, at all . That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by…
Most any .NET site doing volume should be using TPL, because the framework is incredibly efficient at managing threads and preventing the pipeline from getting clogged. I've worked on dozens of APIs and sites that need to deal with hundreds and thousands of concurrent requests. Handling those in a synchronous fashion or hand-rolling state management is horrible and I'd never want to go back to it.
The only downside I agree with is the debugging, but that gets better with every C#/.NET/VS release, and you really shouldn't have a ton of complexity buried in your await block. If it hurts, there's a good chance you're violating SOLID.
Earlier quoted context omitted.
You can just use `--target ESNext` and this will disable all ES features transformations and just erase types.
Thank you!!! This is the one answer I was looking for. And it seems to be very recent, committed Nov 7 for 2.1: https://github.com/Microsoft/TypeScript/pull/12160/commits/7... Looking at the discussion on GitHub for the issue that lead to this commit I'm a little amazed at how much difficulty some people seem to have had with the simple concept. "Just pass it through without code changes, only remove type information…
The downside of using `esnext` everywhere is that someone might be employing a feature that is not widely supported in the target browser/JS engine. So it's pretty bad to start with that as a default without an understanding of the consequences.
Earlier quoted context omitted.
Also, Object.assign
Unfortunately newThing = {...thing, propertyName: value} Will always compile, even if propertyName is invalid. The only advantage over Object.assign I see is IDE support (at least in Intellij IDEA). I will still use: newThing = Object.assign({}, thing); newThing.propertyName = value; This will not compile if propertyName is invalid and is IDE friendly.
let newThing = { ...thing, propertyName: value } // type of newThing would be deduced: TypeOfThing & { propertyName: TypeOfValue }
let newThing: TypeOfThing = { ...thing, propertyName: value }
let newThing = Object.assign({}, thing, { propertyName: value })
Earlier quoted context omitted.
VSCode has become a mind-blowingly good editor. It's closing in on the power of heavy-weight IDEs with much better performance than some code editors (e.g. Atom), even.
Both VSCode and Atom are based on Electron, which is slow and battery-intensive as it is based on NodeJS. Are you saying that recent VSCode versions are as performant as, say, a C++ based editor or even (shudder) a Java based editor such as Jetbrains (Webstorm, etc.)? I last looked as VSCode (on a KDE 4 CentOS 7 desktop) about half a year ago, and it was terribly slow, even without extensions.
I'd really recommend trying it again. On a performant machine, VS Code feels like a native app to me aside from a slightly slower start up time, whereas Atom is noticeably slow. On my bottom spec 12" Macbook the difference is more noticeable, but everything feels slow on there.
Earlier quoted context omitted.
Why is it tautological? There is no performance gain for most people using async/await, at all . That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by…
> There is no performance gain for most people using async/await, at all. That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. If you have two asynchronous things to do, and they are unrelated, start them both and then await Task.WhenAll(file1Download, file2Download) . Look at the wall clock - it's up to twice as fast. Look ma, no…
So why bring it up?
And as for your condescending "Blocking operations ... block", talk about missing my entire point.
IIS is the victorian sewer, your code is the hose. IIS has many threads available to it, that's my entire point. You don't need async/await to free up those threads, it's got a ton of them ready to go.
Most programmers are not going to hit the thread limit, and when they do they can upgrade hardware while they figure out the tiny few high-impact async/awaits that would actually mitigate the problem.
It's pointless pre-optimization. We all talk about how evil it is, so why is it suddenly not evil with async/await?
Earlier quoted context omitted.
Why is it tautological? There is no performance gain for most people using async/await, at all . That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. And while keeping the UI thread unlocked is great, how many people are using this in C# web code instead? Where the entire web pipeline is already set up to naturally multi-thread by…
I'm curious what experience led to this opinion because I can't disagree more. Most any .NET site doing volume should be using TPL, because the framework is incredibly efficient at managing threads and preventing the pipeline from getting clogged. I've worked on dozens of APIs and sites that need to deal with hundreds and thousands of concurrent requests. Handling those in a synchronous fashion or hand-rolling state…
You're in the specific scenario!
If you're getting 1000s of concurrent requests, running at, say, 20ms each, that'd be 4.3 billion requests a day.
What percentage of C# devs have that kind of load?
Any plans to add C#-like extension methods to TypeScript? Or is there a way to achieve the same thing already? I know that a previous suggestion to add extension methods was closed as out of scope. But maybe it's time to revisit that, since TypeScript is now doing significant code transformations for downlevel await support.