I think that in medium project rebuild phase is extremely slow. I can't wait after any code change for a 20-50 seconds to rebuild projects and then run tests. On Go or Node.js it happens almost instantly (1-2 seconds). Why .net core build process is so slow?
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
I agree that the rebuild time depends on the size of the solution. I wouldn't recommend this for medium/large solutions (50+ projects).
.Net is a compiled language. If I good remember, NodeJS bases on Javascript which is an interpreted language. The comparison between them doesn't make sense.
In the case of Go the situation is different. Go belongs to the compiled languages family. It's hard for me to say why Go is so fast because I've no experience with this programming language.
It could be an interesting experiment to compare build time for the same solution coded in both C# and GO. I can only guess that maybe the vast amount of dependencies in C# (.Net) slows it. But that is just my assumption.
Thank you for your reply. Node.js precompile javascript code before run it.
I think that .Net Core need some more intelligent mechanism than just simple watch(build project and all it's dependencies on source change). TypeScript and Node.js doesn't rebuild all project after one file change in watch mode. It rebuild only changed portion of code.
It will be cool if .Net Core introduced that feature. For example i change ClassA => Some mechanism detect this immediately (like nodemon) => Recompile ClassA => Recompile all referenced code that use ClassA => Patch assembly.
In early days of .Net Core (first bettas) it used another build engine (not old fat MsBuild) and it worked a lot faster than now.
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
Unfortunately, it isn't that simple. The example that you gave (Typescript and NodeJS) is excellent.
First of all, Typescript files are being transpiled to the ”pure” JavaScript. That process doesn't have to cover all files. Only files that have been changed have to be translated into the new language.
On the other hand, in the compilation process, we are not able to extract and compile only modified files. The compilation has to cover all files to produce a library which is being treated as the comprehensive part of the software.
I think that is the difference which causes that you and I have to wait longer for the build result.
I think that in medium project rebuild phase is extremely slow. I can't wait after any code change for a 20-50 seconds to rebuild projects and then run tests. On Go or Node.js it happens almost instantly (1-2 seconds). Why .net core build process is so slow?
I agree that the rebuild time depends on the size of the solution. I wouldn't recommend this for medium/large solutions (50+ projects).
.Net is a compiled language. If I good remember, NodeJS bases on Javascript which is an interpreted language. The comparison between them doesn't make sense.
In the case of Go the situation is different. Go belongs to the compiled languages family. It's hard for me to say why Go is so fast because I've no experience with this programming language.
It could be an interesting experiment to compare build time for the same solution coded in both C# and GO. I can only guess that maybe the vast amount of dependencies in C# (.Net) slows it. But that is just my assumption.
Thank you for your reply. Node.js precompile javascript code before run it.
I think that .Net Core need some more intelligent mechanism than just simple watch(build project and all it's dependencies on source change). TypeScript and Node.js doesn't rebuild all project after one file change in watch mode. It rebuild only changed portion of code.
It will be cool if .Net Core introduced that feature. For example i change ClassA => Some mechanism detect this immediately (like nodemon) => Recompile ClassA => Recompile all referenced code that use ClassA => Patch assembly.
In early days of .Net Core (first bettas) it used another build engine (not old fat MsBuild) and it worked a lot faster than now.
Unfortunately, it isn't that simple. The example that you gave (Typescript and NodeJS) is excellent.
First of all, Typescript files are being transpiled to the ”pure” JavaScript. That process doesn't have to cover all files. Only files that have been changed have to be translated into the new language.
On the other hand, in the compilation process, we are not able to extract and compile only modified files. The compilation has to cover all files to produce a library which is being treated as the comprehensive part of the software.
I think that is the difference which causes that you and I have to wait longer for the build result.
Thanks Rafal for you'r response , but what is the magic behind livesharp.net/ ?