The problem with .NET Core is that while the runtime is truly multiplatform, the development experience is not.
The performance improvements on each release are trully impressive, but I think at this point the focus should go towards a better development experience.
Developing on VS Code is such a hurdle thanks to the Omnisharp language server that constantly crashes, and the project does not seems to be among MS top priorities for .NET platform.
Restarting the IDE every few minutes is very frustrating and hardly justifiable from a productivity point of view.
You don't have to restart the IDE. Usually you can just tell Omnisharp to reanalyze your solution and wait a few seconds for that to complete. If Omnisharp has actually crashed, this will start up a new instance, too.
It would definitely be nice if more resources were put towards making Omnisharp smarter and more stable, especially as it seems to be the premier implementation of an LSP server.
If there was no other option I would personally go as far as pulling the power, data loss be damned.
This is in many ways worse than your typical large-scale malware or ransomware crisis (like the one that hit Maersk for example).
Malware or ransomware attacks are typically limited to internal company impact with potential stolen data (which you usually discover after it’s been stolen already).
This current situation however has ongoing external impact for as long as the platform is kept online and could even have geopolitical repercussions if a certain high-profile “real” account ends up affected.
The fact that they left the platform online for so long with an ongoing, uncontained attack is absolutely irresponsible.
The article is fun and well written, and it showcases how the marketed tools/services can actually be used to accomplish something interesting.
As long as the content is useful, should I care if it was written as a way to advertise a product or not?
This is so much better than doorslaming ads in one's face.
As much as this approach might work well for side-projects, it would definitively lead to a few pain points for bigger teams or projects. The main being that you are binding the display of your data (frontend) to your server (backend). In many cases this means multiple deploys for a single purpose, and also multiple people involved to solve a problem that might actually be very simple.
I've also seen many times this leading to the anti-pattern of building an endpoint to every single new page/feature.
Once you reach hundreds of endpoints where some of them are very similar, things starts to get messy.
I believe in most cases the API should empower the user to express and manipulate the data in every way the domain allows, even if it means building complex urls/queries sometimes.
