Hacker News Reader

Comment by ben_pr | Hacker News Reader

I see that JavaScript has it's place in the browser but the whole back-end thing scares me. The ugly code (callbacks, etc), npm injecting only God knows what into your back-end servers, tons of work-arounds for trying to make JS not so ugly, are over the top.

The JS everywhere is so much like the "only tool you have is a hammer, so every problem looks like a nail" thing, it's amazing.

Creating a simple, secure, extensible middle-tier is a solved problem and is not in need of JS trying to solve it in a much more obtuse way. I've created many myself in everything from Delphi, PHP, C#, Groovy, to Java and I would never pick JS for that layer.

And a final thought, PHP used to get tons of bad press for being messy, etc, etc. But this JS stuff takes that mess to a whole new level. Perhaps PHP devs moved to node/js so they could make a mess and everyone would still think they are the cool kids?

View on HN

I'd probably still prefer .Net, but ES6 and TypeScript have made nodejs pretty bearable for me. I'd prefer it to and maybe even argue it's a better platform for concurrency than Python at this point, even 3.5, for most situations.

The concurrency you get with async/await is nice enough and performant enough over 0 concurrency to make it pretty good. You don't get thread pools and it's not the fastest at single threaded processing.. And there is only one number representation which is a hassle forcing the use of BigNum occasionally.. The stdlib is a mix of callback and events and requires wrapping for good async/await consumptions and.. Well there are a lot of drawbacks.

C# on CLR is superior IMHO as a platform and language in nearly every way except... It's not JS. If you are moving around between a ton of stuff constantly you'll end up doing a lot of JS(and in my case TypeScript because I've successfully introduced it multiple times) due to frontend work and the employee common denominator.

Edit: This is a bit of a ramble. I don't think NodeJS is the best thing going. But while I personally would prefer C#, Go(depending on project), F#, potentially clojure, and etc after removing personal preference and adding in all the other factors that come in to play when selecting a technology that a team has to use and support -> nodejs/TypeScript is often a pretty good option.

> es6 and TypeScript have made nodejs pretty bearable for me

I'm glad you found a solution, but I think the fact that you need typescript to make javascript bearable is an issue. Typescript isn't javascript, so the implication is that what we get out of the box is not bearable, and we then have competing languages, tooling, workflows, etc. and no "right way" to do things. Just more fragmentation, and an unbearable default.

Javascript on the backend is HORRIBLE. From a dev UX perspective it's a terrible cluster of random errors, and strange workarounds.

One time a project I was working on wouldn't run with some random ass error from some random ass node module. Try try try, not working. Spent 2 hours trying to find an answer online. For the hell of it I tried again and this time it ran with NO code changes.

That's the day Javascript as a backend language died for me. It's a house of cards stuck together with chinese knockoff glue.

Everytime I try to get excited about Javascript on the server and built anything of substance, every damned module's example code is nothing but a bunch of console.logs. There's must be some magical framework I'm missing where that's a way to build apps. (Console Dot Logs on Fails?)

Except something did change, and it wasn't JS's fault. If it wasn't the code, it was the environment (time, variables, FS, system resources, etc.).

https://youtu.be/bzkRVzciAZg

If you have NPM on the server, uninstall it asap! Running NPM on the server is very dangerous! Use rsync from development/staging instead. Personally I avoid bloated modules, and keep everything in SCM. NPM (the archive) is a superb service, but you should not depend on it.

Full stack polyglot here. I have no idea how you justify anything you just said with facts. It sounds a lot more like you didn't learn the language or are repeating something you read of the internet.

You don't need many callbacks in the backend. Use await / async or promises for most problems instead of callbacks. Of course, callbacks are a fine tool when suitable.

I don't know what "work-arounds" you're talking about.

Reply on news.ycombinator.com