
How PayPal is being revolutionized by Node.js and Lean UX - darsee
http://www.nearform.com/nodecrunch/?p=109
======
arscan
I'm not so sure that it was node.js that revolutionized paypal... seems like
the gains were from switching to a more agile process (and adding some
supporting tools). A lot of the fixes seem pretty agnostic to the actual
platform that they switched to.

Note that all those open source modules that they talk about aren't released
yet. krakenjs.com doesn't even resolve (for me at least).

~~~
kamaal
Its will be a little saying too much, to say node.js revolutionized paypal.
But speaking as a matter of fact programming languages do play significant
role in the overall productivity of the teams.

I wouldn't be too surprised if they are saying using Java was making it
difficult to turnaround issues. The problem isn't Java the language itself,
but the processes involved in taking changes to production with these
languages are generally so much ceremony large turnaround times become the
norm.

Add to this issues like fixing build failures, test failures, code reviews
that span meta aspects of code(config changes, xmls etc), running around to
get libraries standardized per your company standards(getting it into your
local maven repo etc); and much more. These sort of things really slow you
down. With these if you are tending to multiples issues, or if you have
dependencies on your colleagues- I wouldn't be surprised with the 6-month
delays mentioned in the article are actually true.

~~~
smrtinsert
Better said, since there is no compilation step, so you can push non working
js through and it will look "green".

Java isn't defined by a process, that's sad most people don't seem to
understand that. Look at projects like dropwizard, happily throwing away what
they dont like.

~~~
billwscott
I think you are close to the mark. There are ways to work in Java/JSP
environment that is pretty quick cycle time. But I will say that our
experience at PayPal is the code is more terse, less files, npm so much better
than maven for managing dependencies, coupled with the fact that our
javascript templating allows portability between server & client.

The Shift-Refresh style of programming is hard to overstate how much that
creates a different mindset.

And to my point in the talk, the blending of prototyping and production tech
stacks is also huge for being able to quickly iterate with users.

------
zabraxias
PayPal is still running on something they call XPT and their admin tools are
built with something called Maxcode (Max Levchin wrote it).

As of 2 years ago they revolutionized CSS by having it being generated from
Java because their fellowship of the ring wanted control over which properties
you can use and how. Everything they do from a tech perspective has been to
allow them to hire cheap labor while restricting which HTML/CSS they have
access to. It's probably a good business strategy (like making sure they don't
get classified as a bank) but it fosters an abysmal tech culture.

I have no way to prove the points above you'd just have to trust that I worked
there as a UI dev.

~~~
gamache
I worked in PayPal's mobile team for a few months last year (acqui-hire). I
can confirm that as of two years ago, everything you said is true, but as of
last year the groundwork was laid for everything in this article being true
today.

I used the PayPal Node stuff in its infancy (i.e., before anything was
working). At that point it was a thirdhand tarball being passed around. Even
in its preliminary state it was about 500% less shitty than using the old
stuff (Sparta, JSP, etc).

I am glad to see that the (small, relatively insulated) team could deliver. I
expect this migration will make many PP engineers obsolete, but I don't have a
problem with that.

~~~
yla92
Is there anywhere I can read about the technologies that PayPal is using in
production ?

~~~
gamache
New hire orientation!

Seriously though, I doubt it. Most of it is very in-house.

------
widdershins
Interesting article, but I'm in the UK and Paypal still looks and works
exactly the same for me as it has for years. It's very slow, rather ugly, and
very inconsistent - the splash page seems styled differently to the login page
seems styled differently to the help page... I could go on.

I know this is mostly superficial stuff, but it doesn't contribute to a good
experience at all.

Slightly OT, but why is it suddenly all the rage for sites to have persistent
nav-bars that follow you down the page? The one on this blog is obnoxiously
huge, and obscures a lot of content. What's wrong with scrolling to the top of
the page?

