Why use .NET technologies vs., say, Node?
-
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript. Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app. So what's you're take? Why would you use one vs. the other for back-end development? Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsMy personal experience has been that classic C# MVC (Without .NET Core) is often the easiest to debug for complex business logic (not necessarily UI logic). I spent most of my years developing ASPX WebForms (or PeopleSoft hack... [1]) and a little time with ASP.NET MVC and some JavaScript and even a small bit of Node.js. I've even snuck F# and Haskell in (for simple tasks) when I could. My experience with Node.js in VS2019 was that the intellisense and debugging wasn't as rich as what you would get if you used old-school C#/MVC. Seems I couldn't drag the instruction pointer around at will like I could in C#/MVC and I maybe couldn't run certain commands in the debugger window when using Node.js instead of C#. Also, when using C#/MVC I felt the intellisense was quite rich but I didn't get that same feeling with Node.js in VS2019. You might have a better experience with Node.js in *other* IDEs besides VS2019. Then there is the whole part of the "stupid errors". I'm unfortunately a very absent minded person so I often make "stupid errors" in JavaScript that I wouldn't make in C# because C# protects the user from some level of "stupidness". That's where Haskell comes in. I know this is off topic, but Haskell has a really rich type system and is highly immutable so is really hard to achieve side effects or stupid errors in pure Haskell. With that said, I've found the debugging/IDE experience in Haskell to be a bit awkward even if I personally do feel Haskell is the best overall language for Line of Business applications. I think Microsoft tried to bring a "Haskellish" language called F# to the masses, but I think they kind of messed it up by making F# impure. I think this decision on Microsoft's part was to reach a broader audience and make it easier for F# to work with .NET but honestly, as much as I respect Don Syme (and other great F# contributors), I feel Microsoft may have been better off just sticking with pure Haskell and highly discouraging mutability. Now, I think the fact of the matter is that Haskell, F# and maybe even C#/Classic MVC "might" require a higher learning curve than Node.js. The callback and promises in Node.js did seem to give me some headaches but I got over them and I found Node.js to be very intuitive. The libraries in Node.js felt pretty mature to me. Things like WebSockets felt quite trivial in Node.js to me but they seemed to be a royal pain to me in C#/MVC. Regarding .NET Core. Personally, for everything new, I would use .NET Core instead of Classic MV
-
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript. Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app. So what's you're take? Why would you use one vs. the other for back-end development? Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsDepends on so many things... but I'd probably stick with C# because you could be able to get away with a partial rewrite to (for example) factor out WCF or migrate to .NET Core. I've not had *that* much exposure to Node (what I have has mostly been from writing some Electron apps), but I'm not keen on it... Could be because of Javascript - I really don't like Javascript... I'd prefer to use something like Purescript, because it's got a proper type system. Having said that, I'd sooner use F# than C# for the same reason... Crazy type dude...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript. Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app. So what's you're take? Why would you use one vs. the other for back-end development? Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Callsrewrite or port? If you had to port/upgrade the project, do not see much reason to switch the language. The basics likely the same, but I could imagine a bunch of headaches due to hidden logic operations. Some function which is 1 based counting in .net but 0 based in Node/JS (looking at you javascript Date getMonth value :mad: yet days of the month are 1 based :confused:) If rewriting, with a stack of helpdesk tickets thrown in, weighing Node.js as a possible replacement is well within consideration. Azure functions can be done in multiple languages if moving away from self hosted to code as service.
-
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript. Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app. So what's you're take? Why would you use one vs. the other for back-end development? Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsMarc Clifton wrote:
So what's you're take? Why would you use one vs. the other for back-end development?
If all you have is a hammer, then even screws look like nails. What languages and technologies do the future developers you're going to want to pass the maintenance off to know? Use that (even if you consider it to be the wrong tool for the job).
I live in Oregon, and I'm an engineer.
-
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript. Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app. So what's you're take? Why would you use one vs. the other for back-end development? Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsIf I were to create a small webapp without the need for significant security, I would consider using node all the way. It is after all very convenient to only have one language to work with in an app, also I do love typescript. Yet, as mentioned, if we are talking about a larger app and need for some real security, .net core is the only way to go for me. Mostly because I know it well and also because I know how to secure my apps using .net core. With node on the server, while it may be possible to write secure code with node on the server, I would have to learn that all over again and given I own my own iis server that would not be something I would even consider at this point. Also, there is Blazor for .net for writing wasm web apps, that I consider using in the frontend instead of Typescript and Angular, because it is convenient to only have one language to work with in a project. My current app, while Blazor was out as a demo when I started, has an Angular frontend and a .net core 3.0 ef core 3.0 backend.
-
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript. Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app. So what's you're take? Why would you use one vs. the other for back-end development? Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsWhat is all this nonsense about Node and C#? You mean to tell me you did not write your back-end in the one true language of LISP? Hark, thy hast done wrong! Repent, my child! Seek thee of that which hast the ever loving and gentle embrace! :java: Ah, that is better. Well, gentlemen, ladies, now that I have been refreshed, let us have a civilized and quaint discussion. I expect you all here at 4 sharp for tea. In all seriousness, I have heard that .NET Core is superior to Node as of now. Though, I have nothing to back that up with. Personally, I would stick with something that I was familiar with and not do a rewrite into different languages. But, I would also listen to what they say, if they can make a good case for the switch, and provide ample amount of data to back them up, then perhaps it could be an option to consider. Might want to prepare a defensive case for your side of things on that path.
This is my signature, There are many like it but this one is mine.
-
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript. Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app. So what's you're take? Why would you use one vs. the other for back-end development? Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls -
TypeScript isn't a language as much as it is a wrapper around javascript. It's still javascript.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Wouldn't that be true of any language? Say, C or C++ being a wrapper around assembly language, C# and Java being a wrapper around their IL, which in turn is a wrapper around assembly?
-
Wouldn't that be true of any language? Say, C or C++ being a wrapper around assembly language, C# and Java being a wrapper around their IL, which in turn is a wrapper around assembly?
No, it's not the same at all. Typescript simply adds features to an existing language, and is not a language itself. Your other examples are languages unto themselves.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript. Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app. So what's you're take? Why would you use one vs. the other for back-end development? Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsWhy would you use one vs. the other for back-end development?
Two Answers... MOST PEOPLE ... Choose what they know best as the language solution. I could bet money that if you did a poll asking both: 1) Which language do you know best? ... and ... 2) Which language would you choose? ... that there would be a 95% correlation between the 2 answers. THINGS WE SHOULD BE ASKING: 1) Is the expected lifespan of the desired language good? (If you have to have to rebuild in 7 years, then either your language, or more likely your application architecture (or Software Architect) is broken. 2) Is the language supported by a good library base (connectors to different databases, etc). 3) Does the language or its libraries have significant characteristics important to your application which are not available in other languages (i.e. set based processing of SQL for reporting productivity) 4) Does the language support the desired environment characteristics. (RAM usage, response times, CPU requirements, scaling, ...) 5) Is the language supported by a good experience pool? (i.e. can I easily hire new people to support it, and the associated things it may also require, like IIS or Apache) 6) Is the language going to unnecessarily increase the required breadth of skills for my organization? (more important for smaller organizations) 7) Cost of ownership - Includes things like: cost of rebuild? Do I have to maintain an additional developer skillset? Do I have to maintain additional hardware/OS/Web stack? Do I have to maintain an additional hardware/OS/Web skillset? (the actual build and new hardware costs are often less significant than ongoing maintenance of the required people resources) 8) ... yes, I'm sure there are other items I missed ... SUMMARY: Often, (and likely in this case) looking at these larger picture items, the answer is "It doesn't matter", assuming the languages being compared are mature, robust, and purvasive, which they are in this case.
-
Can you debug typescript as typescript yet, or are you stuck trying to figure out how to map the fugly javascript that it was transpiled to back to your original code?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
You absolutely can.
Idaho Edokpayi