How PayPal is being revolutionized by Node.js and Lean UX
nearform.com
nearform.com
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).
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.
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 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.
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.
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.
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.
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.
Seriously though, I doubt it. Most of it is very in-house.
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?
Keep in mind that PayPal is a gut-wrenching edge case of internationalization and localization. If you're an Israeli person transferring Thai baht while you're in Chile, the website must account for that while respecting your user preferences and all local, national, and international law. It's a gross problem no matter how you handle it, and it utterly prevents drive-by redesigns.
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.
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...)
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.
There is nothing about Java that stops you writing your CSS in CSS and your JavaScript in JavaScript. In fact, that's the standard way to do it. It seems that at PayPal, something went wrong early on that led them to build some byzantine homebrew web framework as a rod for their own backs. I have no idea why anyone would do that, but it seems to be a remarkably common thing to do.
They probably made their own web framework because nothing good existed at the time.
Disclaimer - I contribute to the xsbt-web-plugin
[1] http://www.scala-sbt.org/ [2] https://github.com/JamesEarlDouglas/xsbt-web-plugin
Using GWT you don't "write Javascript in Java", the java-code is written in java and then compiled to optimized, cross-browser, javascript. Compile-times can be quite long - but again, during development you will use the hosted-mode (or even the new super-dev-mode) version, which compiles on the fly. Full java-to-javascript compilation is typically only needed when new versions are deployed to stage/prod.
I mean, I still think Java and the JVM are great for many many a use case, not trying to pine for node here.
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.
Having been on a team where the pendulum has swung both ways I know firsthand that you can be too agile and end up regretting it later.
Bitcoin (or bitcoinlike replacement) is the future and the most interesting thing to come out (Technologywise) since email, bittorent or social networks
Let's compare that to the number of people who know what Bitcoin is.
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.
They're essentially a monopolist.
Nobody else has what they have: access to nearly every country, worldwide.
A) People who are outside the US.
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".
PS: I switched from JS to C# - it is an amazing experience!
How do they went to 3-5 times less files without recurring to several classes, controllers, etc in the same file?
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.
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?
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.
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.
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.
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).
If it's just a front-end of the actual processing then meh.