~~~
KiwiCoder
I put a persistent nav bar at the top of my latest site
([http://bosscheck.me](http://bosscheck.me)) so that potential customers are
always looking at a "book now" option. Shallow and obvious, perhaps, but my
assumption is that this is optimal for conversion.

~~~
QuasarLogic
Your navbar is much nicer and less intrusive though, I like it. Have you
thought about differentiating the booking button from the rest of your navbar
elements?

~~~
KiwiCoder
Yes, I've thought about that exact idea probably more than it deserves, but
I'm trying to err on the side of not appearing spammy while simultaneously
keeping the "book now" button always in easy reach.

------
tootie
"Head count: Node.js. Typically they are seeing anywhere from ⅓ to 1/10 the
number of developers needed on the new stack vs the old stack."

That's ridiculously implausible. I know node is more concise, but 300-1000%
productivity increase doesn't come from less typing. Even if we assume they
had a lengthy build/restart cycle on some J2EE web container, that could only
plausibly increase output by 10-20%. Sounds like they had an absolutely shitty
application architecture and he convinced them to do something both reasonable
and modern with the former being the biggest improvement.

~~~
astral303
First of all, J2EE web container lengthy restart is a huge overhead alone, and
in case of iterating over a feature, I can easily see a 30-50% difference.

But second of all, from the article: "You didn’t write html, css or javascript
– you wrote css in java, you wrote html in java and you wrote javascript in
java." Can you imagine developing that?

A Google search reveals: "the only thing worse than XML/XSLT is a proprietary
form of XML/XSLT -- which of course is what PayPal was built on (C++ on the
backend)." (from [http://looksgoodworkswell.blogspot.com/2012/09/why-you-
shoul...](http://looksgoodworkswell.blogspot.com/2012/09/why-you-should-work-
with-me-at-paypal.html))

I've been involved with writing Javascript in Java using GWT and it has poor
developer productivity, especially as the project gets to anything beyond a
medium size. At a medium size, compilation times get well above 5 minutes, and
I can't even imagine a large app the size of a PayPal.

Imagine having to figure out the right XML/XSLT to transform into the right
Javascript.

So it's not at all ridiculously implausible. At previous jobs, I worked with
some really arcane stacks and you can't imagine the number of unnecessary
layers that get in the way of good old GSD.

~~~
tootie
Poor separation of concerns can be easily solved in J2EE and build/restart can
be solved with something like JRebel or just using a lighter contain like
Jetty for dev. I'm just saying Java to Node is not going to give everyone a
huge increase in productivity. Programming in itself doesn't even solve most
of the worst bottlenecks.

~~~
astral303
I agree that Java to Node is not a magic solution. Clearly, like posters below
have mention, it's the old architecture/stack that's the problem. J2EE
containers have come a long way now, I can restart my Tomcat/Jetty containers
in a flash, unlike Weblogic/Websphere of the days past ( _shudder_ ).

I mean, I still think Java and the JVM are great for many many a use case, not
trying to pine for node here.

~~~
billwscott
I agree. I am actually not a Java hater :-) In fact I have built 4 distinct
Java/JSP frameworks since 1996.

You can really create some very nice frameworks with Java using some of what
you say below. The Java framework at PayPal made a few mistakes (in my
opinion) that made the environment harder to work in than it should have been.

But I started with needed to rapidly iterate, move between prototype &
production easily, take advantage of asynchronous nature of node for our web
apps to scale better, simplify the engineering team makeup (not have multiple
types of engineers). These all led to deciding to move forward with node.

Oh, and let's face it, recruiting is a little easier with nodejs.

------
leokun
A little off topic but that giant fixed header that obscures 30% of the
vertical space I have available on my 15" macbook pro retina so I can see a
lot of whitespace. This is terrible and made me not want to read the post.

~~~
taf2
right click - inspect element - select "<nav>" element following body tag.
right click -> "delete".

~~~
leokun
Command+W to close the tab is just so much more convenient though.

~~~
AsymetricCom
Throwing your computer out the window will save you even more time.

~~~
leokun
Somedays I want to do that.

