5 ms·

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 s

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-should-work-with-me-at-paypal.html 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.

jmagoon 13y ago
So it still has little specifically to do with Java vs. node.js. Just a ridiculously bad old process to a better new process.
- twic 13y ago
  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.
  - catch23 13y ago
    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.
eeperson 13y ago
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/ http://www.scala-sbt.org/ [2] https://github.com/JamesEarlDouglas/xsbt-web-plugin https://github.com/JamesEarlDouglas/xsbt-web-plugin
tootie 13y ago
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 13y ago
  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 13y ago
    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.
larsmak 13y ago
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.

jmagoon 13y ago

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

twic 13y ago
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.
- catch23 13y ago
  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.

eeperson 13y ago

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/ http://www.scala-sbt.org/ [2] https://github.com/JamesEarlDouglas/xsbt-web-plugin https://github.com/JamesEarlDouglas/xsbt-web-plugin

tootie 13y ago

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 13y ago
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 13y ago
  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.

larsmak 13y ago

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.