Having VS2022 crash is certainly not expected or normal. I appreciate it must be pretty frustrating. If there’s any way you can submit a VS Feedback item when that happens, or post repro steps to the dotnet/aspnetcore GitHub repo, we’d definitely want to investigate.
The CoreRT and Mono folks certainly do talk to each other.
As I understand, Mono is going to be moving forwards with WebAssembly much faster than CoreRT will do. Mono has officially committed to it already, whereas for CoreRT it was more of an exploratory spike.
Also it makes much more sense for Mono to be the .NET runtime for WebAssembly. Mono is already Microsoft's preferred production-grade .NET runtime for most client scenarios (iOS/Android native apps, Unity games) and is designed for that kind of portability. WebAssembly is another client platform like those.
The version of the specs published to knockoutjs.com didn't match the final release. I've just updated them. Please let us know if anything is still failing, preferably at https://github.com/knockout/knockout/issues
I wish this were true, but unfortunately not. Object.observe doesn't provide any 'read' notifications, so you wouldn't be able to detect dependencies like this does.
Would that be considered negative? In any case, KO is not a Microsoft project, and only one of the core team members (me) works for MS.
Anyway, many projects are built with KO, and its 3500+ watchers on GitHub suggests it's something like 7 times as widely used as one of the libraries in the article, so it's perhaps inaccurate to say that nobody considers it!
I can so easily relate to this. Although I deal with only a fraction of the GitHub traffic that Jeremy does, it's still demoralising at times, and dominates the effort I spend on OSS. It's the equivalent of every widget owner having the CEO's home number, and it being culturally normal to call to discuss any problem or even idea for minor tweak.
One possibility I've wondered about is making the GitHub issues list read-only, except for project maintainers. Then bug reports and feature requests would go initially only to the project's forum or IRC channel, which has much less maintenance cost, because threads or conversations don't need to be "closed". If they attract enough attention (because they describe a painful bug, or a really good idea), then a project maintainer is likely to notice and choose to file an issue.
I was going to try it out, but once you've registered, you have to raise a support ticket to ask them to put a free trial on your account.
> Step 2 - Experience a Free Trial
After registering your MacinCloud website account, please log in and create a new Support
Ticket under Help > Support > New Support Ticket. Click New Support Ticket -> MacinCloud Trial -> Sales, and request for a trial. Please attach a note and let us know if you have any specific needs.
Um, no, sorry. I don't have that much patience. Honestly this could be a great service for Windows-based web developers who just need a few hours on a Mac now and then for testing, but the signup process needs to be instant.
IIS isn't blocking any of its threads once it's handed a request off to Node.js. IIS receives the incoming connection and proxies it via a named pipe into the Node.exe process, so the performance and capacity is much the same as if the requests went directly to Node.
On "Step 1: Add Friends", it showed people who I actually know (presumably who have my phone number, since that's the only info I gave that actually relates to me)
On "Step 3: Profile Information", it offered many more people, most of whom I don't actually know (presumably friends of the people from step 1)
Note that to trigger the mobile-number-confirmation request, you may need to enter dubious-looking profile information. In my case, I entered a name like "Blaah Blahh", with a throwaway email address from www.mailinator.com. If your fake name is too realistic, it won't necessarily trigger the security check.
I do have the same mobile number on my primary account, so it's possible they found me that way. But either way, it's notable that in step 1 they managed to show just the people who I would expect actually do keep track of my phone number.
No objection to your general comments, but just to clarify, knockout.js is a regular open source community project, not an MS product. Also, do try it - you might find this approach to binding to be much more compelling in a dynamic world (i.e., JavaScript).
Knockout focuses more on the front-end - helping you make a sophisticated UI that responds to view model changes using declarative bindings. It isn't as opinionated as backbone about how you should load and save data.
Both approaches are valid; either could be preferable depending on whether you're focusing most on the UI or on the data.
It can do in cases where you find that more convenient. Whenever you prefer to move logic into your view model and just reference it, you can do so. It's intended to be flexible.
How would you prove to me that you don’t still have the key for your old wallet?