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

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

Post reply on HN
Print view View original

101–110 of 365 posts

Re: Hard-won lessons: Five years with Node.js

#101

Post by danneu »

laser wrote: post #83
danneu wrote: post #81

Earlier quoted context omitted.

My reasoning: all of the dynamically-typed languages are more or less the same on the server for CRUD apps, so I might as well use Javascript.

Hmmm, that hasn't been my experience: http://www.phoenixframework.org/

I haven't used it, but it's still the same pseudocode:

    defmodule HelloPhoenix.UserController do
      def index(conn, _params) do
        users = HelloPhoenix.Repo.all(HelloPhoenixUser)
        render conn, "index.json", users: users
      end
    end
For CRUD, I'm not too convinced it's much different than what you'd be doing anywhere else.

For websockets, streaming, and other stuff beyond request -> database query -> response, then competing abstractions get more interesting.

Re: Hard-won lessons: Five years with Node.js

#102

Post by Rapzid »

pyrophane wrote: post #51
koolba wrote: post #28

Earlier quoted context omitted.

Typescript plus async/await is a beautiful solution to both the async story and typing story.

The problem I experienced with async/await and Typescript was always the lack of built-in support for promises among the libraries I was using. Once I had to use something like promisifyAll() I lost any type information I had about the library in question. Is there any better workaround to that these days?

This is changing pretty steadily. For example, the AWS SDK has TypeScript types packaged now and a promise interface. Compare this the boto3, the Python SDK, which has had a story open for years(?) to add async support with no official solution.

Node.js's own libraries are a mix of events and callbacks. Some of it can been "promisified", however they have yet to start a real async conversion AFAIK. I've had to wrap some of this stuff to create async interfaces for my own code.

Re: Hard-won lessons: Five years with Node.js

#103

Post by ReverseCold »

lasfter wrote: post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

In one word: npm

In one sentence: You can build anything with NPM + copy paste in very little time.

Re: Hard-won lessons: Five years with Node.js

#104

Post by chickenfries »

hota_mazi wrote: post #60
badminton1 wrote: post #34

Earlier quoted context omitted.

JavaScript is a scripting language. So is Python and Ruby. As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. Now, in terms of bindings, bindings to libuv are also fast. So node is not so much of a problem in itself. However the problem is how the language is being used: To say you can write a serious library or server code because you kno…

> As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. This makes no sense. They're all dynamically typed languages (avoiding the term "scripting languages" since it's pretty vague). The only reason for the difference in speeds between these languages is due to the quality of their interpreters, not the languages themselves.

I'm not a PL expert, but Ruby's semantics seem much more complicated than JavaScript's.

Re: Hard-won lessons: Five years with Node.js

#105

Post by fulafel »

danneu wrote: post #81
lasfter wrote: post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

My reasoning: all of the dynamically-typed languages are more or less the same on the server for CRUD apps, so I might as well use Javascript.

I find there are really big differences between the dev experience in Python, Node, Clojure and Erlang. JS doesn't trap errors[1], so it's tedious to debug or to have confidence in correctness, and the callback hell APIs are high friction in interactive/REPL development. Node is a fine vessel for running ClojureScript though ;)

[1] See eg the bit about NaNs in the article.

Re: Hard-won lessons: Five years with Node.js

#106

Post by sjg007 »

lasfter wrote: post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

I mean, you only need one language for front end and back end now, so that can be seen as a win! However, I for one prefer strongly typed languages as much as possible.

Re: Hard-won lessons: Five years with Node.js

#107

Post by iopq »

Safety1stClyde wrote: post #90
iopq wrote: post #86

Earlier quoted context omitted.

For example, Rust distinguishes between PartialEq and Eq https://is.gd/kRvoMm you can't derive Eq (transitive equality) on f64 https://is.gd/FjTcA5 but you can derive PartialEq (intransitive equality)

Unfortunately I do not yet know very much about Rust, but I wasn't referring to the specifics, but to the point that every programming language seems to have quirks and hidden rules.

So just use a programming language with less annoying quirks and hidden rules. Especially when those quirks are issues at compile time, not issues at 3 AM in production.

"And I found a whole lot of references to req.randomThing and even some req.randomFunction() calls. I then proceeded to search back through every single middleware function which had run before, to figure out what exactly was going on."

In a statically typed languages names are bound at compile time, so you can actually jump to the definition of each name using tooling. A JS tool can only make an educated guess.

Re: Hard-won lessons: Five years with Node.js

#108

Post by Ataraxic »

technion wrote: post #88
manyxcxi wrote: post #35

Earlier quoted context omitted.

I've got over a decade of professional experience in C#, Python, and Java. I'd consider myself a Java developer before all else, yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Here's the major caveat, out of, say 100+ PoC/prototype projects I've ever done, I've taken two to 'production'. I put production in quotes because they were actually internal ser…

I've had several experiences with Node.js contractors handing over "finished" applications that were only configured to run under webpack-dev-server[0] It clearly tells you in the README it's not for production, but I have this recurrent discussion with developers who tell me they have only ever run Node.js this way. What that tells me is there is quite a trend a towards exactly what you describe, where a lot of what…

Webpack dev server simply serves up compiled assets for convenience, because it serves new assets as they are compiled and blocks when compiling. It should be fairly trivial to serve up static production assets as needed. I say this as a person who just converted a production rails app to use webpack as first class citizen.

Re: Hard-won lessons: Five years with Node.js

#109

Post by ars »

hota_mazi wrote: post #94
mattnewton wrote: post #76

Earlier quoted context omitted.

The edit/refresh cycle starts to slow as the project grows in Java, but node has pretty close to zero startup time and is interpreted. That plus a repl supports a much more explorative coding style where things work as fast as you can add them. No JVM restarts, compilations, or going back to change types or api's in the middle of a thought.

> The edit/refresh cycle starts to slow IDEA and Eclipse compile your code as you write it. And with Hotswap, you don't even need to redeploy anything. They also all offer REPL's that are much more sophisticated than anything Javascript has to offer. I think you haven't used a JVM language and its ecosystem in a very long time.

> And with Hotswap, you don't even need to redeploy anything.

Except when you have to restart the JVM because you added a class or a whole bunch of other things that it can't hotswap in the new code.

Re: Hard-won lessons: Five years with Node.js

#110

Post by dragonwriter »

ralusek wrote: post #75
lasfter wrote: post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

NodeJS has a handful of things that tend to get brought up. Callback soup and difficult error handling. Both are resolved by promises. Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. On top of that, NodeJS is very, very fast. Compared to Python or Ruby, straight computing is significantly faster, bu…

> Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language.

Of the top of my head, concurrent asynchronous tasks are simpler in Pony, Go, Erlang, Elixir, Haskell, and Oz than in JS (and these generally also handle parallelism beyond "run another instance of your app", too); and lots of other languages have concurrency constructs equivalent to JS promises (and, often, also async/await), so JS is at best no easier than that larger group.

Post reply on HN