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

Disabling npm's progress bar yields a 2x npm install speed improvement

twitter.com

Post reply on HN
Print view View original

181–187 of 187 posts

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#181

Post by oldmanjay »

morebetterer wrote: post #176
oldmanjay wrote: post #171

Earlier quoted context omitted.

No, you're making bad jokes in a context where they aren't welcome. You may want to try Reddit or Slashdot. They enjoy this sort of thing, I understand.

Thank goodness we have you and others to police the jokes. Remain vigilant! Keep up the good work.

Do you feel that being an asshole will make you more acceptable to the community?

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#182

Post by mrmondo »

pixelHD wrote: post #158
mrmondo wrote: post #127

Earlier quoted context omitted.

Don't even get me started on the number of reasons why nodejs should not be running on servers, I'll be here all day. We're currently deploying a NodeJS app and we'll never do it again - the amount of problems with that ecosystem is quite amazing. As I tweeted earlier today "JS ppl tend to have marketing & UI/UX experience so JS crapcode gets popularised, becomes widespread, then we have to deal with the fallout".

I'm genuinely interested. I've been using nodejs for hobby projects and scripts, so haven't seen too many issues. But I'd like to know how things are and what issues you've been seeing.

Howdy, we've had lots of issues with single threaded performance, poor memory management especially around garbage collection, we had to modify our SELinux policies as it likes to execute memory off the stack, npm has been very unreliable and often unreasonably slow, error handling of the node index app server seems to have some interesting behaviour but I haven't dug into that one too deeply yet and the list goes on. As an experienced systems engineer it's very clear that this is browser technology that was never designed not fit to run on servers.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#183

Post by rnijveld »

freshyill wrote: post #51
agumonkey wrote: post #30

Earlier quoted context omitted.

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

I see that with iTerm 2, but using Terminal gives me a very different experience. Here's a side-by-side: https://youtu.be/odoVfHHBYVM Until recently, I had no clue iTerm was doing something weird. I just figured npm install was just ugly and incomprehensible.

My iTerm2 has the same behavior as your Terminal.app, so you might just have to change some settings in iTerm.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#184

Post by lilyball »

moonchrome wrote: post #113
lilyball wrote: post #91

Earlier quoted context omitted.

This is not only completely wrong, it's dangerously wrong. It is in fact wildly unsafe to touch the GUI from anything except the main thread. It's all the non-UI stuff that you should shove onto another thread.

Depends on what you call "main thread" - maybe he's saying worker thread that's doing the "main code" shouldn't be doing GUI

Nope, the term "main thread" is very explicitly defined by both iOS and OS X. Not only in all the frameworks (e.g. NSThread, NSRunLoop, etc. all explicitly define "main thread"), but even at the system level. OS X and iOS have a pthread function `int pthread_main_np(void);` that returns non-zero if the current thread is the main thread (meaning the initial thread that the application was launched with), and that is the thread that all UIKit (iOS UI) and AppKit (OS X UI) code must be running on.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#185

Post by mbell »

stormbeta wrote: post #93
mbell wrote: post #74

Earlier quoted context omitted.

I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.

You get a similar effect for free with any language whose community defaults to non-floating transitive dependencies, e.g most JVM languages.

I've spent enough time in my life fighting with version mis-matches of slf4j. Hard defining your dependency versions just pushes the problem upstream.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#186

Post by [deleted] »

mbell wrote: post #74
juandazapata wrote: post #45

Earlier quoted context omitted.

That's frustrating, I got bitten by that a couple of times. I'm wondering when will they add a LOCKFILE like every other build system out there :'(

I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.

[deleted]

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#187

Post by sombremesa »

technomancy wrote: post #103
ClayFerguson wrote: post #68

Doing GUI calls is a notorious way to slow down apps. I sped up an app (major software from major large corporation) by a factor of 10x a few years back by removing GUI updates. What you have to do is create a thread that refreshes the GUI periodically and not let your main worker thread ever work on the GUI. This particular app was an Eclipse Plugin (a source control app) and the Eclipse SWT to update the console lo…

> What you have to do is create a thread [...] A thread? But that'll never scale!

It's Eclipse. It'll never scale regardless.
Post reply on HN