I'll preface this by saying I want to discuss the future viability of ASP.NET Core, to understand what others think of it, and to see what alternatives are available.<p>I'm worried by the direction ASP.NET Core is headed. There has been an explosion in complexity of ASP.NET Core's internals, especially the tooling systems. Microsoft has approached this new version as an opportunity to solve technical issues in the old versions but they've done so from the inside-out, in a way that exposes the developers to a lot more complexity.<p>Here is a comment taken from a chat between the ASP.NET Core developers where they answered a question about a property in the project.json file:<p>Person 1: "What does the 'imports' do in the frameworks section of project.json"?<p>Person 2: "So that's what I was referring to before. That's the ability to say 'Hey this project is compiling for net core app 1.0 which is the new TFM ah in the dot net CLI which represents an app that RUNS using the dot net core CLI. Basically you can type dotnet myapp and it will run uhm that TFM though no one has compiled for that TFM yet because you know it's brand new so if you go to nuget and download JSON.NET there's no TFM that matches dot net core app and the only TFM that dot net core app inherits from is the net standard TFM because we're trying to replat everything on net standard so in order to get nuget packages to correctly install into your project when they don't have assemblies or assets for that TFM you can tell the project system 'Please also import assets from these other TFMs' and then you're free to put in what ever TFM you want and we ill just blindly treat it as compatible. It may fail horribly when you try to compile or run uhm but obviously this is one of those back doors where you can say 'Hey, I know that this DLL inside TFM foo inside this package will work the way I'm using it so please just resolve it correctly and let me run'.<p>Person 1: "cool."<p>(continued in comments)
Now I understood none of that, but it sounds like a hack to work around something they tried to fix, or is an ugly way of gluing "old" libraries into "new" libraries which should be handled by the compiler. This is just one example of many complexities I worry are going to bog down any developers who take on ASP.NET Core. Remember we only have to face one compiler error caused by this issue before having to do a deep dive and learn all the inner details to fix it.<p>I am also concerned about the quality of the tooling. DNX can't handle long paths so I have to develop out of C: drive. This reminds me of Node's almost incompatibility with Windows and makes me worry that the tools haven't been thoroughly tested. DNX is going to be replaced yet again in the near future with a newer, probably less tested set of tools.<p>On top of that the tooling doesn't work well in enterprise because they have poor proxy support. I'm also worried about "everything is a collection of hundreds of tiny packages", the NPM dramas have shown us that micropackages lead to insanity. ASP.NET was a place to hide away from those kinds of things. Now it feels like it's "C#, as developed by the node community". I think they've tried to make things simple but haven't seen the forest for the trees. The fact that they're bundling dead tools like Bower into the project templates is also worrying. They should have had the forethought not to include any JS libraries that have a high churn rate.<p>One final thing bothering me is the number of choices of the target framework. Why have there been so many meaningless names like "dnx451", "netstandard", "netcore10"? I sit down to make a web app, and I have no clue what I actually need to target. In the old days we'd pick a .NET framework version and choose either the compact or complete framework. When did this become rocket science?
I didn't understand the comment from person 2.. I would say keep learning about it and playing but you know as do I you don't have to move to it now just cuz it's new.