I am very much a Python person, and have made a long and reasonably successful career out of it. But I generally think that if I weren’t a Python person, or decided to move on from it as my day-to-day primary language, C# is likely where I’d end up. I first learned it years ago as a backup plan in case Python and this new “Django” thing didn’t work out (because, hey, there’s always going to be work for people who know whatever the Microsoft stack is), and every couple years I check in on it and it’s evolved into quite a nice language, along with a nice web platform to work in if I ever needed or wanted to.
That said, I think the gratuitous JavaScript-bashing in this piece is, well, gratuitous.
I’ve got an issue with comparing the ruby/js/python repo issues to .net for two reasons: 1. What’s included in the base distribution of dotnet core is amazing compared to others. You don’t wonder what database connector/logging/filesystem/http/whatever library you’re going to use. They’re first party. (Yes, some of those effectively live in nuget, but I expect the advisories come under dotnet itself). Compare this to npm where every basic thing (childeexec?) is provided in 5 different flavours. 2. Dotnet community is still discovering open source as far as I can tell. Yes, there’s lots of stuff on nuget, but they’re mostly components rather than full apps with dependencies that you can find on pypi, npm, gems, etc. I’m pretty sure you could replace most of your system with things you can find in pypi.
Since the article mostly concentrated on the backend, one thing they didn’t mention is Blazor. I’ve been playing with that recently and found it amazing and magical. It contains a dotnet->wasm compiler and templated page generator. That means I could create a static website that edits some xlsx files fully client side by using some generic c# library for the spreadsheet files, and it just works. It’s the first time in a long while I’ve been blown away by a new tech.
Correct. Your description is more precise. The page loads the dotnet.wasm bootstrap and the dlls. But the end result is that you can run the dotnet code with dom hooks completely client side.
I am very much a Python person, and have made a long and reasonably successful career out of it. But I generally think that if I weren’t a Python person, or decided to move on from it as my day-to-day primary language, C# is likely where I’d end up. I first learned it years ago as a backup plan in case Python and this new “Django” thing didn’t work out (because, hey, there’s always going to be work for people who know whatever the Microsoft stack is), and every couple years I check in on it and it’s evolved into quite a nice language, along with a nice web platform to work in if I ever needed or wanted to.
That said, I think the gratuitous JavaScript-bashing in this piece is, well, gratuitous.
I’ve got an issue with comparing the ruby/js/python repo issues to .net for two reasons: 1. What’s included in the base distribution of dotnet core is amazing compared to others. You don’t wonder what database connector/logging/filesystem/http/whatever library you’re going to use. They’re first party. (Yes, some of those effectively live in nuget, but I expect the advisories come under dotnet itself). Compare this to npm where every basic thing (childeexec?) is provided in 5 different flavours. 2. Dotnet community is still discovering open source as far as I can tell. Yes, there’s lots of stuff on nuget, but they’re mostly components rather than full apps with dependencies that you can find on pypi, npm, gems, etc. I’m pretty sure you could replace most of your system with things you can find in pypi.
Since the article mostly concentrated on the backend, one thing they didn’t mention is Blazor. I’ve been playing with that recently and found it amazing and magical. It contains a dotnet->wasm compiler and templated page generator. That means I could create a static website that edits some xlsx files fully client side by using some generic c# library for the spreadsheet files, and it just works. It’s the first time in a long while I’ve been blown away by a new tech.
As far as I recall, unless this has changed, it doesn’t convert your code to wasm. It runs your code on a wasm implementation of .net.
Correct. Your description is more precise. The page loads the dotnet.wasm bootstrap and the dlls. But the end result is that you can run the dotnet code with dom hooks completely client side.
I would really love it if it was wasm completely though.