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

131–140 of 248 posts

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

#131

Post by paulddraper »

kansface wrote: post #119
uptownJimmy wrote: post #103

Earlier quoted context omitted.

Speaking only for myself, a middle-weight .NET dev who was, not too long ago, working desperately to find my footing in all this: 1. I think the learning curve to doing good work with Node is really shallow at first, and then it quickly gets almost vertical. 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a…

> 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Mov…

Yeah, but is that really necessary? GitHub runs Rails and they have load.

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

#132

Post by Silhouette »

spion wrote: post #120
Silhouette wrote: post #29

Earlier quoted context omitted.

You should try to surround yourself with developers who don't have such attitudes. The trouble is that while you can do this for yourself to some extent, you can't necessarily do it for the people you have to work with. I've worked on a project where one guy came in to do a simple database back-end for an embedded system and decided Node and its ecosystem were appropriate. He seemed to have some experience with those…

Sounds like this has absolutely nothing to do with the technologies and everything to do with the developers.

Yes and no.

The difficulty of getting Node itself up and running on the various platforms involved was a significant part of the problem. These weren't Linux boxes built around Xeons. It turns out that as soon as you go outside of the mainstream, the tools and documentation for building and running Node are awful compared to a lot of other languages.

The lack of standardisation and stability and the relatively poor dependency handling within the Node ecosystem were also major factors. Way too much time was spent just trying to make sure different machines really did have identical packages installed, figuring out how to pin everything down to make reproducible builds, and so on. Again, if you're happy just to shrinkwrap, npm install on your local machine, and wait if the repository is unavailable, that's one thing. However, as soon as you start talking about preserving exact configurations within 100% local build environments or building images to install on different machines, all kinds of problems crop up that have been well addressed by now within a lot of more mature language ecosystems but not so far with Node.

Another problem was that Node and its ecosystem are just so heavy overall, and this one is nothing to do with the variety of platforms in use. It's just a big runtime, and a lot of overhead because of the way libraries and dependencies are handled. This would be an issue for anyone operating with limited resources, whether it's trying to run something on a Raspberry Pi or trying to keep costs down by using the smallest possible instances of cloud-hosted virtual servers.

There did also seem to be an element of wanting to use the shiny new toys, and of stubbornly sticking with those toys for far longer than should probably have been allowed, so in that sense there were issues with the developer as well.

But there was also a willingness among the wider team to trust that developer, at least to begin with, because with Node's high profile and large ecosystem, no-one expected it to be as immature as it turned out to be as soon as you left the mainstream. For comparison, porting code written in traditional systems programming languages like C and C++ was done routinely, but even among the dynamic/scripting family, the more established server-side languages have caused far fewer problems than Node.

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

#134

Post by paulddraper »

joshmanders wrote: post #33
dualogy wrote: post #23

Earlier quoted context omitted.

> JavaScript in general is in a huge influx of updating at this moment Isn't that the case basically all the time? Which is a perfectly suitable reason to avoid it at all costs except for the bare minimum required for front-end..

> Isn't that the case basically all the time? No, ES5 to ES2015 is a HUGE leap. ES2015 to ES2016 is a very minor jump as it only adds 2 new things to the spec. > Which is a perfectly suitable reason to avoid it at all costs except for the bare minimum required for front-end.. And honestly, that is not my job to tell you not to do. If you want to avoid Node.js go ahead. I feel Java is something I should avoid at all c…

Naturally. That's a jump of 2010 compared to 1

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

#135

Post by paulddraper »

eknkc wrote: post #15

TLDR; Author actually wants to use Python. Used Node.JS regardless, for whatever reason.. It did not work the way Python works. Author is frustrated. Complains that JavaScript is not Python.

I love Python and hate JS as much as the next guy. But complaining that JS idioms do errors differently than Python idioms is stupid.

It's like saying

"JS is stupid because people use braces and whitespace to denote flow control"

Adopt the paradigm and see how well the technology fits it

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

#137

Post by jondubois »

- 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 massive hack intended to fix the impedence mismatch between relational DBs and RESTful APIs. If you used a NoSQL DB with Node.js (such as RethinkDB), your life would be much easier. Nobody in the Node.js community except your grandma cares about ORMs because they're considered legacy technology. If you don't like it, then you can stick to your COBOL and Oracle database.

- Node.js lets you choose how you want to handle errors. JavaScript offers an Error class which exposes a name property (which you can overwrite for each error type) and you can also attach custom properties to Error objects (to carry back more detailed info specific to each Error type). JavaScript is really easy to serialize/deserialize so you can even design your error handling system to be isomorphic (same error handling on the client/browser and server). I really enjoy error handling in Node.js/JavaScript - You just have to put some thought into it.

- The way of writing async logic is changing. The fact that Node.js is keeping up is a good thing. There is no single right way to handle async logic. Most well-maintained libraries will keep slowly evolving to use the newer features of the language but it's mostly backwards compatible (many libraries support both callbacks and promises).

- The standards are not bad; they're evolving and you can choose your own styleguides for your projects. Most JS developers will adapt to new styleguides as they move between companies/projects.

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

#138

Post by spion »

Silhouette wrote: post #132
spion wrote: post #120

Earlier quoted context omitted.

Sounds like this has absolutely nothing to do with the technologies and everything to do with the developers.

Yes and no. The difficulty of getting Node itself up and running on the various platforms involved was a significant part of the problem. These weren't Linux boxes built around Xeons. It turns out that as soon as you go outside of the mainstream, the tools and documentation for building and running Node are awful compared to a lot of other languages. The lack of standardisation and stability and the relatively poor d…

> The tools and documentation for building and running Node are awful compared to a lot of other languages.

Can you be more specific?

> It's just a big runtime, and a lot of overhead because of the way libraries and dependencies are handled.

Compared to what exactly? I don't see any mainstream dynamic language except Lua doing better. Ruby? Python?

If you don't need native modules (which is actually the case in a surprising number of situations) there is no build process, except making a tarball of node_modules and the project. If you do need native modules, the situation is slightly worse than C or C++, but not significantly: you generally need to build on a machine with the same architecture (Setting up cross-compilation with C isn't very easy either)

> A lot of overhead because of the way libraries and dependencies are handled.

This has some truth to it, but in my experience its overblown. Being just a little bit careful with your dependencies goes a long way.

The Raspberry Pi 2 is a speed monster for node. Plenty of RAM. Here is a basic 2012 benchmark on the Pi 1: http://guidogarcia.net/blog/2012/09/13/node-js-on-my-raspber...

On the other hand, if you want to run node on something like this: https://www.olimex.com/Products/OLinuXino/iMX233/iMX233-OLin... that will definitely be a problem. Thats about the lowest specced hardware that can (barely) run it, but 64MB RAM just isn't enough, really.

P.S. Based on what you said, I have a hunch that most of your troubles came from this module: https://github.com/mapbox/node-sqlite3 - is that right?

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

#140

Post by Derbasti »

uptownJimmy wrote: post #106
joshmanders wrote: post #14

Earlier quoted context omitted.

You should try to surround yourself with developers who don't have such attitudes. I am a fan of JavaScript, I love Node.js and I will often times suggest it to newbies. But I don't pretend it's the be all/end all of languages. Just like any other language it has its strengths and weaknesses. It's up to you to decide if it's the right choice for you.

It is one of my most cherished professional goals to avoid ever working with people who think like this. The message this sends to junior devs is so backwards and wrong-headed that it defies discourse.

why?
Post reply on HN