Hacker News Reader

Comment by tootie | Hacker News Reader

"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.

View on HN

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...)

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.

So it still has little specifically to do with Java vs. node.js. Just a ridiculously bad old process to a better new process.

No, it's also about a ridiculously bad old architecture to a better new architecture.

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.

Paypal is ancient. It's likely they developed their web framework before any open source java web frameworks became popular. Paypal existed around 1998, Java Struts 1.0 came out in 1999. Struts 1.0 is probably one of the big reasons many people flocked to PHP.

They probably made their own web framework because nothing good existed at the time.

Servlet container restarts don't have to have a huge overhead for development (not sure about using a full j2ee container). If you use SBT[1] plus the the xsbt-web-plugin[2] then restarts are just as fast as they are for node projects.

Disclaimer - I contribute to the xsbt-web-plugin

[1] http://www.scala-sbt.org/ [2] https://github.com/JamesEarlDouglas/xsbt-web-plugin

J2EE-containers can take a while to start indeed (for large projects), but in most cases they can be tuned to restart in less than 10sec - at least during development.

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.

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.

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.

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.

I read that another way. The whole article sounded like they replaced engineering with hacking/prototyping and measuring the productivity of a prototype vs the productivity of battle-hardened code. There is an admission that they have no specs and i also got the impression that they have no tests. I seriously doubt that at the claimed turnaround times they have a proper code review process. It sounded to me like they were getting false productivity and eventually would program their way back into a corner.

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.

I wondered about that too--I didn't see any mention of any software testing. Definitely user/outcome testing, but no unit tests or functional tests were mentioned.

Reply on news.ycombinator.com