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 CallsWhat's their reason for switching to Node? Node is JavaScript, which is awful, and TypeScript just makes it look more like C# :laugh: It kind of depends on your environment though. Personally, I'm using Microsoft all the way down, so switching out anything would make it harder to integrate with everything else. For example, if you're using Jenkins instead of Azure DevOps, C# integration is a lot harder to begin with and switching to JavaScript may make certain tasks easier. One reason I'd use Node over .NET Core is to re-use code between a back-end and a front-end (website). This is actually a scenario that came up recently for a web app we wanted to do with instant front-end calculations that we also had to do back-end for an initial generation for the data. Node would probably also be a better fit if your data is unstructured (with a MongoDB database, for example). Using Node could be a hiring decision if you can get plenty of JavaScript developers (because everyone knows JS), but no C# developers. Other than that I have no reason to use Node instead of .NET Core, they're both multi-platform and lightning fast. It even seems .NET Core is sometimes even faster than Node! Node invites the horror that is npm with 10.000+ files in 40 MB for a single package into your back-end X| However, why not use microservices and use both where they best fit? ;)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
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 -
I love TypeScript. As a language, it has so much going for it but, and this is a massive but, if I were rewriting a .NET app now, I would go with .NET Core all the way. The new hosting model is faster than Node's; it runs on just about every platform you could possibly want and the new features such as Span means that it can work with much lower code overhead.
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, 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 CallsOur current ASP.Net WebForms code base requires asmx files so we can communicate with our DAL from javascript. Our new MVC5 code base is all C#, and we're moving as far away from using javascript (in any of its evil forms) as we can. We also implemented a new DAL that is more generic than the existing one. We're not using any ORM beyond the EF stuff that comes with your typical MVC project template. To be honest, we'd REALLY like to get rid of EF altogether, but we don't really have time to work on that aspect of the code. It's hard to decide which I hate more - javascript, or EF.
".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 CallsFrom an architecture and design standpoint, I'd first look at the team and their core skills. The platform I chose would heavily depend on what my developers were used to coding, and could be productive in. That's one of the primary considerations of any platform or stack, assuming they meet functional requirements. So if it were me, again, I'd start there. From there, most of the rest is dev fodder, that really people will tend to holy roll over. What's important at the end of the day, is can it meet the requirements necessary to build your app? And so if it were me, I'd go back to the design phase, mock up some overall system diagrams, and flow, maybe come up with a preliminary SBD, and then match it against the various offerings. Whichever comes up strongest in helping the app fulfill it's behavioral requirements is what I'd go with, in the context of the given team's skillset
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I love TypeScript. As a language, it has so much going for it but, and this is a massive but, if I were rewriting a .NET app now, I would go with .NET Core all the way. The new hosting model is faster than Node's; it runs on just about every platform you could possibly want and the new features such as Span means that it can work with much lower code overhead.
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
-
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've been able to debug TypeScript as TypeScript for a long time now.
-
You've been able to debug TypeScript as TypeScript for a long time now.
cool, does it work in all browsers or need helper plugins? Not being able to do so was the biggest downfall of the project using coffeescript I was on some years back; and when I asked about typescript a few times before I never got an answer.
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
-
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 CallsI would do a lot more who/what/why discovery before choosing either - why are we rewriting, why do we need to do the whole thing, what skill sets do we have, what is our hosting story, what is the budget etc.
-
cool, does it work in all browsers or need helper plugins? Not being able to do so was the biggest downfall of the project using coffeescript I was on some years back; and when I asked about typescript a few times before I never got an answer.
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
Dan Neely wrote:
cool, does it work in all browsers or need helper plugins?
No plugins required. I'm able to debug TypeScript in VS without problems. VSC - now there I had problems with setting up breakpoints.
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls -
I love TypeScript. As a language, it has so much going for it but, and this is a massive but, if I were rewriting a .NET app now, I would go with .NET Core all the way. The new hosting model is faster than Node's; it runs on just about every platform you could possibly want and the new features such as Span means that it can work with much lower code overhead.
Pete O'Hanlon wrote:
and the new features such as Span<t> means that it can work with much lower code overhead.
Care to elaborate on that a bit? As in, I can understand memory overhead, so I'm curious how it can affect code overhead?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls -
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:
Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
I would oppose a rewrite even. You can replace parts of it, but you don't abandon the applications that make money.
Marc Clifton wrote:
So what's you're take? Why would you use one vs. the other for back-end development?
If developing for a Rich UI, I will want to provide a Rich UI - not a simplistic website, but a UI that supports Windows color scheme's, resizing of panels, resizing of columns, and would always use the Common Controls (nearly unchanged still, since Win3). Installed this "Slack" desktop application, and it is unintuitive and bloody ugly, does not support high-contrast color schemes, and is an insult to development in general.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Pete O'Hanlon wrote:
and the new features such as Span<t> means that it can work with much lower code overhead.
Care to elaborate on that a bit? As in, I can understand memory overhead, so I'm curious how it can affect code overhead?
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsI was loose with my terminology here. It should, of course, be memory overhead.
-
Our current ASP.Net WebForms code base requires asmx files so we can communicate with our DAL from javascript. Our new MVC5 code base is all C#, and we're moving as far away from using javascript (in any of its evil forms) as we can. We also implemented a new DAL that is more generic than the existing one. We're not using any ORM beyond the EF stuff that comes with your typical MVC project template. To be honest, we'd REALLY like to get rid of EF altogether, but we don't really have time to work on that aspect of the code. It's hard to decide which I hate more - javascript, or EF.
".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, 2013Our MVC5 talks to a webservice backend (also c# that runs a repo pattern with dapper as the persistence handler). It's lightning fast and pretty easy to implement. Once you have a webservice/micro service layer, your frontends are really whatever makes your project easier for quicker ROI. I've never used node but I'm wondering why one would use a javascript library for server side implementation?
-
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 CallsI would use F# :-)
Check out my blog at http://msdev.pro/
-
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 CallsYou should never switch tech because it's old, although we always like new and shiny things. If it works you should maintain it (I have 16 year old code in production). The reason to use (continue) .net : - control over the environment (in house deployment) - existing competence in the technology - better IDE and dev tools Reasons to switch to something else: - not in house and in the cloud - environment running costs at scale (generally .net more expensive)
Exception up = new Exception("Something is really wrong."); throw up;
-
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 CallsC# has a low learning curve and the language, debugger and IDE's are all mature. And that's not mentioning the security patches the web stack gets every few weeks. Honestly, if my team would suggest to scrap a C# back-end in favor of using node.js and typescript, I'd either resign or ask for resignations. I wouldn't want to work with people like that, especially not with WASM and .NET Core creeping into the web-stack, threathening the future of javascript back-end frameworks. That's basically expecting you to learn skills for the next 5 years, that might be obsolete in the same timeframe. Madness. Pure madness.
-
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 CallsIt doesn't look like it is the right time to switch from .NET to anything else at the moment: - .NET Core - WebAssembly - How can the Node ecosystem stand in comparison to the .NET ecosystem, in terms of available libraries, classes, object model, tools, etc.
-
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 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.
