Why should I learn Node instead? Does writing backend Javascript mean you're a better developer?
And a lot of the “magic” in the .Net server technologies mean that when things go wrong, there’s almost nothing you can do other than raise a ticket with MS, but you end up spending a lot of time and energy trying to figure out what might be wrong before going that route.
Fortunately, both of these issues have been resolved with the open source .Net Core, and while we continue to use .Net Framework, I’m looking forward to doing more .Net Core development going forward.
TBH there are very few IDEs or environments that match Visual Studio. If you've never used it, of course you'll be less productive.
>A lot of configurations need to be done through VS and lead to the creation of config files that cannot be edited or read outside of VS.
Project and solution files have been XML for a long while. I think the example here would be early UI work with WinForms and WPF? But everyone would think you're crazy to edit those text-only when you had a WYSIWYG editor.
>And a lot of the “magic” in the .Net server technologies mean that when things go wrong, there’s almost nothing you can do other than raise a ticket with MS
>Fortunately, both of these issues have been resolved with the open source .Net Core
If there's an issue with Kestrel, I think you'll still be spending a long amount of time debugging that. I don't think much has changed on that front.
.NET Core isn't a magic solution to this.
Truth is, for a long time already, C# has been a decent boring cross-platform language. The only reason people refused to use it was hype and stigma. There was no deep rational reason.
Sure, mono was slower than .net-on-windows at the time (.net core fixed this), but it was still way faster than the then-default Rails setup.
Whenever I told people about our setup at eg tech events they got very confused. Some dismissed me as a moron but to be honest most people were just surprised you could run a cross platform C# devteam and deploy to Linux. People simply didn't seem to know this was possible. That's been some pretty bad marketing in Microsoft's part.
Node is a gateway to Javascript fluency for people that get a headache dealing with the DOM in the browser. You can write command-line scripts, run them with "node [scriptname]", and learn.
Having done that, I've found that Node is great for fast prototyping of servers, even if those are going to be written in C/C++ ultimately. In not-super-formal work environment, you can very quickly write something that runs with the correct behavior, and treat that as the spec for the final performant code.
Honestly, to me Node always sounded like the exact opposite of your description: a way for frontend development experience to leak into the backend at least in appearance so that people who were able to hack around DOM updates could argue that they could develop for the backend as well, thus paving the way to pad resumes with "full stack" experience.
I think companies underappreciate this.
If your current tech team is focused on (insert any specific language / framework), then why are they going to like and hire anyone with different experience?
Your telling me how you can do it in 3 lines of (new language) makes me feel pretty bad about my 1000 lines of Java.
> Your telling me how you can do it in 3 lines of (new language) makes me feel pretty bad about my 1000 lines of Java.
Blub languages aside, a candidate focusing on how they do things in $LANGUAGE_WE_DONT_USE_HERE means they're going to have to get their feet under them to read our existing code fluently, to write code in our style, and to get all of the other language- and tooling-specific institutional knowledge existing programmers here have.
Short term vs long term optimization. Neither strictly better.
[1]: https://trends.google.com/trends/explore?date=all&geo=US&q=%...
Honest question: does Node offer any advantage other than CV points wrt established backend tech stacks?
Lua JIT however is sane, simple and even faster, but the infrastructure and tools surrounding it are bare in comparison.
Huh? Async code is so powerful. You can use promises instead of callbacks. And you can easily make a async call "synchronous" by adding the await keyword in front of it.
If you get some better tooling for multi-language development, it will usually pay off a lot faster than choosing Node for your backend will.
That way lies surrender by default to the Google empire.
These days my main strategy is to have three TypeScript projects—frontend, backend, and common. I then whitelist imports in the common libraries.
> It's the same language, using the same JavaScript engine (v8 for chrome).
I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later.
New features will have varying support between implementations in any language. You have to take these differences into account even if you're writing frontend-only code.
> I find it completely unacceptable to assume that V8 is running in the browser. In general, I do all of my JS development work in Firefox or Safari, and this saves me a bunch of time checking portability later.
The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS.
For frontend, you use transpilers or polyfills to smooth over the differences between browsers. You then package these up, with rollup or webpack or whatever, and deliver to the client.
My experience is that once you add backend to your list of supported targets, you have to get quite a bit of new tooling in place. Backend code is generally not packaged before running, imports are done at runtime rather than build time, etc. There’s a whole pipeline between your source code and the JavaScript engine, and that pipeline has a different shape for backend and frontend, and typically uses completely different libraries to make it work.
> The point is it can be the same javascript engine for frontend and backend. The difference between Node JS and Firefox JS is the same as between Chrome JS and Firefox JS.
I don’t know what kind of point that is, because it doesn’t matter to me that sometimes the frontend and backend will happen to run on the same engine. I haven’t figured out a way to leverage that fact to give me any additional productivity.
For the projects I’ve worked on, it can end up taking me quite a bit of time figuring out how to make one piece of code work in both frontend and backend, even though I can trivially make it work in either environment as I please.
Maybe other people have already solved this, but I recently went through and made a bunch of PRs to fix a common issue I saw in other people’s codebases and it was super rare to see any code shared between frontend and backend.
You still have to identify which polyfills you need, add them in, test them, etc. Polyfills are also quite buggy especially for new features from my experience. Also, the fact that you're typically running your build, packaging, linting, testing etc. on Node for your frontend code, says a lot.
> My experience is that once you add backend to your list of supported targets, you have to get quite a bit of new tooling in place.
When is that really even a consideration though? When do you actually need to deploy your frontend app to Node? If you have common model code, or say, input validation/sanitation, business logic, etc - that can easily be identical for both browser and Node.
> Backend code is generally not packaged before running, imports are done at runtime rather than build time, etc.
That really depends on your setup. You can do imports at runtime or build time for both Node and browser. If you're transpiling the setup is pretty much identical.
> I don’t know what kind of point that is, because it doesn’t matter to me that sometimes the frontend and backend will happen to run on the same engine.
How do you run your unit tests, your static code analysis, your packaging and traspiling? Do you run it in the browser or in Node? There is no fundamental difference between JS of the same version in Node vs Browser. Any browser specific or Node specific libraries/features you use are generally not part of any stable JS spec.
> it was super rare to see any code shared between frontend and backend.
Well I'm assuming these are different applications, so that's expected. I don't know why you wouldn't share your model definitions and/or validation/sanitation code though. People do this even for backends/frontends written in different languages.
You just have to keep an eye on your client bundle size if these shares functions ref something like underscore, moment or something like that where you’re pulling in the entire thing for one function. I’m aware you can just pick pieces with {} and import, but not everyone is aware and often require the entire thing.
It only works if the paradigms your app uses are the same in the front and back. And I have nott seen a project where the KIND of problems that need solving (in the front vs back) were close enough for the same language to be a benefit.
I mean at the end of the day, I can build a house with JUST a screwdriver, but man, I'd rather use the right tool fot the specific job.
And at the end of the day, $LANG is a tool.
Ive not worked with c# much, but is that not as much of a problem with it? Like, is there more of a standardized way of doing things? Python is kinda like that i guess.
Some subset of that can be achieved with stuff like GraphQL or Swagger and what not though I haven’t given it a serious try since we’ve never run into hiccups yet with this system, reliant on a very simple library.
We also use the same package manager (NPM) on both ends and can therefore invoke scripts all over our codebase with the same syntax; and although react code and node code is quite different in structure, they all have the same idioms and async syntax and stuff, so the amount of retraining necessary to convert someone from backend to full stack isn’t very large due to the same environment, and keeping code style consistent across the project is also easy.
So I feel like there’s definitely stuff to profit off of with sharing a single language.
The Node API unfortunately is built around callbacks, but can be turned into a Promise-based API using the built-in "promisify" tool: https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...
Absolutely not. But as someone who does write backend Javascript I don't tolerate Microsoft development tooling because I don't tolerate Microsoft. Period.
When their core product offering is literally adware/spyware (Windows 10) to the point I have to use special builds that are difficult/expensive to get a hold of (LTSB/LTSC) I get pretty turned off in regards to the whole ecosystem.
Microsoft tooling may be right for you, but it is not for me... and Node is an outstanding tool for rapid application development with solid async capability that's open source.
I can also find/hire way ECMA devs way easier vs C#.
Also before someone rips me saying "well Visual Studio is better than everything else" - Intellij offers the same general "nice-to-haves" and doesn't come with a dependency on a broken OS.