------
dangrossman
PayPal has so much legacy UI cruft even their own employees can't figure it
out. I was talking to a support rep on the phone last week who was telling me
to click something on my home screen that wasn't there. It wasn't there
because she couldn't figure out which of the 4 home screen interfaces my
account was on -- having a business account with PP Pro subscription means I
have extra reporting menus but none of the updated design of the past few
years. Going from their public site to my logged-in profile page exposes me to
3 totally different page layouts.

------
Touche
In most cases position: fixed is unnecessary. But it's _especially_
unnecessary when your navbar takes up a quarter of the height of the screen.
Please reconsider this approach, it's really not needed for users to see your
sitemap at all times while reading a technical article.

------
dcc1
Who cares about Paypal? they have screwed so many people and companies one has
to wonder how they get away with it and still are in business

Bitcoin (or bitcoinlike replacement) is the future and the most interesting
thing to come out (Technologywise) since email, bittorent or social networks

~~~
conradfr
Business who accept payment online. People who use eBay.

Let's compare that to the number of people who know what Bitcoin is.

~~~
dcc1
See the comment above comparing Paypal vs Bitcoin to Microsoft vs Linux

in the long run (10 years) either bitcoin or bitcoinlike replacement is going
to trash Paypal in same manner that Linux, android etc is trashing Microsoft
now, yes Microsoft still make billions but bitcoin is growing rapidly, many
people wrote off Linux years ago too for very similar sounding reasons.

~~~
ScottWhigham
Yes, but your question wasn't a long run question, was it? It was a teenage-
angst filled question: "Who cares about Paypal?" $44,000,000,000 in payments
processed in three months - I think that is another way of saying, "Most of
the people who pay for things online care about PayPal."

