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

61–70 of 248 posts

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

#61

Post by Touche »

Wintamute wrote: post #52
Touche wrote: post #48

Earlier quoted context omitted.

NPM scripts are just a different problem. See: https://twitter.com/sindresorhus/status/724259780676575232?l... https://github.com/ReactiveX/rxjs/blob/a3ec89605a24a6f54e577... Already people are coming up with new "solutions" to this problem that looks more like Grunt. It's a repetitive circle. Personally I just use Make.

So somebody found a project somewhere on the internet with an exceptionally complicated build process, and you use it to say npm scripts are broken? Sorry, that's absurd. Looking at that particular build process, I don't think a Makefile could have been crafted to make it much simpler or smaller. In that example, the problem lies with the complexity of what they're having to do, not the tool. Npm scripts are really j…

It's an inflated example of what all npm script projects become, imo. First you just have "test", then you add "build", then you separate your "test" into one for the browser, one for Node, one for CI, then you need scripts that combine those together; then you create different "start" versions depending on environment... It blows up quickly.

> Npm scripts are really just shell scripting, which means all the real progress happens in the unixy Node tools that do the heavy lifting, where it should be.

That's fine, but you're missing critical features that Make provides; make won't even rebuild a target if no files have changed.

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

#62

Post by spion »

Touche wrote: post #48
Wintamute wrote: post #32

> You use Grunt!? Everyone uses Gulp!? Wait no, use native NPM scripts! Although couched as a criticism this is actually the community fixing itself. The evolution from Grunt > Gulp > npm scripts is movement away from needless complexity towards simplicity. Npm scripts are effectively just Bash commands that build and manage your project, which sometimes employ small, unixy tools written in Node. This self correction…

NPM scripts are just a different problem. See: https://twitter.com/sindresorhus/status/724259780676575232?l... https://github.com/ReactiveX/rxjs/blob/a3ec89605a24a6f54e577... Already people are coming up with new "solutions" to this problem that looks more like Grunt. It's a repetitive circle. Personally I just use Make.

That actually looks better than most Gruntfiles I've seen.

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

#63

Post by silviogutierrez »

Same experience as the author. Tons of reinventing the wheel, and hundreds of dependencies.

The majority of established companies that say they use Node in production are doing so as a fancy proxy. All the "serious" stuff is done on backend services written in other languages.

Moreover, asynchrony is a concept far more advanced than most people think.

We will likely continue to leverage Node as a fancy proxy. Adding Typescript will only help. But it's likely that as Node grows into a mature platform, other platforms will continue to fill in the gaps that Node filled.

See for example Node constantly adding [foo]Sync versions of methods, while Python adds first class sync support.

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

#64

Post by spion »

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…

With node, at least you have the option to easily migrate to TypeScript and get excellent tooling.

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

#65

Post by Silhouette »

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…

Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again.

If only that were true! I think the JS (and more generally web development) ecosystem today is more a case of those who do not learn from history being doomed to repeat it. The thing is, if you actually are Google or Facebook or Microsoft or Mozilla or Apple, you can throw huge amounts of resources at problems and produce sufficiently useful solutions regardless, and then you can do the same again a few months later if you need to. These are the kinds of organisations that set the tone for the whole community because of their sheer size and influence. However, their goals are not necessarily aligned with the rest of the web development community, nor will their approach necessarily work well for someone else.

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

#67

Post by Touche »

Silhouette wrote: post #56
firasd wrote: post #25

I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used. The whole async situation needs to settle down, it's completely unacceptable to write code with callbacks, promises, etc. This is because they are not just challenging to deal with, but intrinsically wrong in concept. I have to wait for a database query to complete, then pass…

I find that JS often seems to tie programmers in the most extraordinary knots just to implement even quite simple logic, because of the single-threaded nature of the language. In the programming model used by most other mainstream languages today, if you've got some work to do that interacts with some external system and might take a while, you'd probably start another thread for that task. You'd write the required l…

> Modelling this using fork/join semantics and techniques to co-ordinate access to shared resources from different threads are reasonably well understood ideas.

Writing thread-safe code is anything but easy in languages that support threads.

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

#68

Post by oceanstone »

tylerlh wrote: post #40

The Netflix.com site and webapp runs on Node (and talks to a number of services written in mostly JVM based languages). While we encounter challenges just as we would with any other language -- it works for us and I would argue that it's a pretty big application. There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best. Don't treat any one language as an end-all…

> There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best

Well said.

By the way, what is Netflix's take on Promises vs RxJS?

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

#69

Post by [deleted] »

spion wrote: post #3

> Coming from other languages such as Python, Ruby or PHP you’d expect throwing and catching errors, or even returning an error from a function would be a straightforward way of handling errors. Not so with Node. Instead, you get to pass your errors around in your callbacks (or promises) - thats right, no throwing of exceptions. Promises let you throw errors normally. They will propagate up the call stack in a simila…

[deleted]

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

#70

Post by beders »

spion wrote: post #64
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…

With node, at least you have the option to easily migrate to TypeScript and get excellent tooling.

if all the libraries you are using are as well...maybe.
Post reply on HN