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

61–70 of 365 posts

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

#61

Post by oddlyaromatic »

ohstopitu wrote: post #37
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've used nodeJS at 3 of the past 4 startups I've worked at (currently using PHP). I had a hand in choosing it at all those 3 places and my main reasons boiled down to: 1. most devs know JS (so it's easier to hire & onboard new devs) 2. while everyone claims node's dependencies are hell, I love the choice available (although over time, it's tiring). 3. The community is generally awesome (helps during meetings, online…

I'm pretty much a beginner developer, doing a few small things but not employed as a dev. I like JavaScript, and when I wanted to do server side stuff (like automate schedule emails at my company), solutions were really available in PHP and it worked right away on my local machine with mamp and on my super cheap web hosting, whereas I seem to hit various setup pains when I try to do something with node. The PHP syntax was close enough for me to be much more comfortable than I expected to be. I recently worked on something that logs a user in to a mobile-unfriendly website, scrapes and parses a specific page that you would want to see on mobile, and presents a nice mobile view, with some extra relevant information. All the scraping is done in PHP and it just returns json that gets displayed with a handlebars template. It's just a demo right now, but my point is that even knowing a bit about JS, PHP feels so much more accessible than node for me, and I've done stuff that a year ago I never would have thought I could do. I feel like solutions are close and only require language and library research. Node solutions also require this other layer of knowledge that I haven't clicked with. How is PHP treating you at your current job?

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

#62

Post by pyrophane »

koolba wrote: post #55
pyrophane wrote: post #51

Earlier quoted context omitted.

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?

Not really but I also don't see it as that much of a problem. The libraries I use either provide a Promise based interface or I've written my own as a thin veneer atop a callback interface. Ditto for apply your own types atop the results. Most are already there and only a few edge cases need to be added.

I had a somewhat different experience. Most of the libraries I used lacked types in the library itself. There were types provided by DefinitelyTyped, but they were often incomplete or out of date, and I think a wrong type definition can be worse than none at all.

As far as writing your own types on top of those libraries, how do you ensure any amount of correctness?

Am I missing something important here?

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

#63

Post by [deleted] »

koolba wrote: post #55
pyrophane wrote: post #51

Earlier quoted context omitted.

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?

Not really but I also don't see it as that much of a problem. The libraries I use either provide a Promise based interface or I've written my own as a thin veneer atop a callback interface. Ditto for apply your own types atop the results. Most are already there and only a few edge cases need to be added.

[deleted]

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

#64

Post by shados »

ninkendo wrote: post #53
thesmallestcat wrote: post #30

Earlier quoted context omitted.

Or one could learn how `this` works, which is that example is really talking about. I was unimpressed by these lessons. There are no dark corners of Node, or JS in general, here. It's more of a narration of the author's growth as an engineer. The "call the callback last" recommendation is particularly odd.

The counterintuitive behavior of "this" in JavaScript doesn't need any defending. I've never heard a justification for this or any other of JavaScript's quirks that wasn't just a thinly veiled lecture on how it works.

if nothing else, the javascript "this" is teaching people alternatives to coding that don't need it in the first place.

(I don't think JS "this" is that bad...it's just not needed at all)

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

#65

Post by bradmwalker »

jack9 wrote: post #19

> Verify All Assumptions When you have to worry about the environment unexpectedly reusing internal variables, when is it considered foolish to use a framework where you have to question every relationship between every concept? Just stop using it.

https://www.youtube.com/watch?v=D5xh0ZIEUOE

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

#66

Post by bbcbasic »

ninkendo wrote: post #53
thesmallestcat wrote: post #30

Earlier quoted context omitted.

Or one could learn how `this` works, which is that example is really talking about. I was unimpressed by these lessons. There are no dark corners of Node, or JS in general, here. It's more of a narration of the author's growth as an engineer. The "call the callback last" recommendation is particularly odd.

The counterintuitive behavior of "this" in JavaScript doesn't need any defending. I've never heard a justification for this or any other of JavaScript's quirks that wasn't just a thinly veiled lecture on how it works.

They should name it arg0, as that is more indicative of what it is than "this".

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

#67

Post by eel »

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?

At a previous gig, without getting into specifics, we built a huge internal client-server system. The client was written in Node.js and ran as services on both Windows and Linux on a few thousand machines. The server was written in Node.js and ran as a Linux daemon.

Node.js matched the developers' skill sets and gave us the ability to quickly write a server that could easily handle several thousand concurrent requests from the clients. On the client-side, Node.js gave us cross-platform support for nearly free (as well as being within our skill sets).

Looking back, I do not think the project would have gotten off the ground in any other platform in that specific organizational environment. The server on Linux was particularly well-suited as it was architected to scale horizontally but still had room to scale vertically.

On the client side, while we were able to get the Node.js service out pretty quickly, it eventually had performance and integration issues, particularly on Windows. It was super frustrating having to shell out to external processes or write native C++ modules to get access to some needed Windows APIs. In hindsight, I would have tried to rewrite the Windows client sooner in C++ or C#. On the plus side, it was a huge advantage that the entire Node runtime fit in a single executable (no dependencies on a huge JRE or other runtime).

Overall, I would recommend it as an option to consider if most of the following is true:

* Need to get to market quickly * Application is I/O intensive rather than CPU intensive * Dev team already knows JavaScript * Target environment is not Windows

Personally, I decided to move away from Node.js and these days if I was faced with the same problem I would lean toward a JVM language or Elixir.

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

#68

Post by goatlover »

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.

Yeah, since PyPy is V8 fast, LuaJit is faster, and Julia is even faster.

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

#69

Post by shados »

koolba wrote: post #28
lasfter wrote: post #27

Earlier quoted context omitted.

I actually have, but it doesn't alleviate my biggest issue with Javascript, which is its async story. Also I've had experiences with Typescript code compiling with an error then immediately recompiling without any errors. Then errors when I switch to my browser. The immediate recompilation is probably just webpack but it doesn't inspire confidence when errors are non-deterministic.

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

async/await is still based on promises, and promises are a naive/simplistic answer to the problem.

It works fine for simple cases, but those are cases that were simple to begin with (Ok, maybe they would not be fine with CPS, but async/await is just thin sugar over promises).

To really solve the async problem, you need either Observables or monadic constructs. The former is much more mainstream and mature in the JS world right now. It's not as cute as async/await and you'll be typing more functions, but it really solves the problem altogether.

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

#70

Post by pyrophane »

hota_mazi wrote: post #57
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…

> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Why? Writing Java is really very fast these days, especially with IDE's. I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.

I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.
Post reply on HN