~~~
dcc1
its not too far behind paypal already and growing rapidly in use
[http://coinometrics.com/bitcoin/btix](http://coinometrics.com/bitcoin/btix)

------
CmonDev
"Node.js and javascript all the way up from just above the services layer to
the frontend layer"

Sounds like a glorified web GUI layer. Good old statically-typed Java is still
used for the stuff that does the actual work.

I propose a new article title "How PayPal switched to a more reasonable web
GUI approach".

~~~
Already__Taken
I propose you read the article past step 5

~~~
CmonDev
I did. That quote is from step 6. Read again - everything revolves around
front-end.

------
KiwiCoder
Content (text only) mirrored here:
[http://pastebin.com/aFPtzPpD](http://pastebin.com/aFPtzPpD)

------
filipedeschamps
Here in our company we are also changing everything to Node.js (currently
abandoning C#) and it's being an amazing experience.

~~~
ScottWhigham
Another "What - how does that work?" question here. What you've said just
isn't making sense - you're replacing a server side programming language with
a client-side JS framework. There's obviously other "things" going on - I'd be
interested to hear much more. C# is such a great language but ASP.NET is so
slow...

~~~
themoonbus
Well for starters, node.js isn't a client-side JS framework, it's a server-
side JavaScript platform.

------
mromanuk
"Lines of code: In general they have seen code size shrink by factor of 3-5 by
moving from the Java stack to the Node stack. Even the number of files shrunk
by a similar factor."

How do they went to 3-5 times less files without recurring to several classes,
controllers, etc in the same file?

~~~
jffry
I'm guessing that a good chunk of that came from either reducing the actual
complexity of their UI, or from simplifying horribly-fragmented old code. And
I would guess more of the former than the latter.

~~~
billwscott
We actually had the luxury of comparing parallel efforts. While Node was being
readied for production we were writing our new consumer/wallet app with the
PayPal Java framework (based on Spring). Meanwhile we started writing the Node
version. Once we got to a certain point the Java team insisted that they stop
the Java development and start on Node with the node team. At this point we
had two versions of the app built in two stacks and thus could compare code
size, developer productivity & scale.

Of course, if we compare the new node apps vs the old PayPal code... well that
would be a poor comparison as they really were old and monolithic.

~~~
jffry
Cool - it's great to hear that you guys actually got to put it to a head-to-
head comparison with the old ways.

How heavily have you customized Spring, versus how much did you use various
Node modules out of the box (versus having to adapt things to your backend)?
Do you think part of the productivity gap comes from the large learning curve
of your PayPal framework or just from Spring in general?

~~~
billwscott
Not from Spring. Spring is a solid reasonable framework. Unfortunately the
modifications were enough to cause confusion, the Windows-biased support (not
good support for Mac) for the dev environment, forcing people to use Eclipse,
having lots of server-side solutions for stuff that is already readily
available on github as a simple JS library and on and on.

I still feel that even set against Spring or GWT or any Java server-side UI
framework, Node plays much nicer and really gets you to the Shift-Refresh type
of programming that is perfect for app development.

We used (and use) node modules completely out of the box. We add additional
modules to augment. We are really adamant not to follow the roll your own
mindset. We have had numerous times that we threw away our work in lieu of a
new npm module that did what we were doing as good or better than ours. Why
spend time doing that when we have so much technical debt to overcome to get
to the state of really innovating.

------
ilaksh
If they had that many developers I am not sure why they invented such a
complex alternative to a private npm repo with the full replication. I mean it
only took half a day to set up and then two days to load. Heh.

But I glad they did it. I really feel like someone should take some code like
the core if Kappa and integrate it into npm so you don't have to wait two days
or whatever to replicate a giant database just so you can have private
modules. I know that will make a few peoples business model go away but I hope
that's not what is stopping it from happening.

------
neovive
This is interesting. We researched Node.js a bit and found many arguments on
StackOverflow against using it for apps that require heavy DB interaction
and/or non-real-time apps. Also, there seemed to be many people pointing to
the single-process model as risky. Is this no longer the case or have these
issues been addressed through configuration? I would love to give Node.js a
try again.

~~~
baudehlo
It never was the case. Ignore the stack overflow dribble.

------
pkmishra
I do not agree that node.js revolutionized the company and everyone should
start using node.js everywhere. Rather a better approach is what suggested by
Nicholas - [http://www.nczonline.net/blog/2013/10/07/node-js-and-the-
new...](http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-
front-end/)

~~~
billwscott
Hmmm... That is kind of humorous, given that Nicholas was a consultant for us
early last year as we started this effort. His team was also at PayPal today
(from Box). That article was influenced to some degree by me giving a talk at
Box HQ on this very topic.

Also, maybe you misunderstand what we are doing. We are using nodejs for the
web app layer. But it could be used for services (like Walmart Labs is doing).
You really have to determine the context, the people, the technology, the
amount of risk, and so on to decide.

But I do agree, no one should see nodejs as a silver bullet.

------
vaadu
Why would anyone let an unregulated internet company have control of their
money? Especially one with a track record like PayPal.

~~~
icebraining
_unregulated_

PayPayl is licensed and regulated as a money transmitter in multiple US states
and as a bank in the EU¹. The idea that states would allow it to transfer the
amounts it does without being regulated is funny, but not realistic (and not
true).

¹ [https://www.paypal-media.com/licenses](https://www.paypal-
media.com/licenses)

------
jebblue
I read through the article, hard to believe they will be processing billions
of dollars on top of JavaScript. Maybe I've been wrong and now it's time to
dump Java and go all script.

~~~
chillax
I'm guessing this is just the front-end of paypal. The backend is most likely
Java-based and is never going to be changed to Node.

------
singingfish
Article really confirms my suspicion that node.js is pretty much the new perl.
(Although modern perl is still an excellent choice for new projects if you
need small team high impact stuff).

------
AdrianRossouw
it's interesting how some established startups (if paypal could even be
referred to as that anymore) have been getting gains by leveraging node.js
into existing stacks.

~~~
ericcholis
To me, it's more interesting to see the willingness of large companies like
PayPal to leverage "new" technologies in any way. The common narrative of
large companies suggests otherwise.

------
smackfu
As of today, Paypal still shows an interstitial progress screen after you
enter your userid and password and hit sign-in.

------
puppetmaster3
PayPal sux! that's all.

