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.

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.

will ping you.

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.

You raise a great point. Another big challenge we have had is re-educating developers. This has been helped by finding the really sharp engineers internally and hiring new engineers that bring in the right DNA.

I think we are getting to a tipping point, but it is a lot of work obviously.

Technology is not a silver bullet. Nor process. At the end of the day it is about your people. Technology & process can set them free.

I can assure you that I had to attack multiple fronts. Process is a big part of it (I brought in LeanUX methodology), but I can tell you (and painfully so) that if we had not changed the technology we would not be moving at anywhere near the speed we can now.

Mind you that what you see on the PayPal sites is not all updated. This is a testament to just how deep the technical stack has been.

Other colleagues have been attacking the services layer and they are doing just as much change in that layer as my team has done on the app/frontend layer.

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.

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.