Live data from Hacker News

About PayPal's Node vs Java “fight”

developer-blog.cloudbees.com

1–10 of 216 posts

Re: About PayPal's Node vs Java “fight”

#5
Well-reasoned.

I've always found framework overhead and especially tech debt to be the largest contributors to performance issues. Especially when said frameworks have lots of ways to do things and they're not all the best way to do it.

Modern JVM development starts to look a lot like Sinatra -- you don't get a lot baked in, but you probably didn't need it anyways.

Re: About PayPal's Node vs Java “fight”

#7
Regarding the JVM performance:

> Under minimum load the best page rendering time was 233ms

Regarding the node.js performance:

> Under minimum load the best page rendering time was 249ms

What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going to be mostly waiting for external resources (DB, message queue, etc).

Without knowing how much time is spent on those external requests these numbers are meaningless.

Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).

If every request you process involves serially accessing a 50-100ms external resource four or five times then it will always take 250ms (though you could increase parallelism of multiple requests if done right).

Re: About PayPal's Node vs Java “fight”

#9
Maybe we should assume the best instead of the worst. We could assume that paypal has capable developers who are knowledgeable about both the jvm and node.js, and who have concluded that their specific featureset can best be built using node. That is not a value judgment of the jvm vs node in general, as their situation is theirs and theirs alone.

Re: About PayPal's Node vs Java “fight”

#10

Summary: Most frameworks sux.

Wrong. PayPal refuses to use open source frameworks because of an internal culture (and self preservation interest) of some very old "architects" who really only care about being in charge of the next internal framework. The best part is they later get to showcase how much better the new one is compared to the old framework, even though it's multiples slower than the slowest open-source counterpart.
Post reply on HN