7 ms·

I'm working on a .Net Core project currently. I'd definitely go with .Net Core, but it has quite some problems currently. We do integration tests with mocha/ch

I'm working on a .Net Core project currently. I'd definitely go with .Net Core, but it has quite some problems currently. We do integration tests with mocha/chai on node and that is just about as much untyped js as a project can take imho. For node there are a gazillion of libraries (i mean frameworks ) but so many are lacking in quality for so simple stuff what you take for granted in the .net world that choosing the right one slows us down. On the other hand for .net core many libraries simply do not exist (yet). Regular .net stuff wasn't ported, and imho it won't be done until the next tooling arrives. The tooling is the second con, and will be until 2017q2. The project.json is a terrible format, the visual studio tooling is lacking, incompatible, and is slowing ua down. The tooling has some nice ideas but is too rough around the edges. Debuggning has some inconveniences sometimes, but generally works. Clean does not clean the solution properly. No complaints when a file was open and could not be replaced, shows build as success, then you hunt phantom bugs because of this... Not as mature development experience as with java/full .net 4.5 We have bet on core getting there, but expect inconveniences until then.

Sacho 10y ago
> The project.json is a terrible format The latest asp.net core templates(shipping with VS 2017 RC) use .csproj files, so you can test them out already. > On the other hand for .net core many libraries simply do not exist (yet). This is partly due to MS making such a huge mess out of the ecosystem, going through dnx to dotnet and switching around targets to settle on netstandard. Hopefully things have settled by now and library authors can catch up. There's still one more compatibility snafu to get through with the transition from netstandard 1.6 -> 2.0 and .NET framework versions 4.6.1/4.6.2. If you suffer from "javascript fatigue", it's best to stay away from .NET Core right now - it is going through the same churn of rapid reinvention. We're using it for some smaller projects and are really happy with where it's going, but it's not been an easy ride.
- kodfodrasz 10y ago
  We know that the new tooling is supposed to solve many problems, but until then we stick to the stable versions as we have no problems with the runtime so far, and got other stuff to work on until then. :)
TheAceOfHearts 10y ago
I saw this thread and searched for ".net core" to read up on it. When I opened one of the results, the first thing I saw after being redirected was a full screen modal asking me to take a survey [0]. It's unlikely you're one of the people maintaining the website, but maybe you know someone or can pass on the message that it's pretty tasteless to show that kind of modal on the first visit. Heck, why would you even ask for someone to complete a survey before they have a chance to try the experience? [0] https://i.imgur.com/8sDrr6A.png https://i.imgur.com/8sDrr6A.png
olalonde 10y ago
> many are lacking in quality for so simple stuff what you take for granted in the .net world that choosing the right one slows us down Do you have some examples? I was under the impression that the JavaScript/Node.js ecosystem was bigger, but maybe that's the HN bubble.
- kodfodrasz 10y ago
  The ecosystem is big. Too big, you spend almost as much time trying to find the right tool as it takes to do it from ground up. My example: I needed to work with dates. Under .Net the DateTime and TimeSpan types do this pretty well, and under Java 8 it is also well solved. Under JavaScript this is not so clean. I found the moments library to work well, but had some tries before. With one when I tried the example code from the homepage I received Nan/NaN/NaN NaN:NaN:NaN as a string representation for a valid date :D This is a thing which is "trivial" (you expect it to be there, and be solved) and you expect it to just work if not socialized in the JS world. Surely I'll encounter other such things, even as we use JS only for integration tests. Also the Java/.Net ecosystem is also big, but does not completely overlap with the JS world, and stuff doesn't get reimplemented so often. (JS attiute in the HN bubble: This library had no release and no tweets in 2 weeks. The project is dead! have to rewrite from ground up!)
- pjmlp 10y ago
  I keep focused on Java/.NET world (occasionally C++), only using JavaScript on the browser. Being bigger doesn't mean better quality, in tooling, performance or libraries. I had a laugh at a Code:dive lighting talk about the amount libraries in npm to create a directory!

Sacho 10y ago

> The project.json is a terrible format The latest asp.net core templates(shipping with VS 2017 RC) use .csproj files, so you can test them out already. > On the other hand for .net core many libraries simply do not exist (yet). This is partly due to MS making such a huge mess out of the ecosystem, going through dnx to dotnet and switching around targets to settle on netstandard. Hopefully things have settled by now and library authors can catch up. There's still one more compatibility snafu to get through with the transition from netstandard 1.6 -> 2.0 and .NET framework versions 4.6.1/4.6.2. If you suffer from "javascript fatigue", it's best to stay away from .NET Core right now - it is going through the same churn of rapid reinvention. We're using it for some smaller projects and are really happy with where it's going, but it's not been an easy ride.

kodfodrasz 10y ago
We know that the new tooling is supposed to solve many problems, but until then we stick to the stable versions as we have no problems with the runtime so far, and got other stuff to work on until then. :)

TheAceOfHearts 10y ago

I saw this thread and searched for ".net core" to read up on it. When I opened one of the results, the first thing I saw after being redirected was a full screen modal asking me to take a survey [0]. It's unlikely you're one of the people maintaining the website, but maybe you know someone or can pass on the message that it's pretty tasteless to show that kind of modal on the first visit. Heck, why would you even ask for someone to complete a survey before they have a chance to try the experience? [0] https://i.imgur.com/8sDrr6A.png https://i.imgur.com/8sDrr6A.png

olalonde 10y ago

> many are lacking in quality for so simple stuff what you take for granted in the .net world that choosing the right one slows us down Do you have some examples? I was under the impression that the JavaScript/Node.js ecosystem was bigger, but maybe that's the HN bubble.

kodfodrasz 10y ago
The ecosystem is big. Too big, you spend almost as much time trying to find the right tool as it takes to do it from ground up. My example: I needed to work with dates. Under .Net the DateTime and TimeSpan types do this pretty well, and under Java 8 it is also well solved. Under JavaScript this is not so clean. I found the moments library to work well, but had some tries before. With one when I tried the example code from the homepage I received Nan/NaN/NaN NaN:NaN:NaN as a string representation for a valid date :D This is a thing which is "trivial" (you expect it to be there, and be solved) and you expect it to just work if not socialized in the JS world. Surely I'll encounter other such things, even as we use JS only for integration tests. Also the Java/.Net ecosystem is also big, but does not completely overlap with the JS world, and stuff doesn't get reimplemented so often. (JS attiute in the HN bubble: This library had no release and no tweets in 2 weeks. The project is dead! have to rewrite from ground up!)
pjmlp 10y ago
I keep focused on Java/.NET world (occasionally C++), only using JavaScript on the browser. Being bigger doesn't mean better quality, in tooling, performance or libraries. I had a laugh at a Code:dive lighting talk about the amount libraries in npm to create a directory!