Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After a year of using Node.js in production

geekforbrains.com

Post reply on HN
Print view View original

171–180 of 248 posts

Re: After a year of using Node.js in production

#171

Post by ldehaan »

From reading the comments there are Still a lot of misconceptions about Js.

javascript is not new, it's been around since before most of the web devs out there started working in computers.

nodejs supports multiple CPUs.

nodejs is stable.

JavaScript is retarded fast, and it's not c or c++ or any Compiled language, and shouldn't be compared to them because that's unhelpful as a measure.

it is the only language for the web which enables you to work in the same language on both fronts.

frameworks aren't JavaScript.

nodejs isn't JavaScript.

JavaScript is so flexible that it can be changed to suit the needs of those writing it, so much so that you get whole new dsl's like typescript.

there are more conversations on the internet about JavaScript than any other language being used today.

oh and nothing scales if you don't know how to write scalable software, that's on you, not the language.

Re: After a year of using Node.js in production

#172

Post by majewsky »

spion wrote: post #97
beders wrote: post #55

Now all of a sudden, having types and some standards to gather around doesn't sound like a bad idea anymore ;) I agree with one of the commenters: Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again. The software industry is in a sorry state. Unless you are a very disciplined team with a very strong sense of writing modular code, d…

The main problem with most typed languages is basically that types are nominal by default. What I want is free-form records and structural types by default, nominal types only when necessary. I get more than half of that with TypeScript (it does lack nominal types but there are ways to get around that), and honestly its the half I prefer having.

Most serious statically-typed languages have some sort of "anything" type where you can check the actual value type at runtime using some sort of reflection. For example, the direct Golang equivalent of a Javascript object is a map[string]interface{}.

Re: After a year of using Node.js in production

#173

Post by Kequc »

MichaelGG wrote: post #159
Kequc wrote: post #155

Earlier quoted context omitted.

I'm still not all the way on board with promises - from the sounds of it this article says there is already a successor down the pipe. As you've pointed out some of these libraries make things behave a lot more similarly to other languages. And in such a case you may be better off just using one of them. However you're giving up on a lot of the power and benefits javascript provides, so of course you'd want to use so…

How is JavaScript so special with async and streams? JS lacks any syntax for async, so it's not on par with languages that do. What's special there? Same for streams: they're implementable in any language, and JS has no special capability there. Or am I unaware of something JS has that other languages lack (besides popularity)?

When javascript performs an asynchronous operation it doesn't block the thread. It stacks everything on a queue and then just works through everything as fast as possible. Any other language would require a separate thread for each operation.

I'm sure there's one other language out there that does it too but I don't know what it is.

Event based programming effectively means that as long as it has something to do it's doing it. You tell it to wait? It says great I've got all this other stuff to do.

Streams you may have me there, I didn't realise those were so widely used in other languages. Javascript works pretty well because you can run it on the whole stack. Share code between the front and back end. Stream from one place to another and around the corner.

Re: After a year of using Node.js in production

#174

Post by Tarks »

spion wrote: post #91
popmystack wrote: post #85

Earlier quoted context omitted.

Or what if, hear me out, everyone just did that thing from the start?

I do tend to start all my new node projects in TypeScript, yes.

With TS do I have to have a spec for every third party code or can I import something and use it as-is, but not get the benefits of TS on that part of the code?

Re: After a year of using Node.js in production

#175

Post by esailija »

snappy173 wrote: post #26
eldude wrote: post #4

I train enterprise node.js for a living. My recommendation is to just use songbird (which exposes the forthcoming promise API from core, built on bluebird), async/await and the async `trycatch` library so you don't have to worry about a 3rd party package's choice of asynchrony. It also comes with optional long stack traces.

>async/await in my experience, async/await is a great way to layer indirection and obfuscation over what is still callback hell. it may look better in the editor, but it's hell to debug.

async/await is tiny amount of sugar over generators and promises (virtually the only thing that changes is `yield` -> `await` and `function*` -> `async function`), not callbacks.

Re: After a year of using Node.js in production

#176

Post by q3k »

snappy173 wrote: post #21
deedubaya wrote: post #19

For all the comments on here about how unfair the author was, there sure is minimal feedback on the problems they highlighted.

the feedback is: stop expecting javascript to act like python

What does that even mean? What behaviors are you talking about?

Re: After a year of using Node.js in production

#177

Post by pathsjs »

Kequc wrote: post #173
MichaelGG wrote: post #159

Earlier quoted context omitted.

How is JavaScript so special with async and streams? JS lacks any syntax for async, so it's not on par with languages that do. What's special there? Same for streams: they're implementable in any language, and JS has no special capability there. Or am I unaware of something JS has that other languages lack (besides popularity)?

When javascript performs an asynchronous operation it doesn't block the thread. It stacks everything on a queue and then just works through everything as fast as possible. Any other language would require a separate thread for each operation. I'm sure there's one other language out there that does it too but I don't know what it is. Event based programming effectively means that as long as it has something to do it's…

Python, Scala, OCaml, Nim, Haskell and more all have asynchronous operations for I/O - it's not something that is a JS only thing

Re: After a year of using Node.js in production

#178

Post by rimantas »

eagsalazar2 wrote: post #151
Corrado wrote: post #147

I agree with this article and find the Node.js community, and to a lesser extent Javascript itself, exhausting. It seems like every 2 minutes there is a "more" proper way to do something, which tells me that the architecture is not yet mature, even though it's pretty old by now. On a related note, it seems like every time you find something that doesn't quite work correctly or conveniently in Node.js there is a "fix"…

Yes, the Javascript world is quickly evolving both on the front end and backend, and of course that can be exhausting but I have to disagree with both conclusions that (a) this means the tech is immature, and (b) the community's readiness to make changes is "holding it back". The js world is very unique in its ability to evolve quickly and things have improved massively over the last few years. Now, apart from the ch…

The problem I see that in this case "evolving" looks suspiciously like running in circles without going anywhere.

Re: After a year of using Node.js in production

#179

Post by flamethroeaway »

jondubois wrote: post #137

- The dependency instability can be avoided by specifying specific versions of your dependencies inside your package.json. - The fact that the ecosystem is evolving quickly is a good thing. Node.js is still one of the fastest growing software development platforms according to Google trends so you should expect it to change faster than other ecosystems. - ORMs suck (in every language) - They always sucked; ORMs are a…

Is package.json webscale?
Post reply on HN