6 ms·

LinkedIn is primarily a JVM shop. We believe that type-safe languages like Java and Scala are a good choice for building performant and reliable systems that sc

LinkedIn is primarily a JVM shop. We believe that type-safe languages like Java and Scala are a good choice for building performant and reliable systems that scale to huge numbers of users as well as huge numbers of developers. We aren't constrained to the JVM - for example, we use node.js for our mobile server - but it has significant advantages and we have years of investment in it. Unfortunately, we found developer productivity in the Java/Scala world to be a huge problem. We also found that most Java/Scala web stacks, based on servlets, were far behind other web frameworks (RoR, Django, etc) in terms of keeping up with the requirements of modern web development. Play helps on both fronts: it dramatically improves developer productivity and handles all the requirements of a modern web stack (MVC, web sockets, powerful routing, easy JSON handling, DRY form handling, etc). Is it better than RoR, Django, Node? In some ways yes (e.g. Play's reactive programming model is dramatically better than JavaScript's callback mess), in some ways no (e.g. it's hard to compete with dynamic/interpreted languages for pure reload time). Is it better than everything else in the Java/Scala world? We think so.

smrtinsert 14y ago
Developer productivity is really broad. Can you elaborate? Most modern webapps I work on end up as json services and the backend are just java pojo services that can be unit and int tested - tdd with java is extremely fast in my experience. the whole servlets/jsp/jsf thing is dead imo, is that where you guys were losing time?
- chaostheory 14y ago
  If I were to guess, it would be configuration, more specifically the myriad number of choices and combinations of it. Spring's strength and weakness is the power of customizing it.
- brikis98 14y ago
  We had Java services that produced JSON, some that used JSPs, and a variety of others. TDD works in some cases, but if you ever wanted to do manual testing - for example, actually see the UI you were working on with real data - that meant redeploying the server after every change. Play makes this dramatically faster/easier. TDD is better with Play as well: the plugin support, strong test tools, and sbt's ~test command are amazingly productive.
  - smrtinsert 14y ago
    Personally I rarely test all ui because QUnit verifies all frontend code so long as it meets the json contract. Regardless, thanks for your post, I'll give Play a go!
zmmmmm 14y ago
I'm curious if you ever evaluated Groovy? With optional static typing you can pretty much pick and choose the best mode for each part of your application, which for me seems like nirvana. Even with static typing enabled, I find the syntax more concise and productive in Groovy than I do with Scala (I'm more experienced with Groovy so there's a lot of bias in that though).
- brikis98 14y ago
  LinkedIn has been using Grails for ~4 years. It's a terrific framework, but we found that Groovy was one of the downsides. The language is very easy to learn and use with Java, but we found that it didn't scale nearly as well to large numbers of users or developers. It's worth noting that this was pre Groovy 2.0, so I'm not sure what has changed in the latest version of the language.
  - zmmmmm 14y ago
    Thanks - that's really interesting to hear. It sounds like your use predated 2.0, at which time I would certainly have said the same thing. However static compilation (a feature of 2.0) has definitely changed my feeling about it - you're getting compile time type checking and near-Java speeds, but all the highly expressive Groovy syntax still works.
    - vorg 14y ago
      > you're getting compile time type checking and near-Java speeds The static compilation added in Groovy 2 is much faster than dynamically-compiled code but is still buggy e.g. http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei.. http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei.... It was written by one developer, and first shipped in Grails only 2 months ago, which doesn't even seem to use the static compilation features (correct me if I'm wrong). Let the Groovy/Grails developers eat their own dogfood first before recommending Groovy's static compilation to others.
johnx123-up 14y ago
Thanks for the insights. But, why not Scooter http://www.scooterframework.com/ http://www.scooterframework.com/ or ActiveWeb https://code.google.com/p/activeweb/ https://code.google.com/p/activeweb/ ? Both look quite comparable with RoR than Play!
rybosome 14y ago
Does LinkedIn make use of Play's async response features for anything public facing? That's a feature that I am very curious about.
- brikis98 14y ago
  Our Play frontends are entirely reactive/non-blocking, so yes, we're using the async features very heavily. We'll have a blog post about this in the near future. Our Play backends, if they use JDBC to talk to a database, are fully blocking, since pretty much all JDBC drivers are blocking. One of the nice things about Play is it's easy to configure the thread pool to handle this configuration as well.

smrtinsert 14y ago

Developer productivity is really broad. Can you elaborate? Most modern webapps I work on end up as json services and the backend are just java pojo services that can be unit and int tested - tdd with java is extremely fast in my experience. the whole servlets/jsp/jsf thing is dead imo, is that where you guys were losing time?

chaostheory 14y ago
If I were to guess, it would be configuration, more specifically the myriad number of choices and combinations of it. Spring's strength and weakness is the power of customizing it.
brikis98 14y ago
We had Java services that produced JSON, some that used JSPs, and a variety of others. TDD works in some cases, but if you ever wanted to do manual testing - for example, actually see the UI you were working on with real data - that meant redeploying the server after every change. Play makes this dramatically faster/easier. TDD is better with Play as well: the plugin support, strong test tools, and sbt's ~test command are amazingly productive.
- smrtinsert 14y ago
  Personally I rarely test all ui because QUnit verifies all frontend code so long as it meets the json contract. Regardless, thanks for your post, I'll give Play a go!

zmmmmm 14y ago

I'm curious if you ever evaluated Groovy? With optional static typing you can pretty much pick and choose the best mode for each part of your application, which for me seems like nirvana. Even with static typing enabled, I find the syntax more concise and productive in Groovy than I do with Scala (I'm more experienced with Groovy so there's a lot of bias in that though).

brikis98 14y ago
LinkedIn has been using Grails for ~4 years. It's a terrific framework, but we found that Groovy was one of the downsides. The language is very easy to learn and use with Java, but we found that it didn't scale nearly as well to large numbers of users or developers. It's worth noting that this was pre Groovy 2.0, so I'm not sure what has changed in the latest version of the language.
- zmmmmm 14y ago
  Thanks - that's really interesting to hear. It sounds like your use predated 2.0, at which time I would certainly have said the same thing. However static compilation (a feature of 2.0) has definitely changed my feeling about it - you're getting compile time type checking and near-Java speeds, but all the highly expressive Groovy syntax still works.
  - vorg 14y ago
    > you're getting compile time type checking and near-Java speeds The static compilation added in Groovy 2 is much faster than dynamically-compiled code but is still buggy e.g. http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei.. http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei.... It was written by one developer, and first shipped in Grails only 2 months ago, which doesn't even seem to use the static compilation features (correct me if I'm wrong). Let the Groovy/Grails developers eat their own dogfood first before recommending Groovy's static compilation to others.

johnx123-up 14y ago

Thanks for the insights. But, why not Scooter http://www.scooterframework.com/ http://www.scooterframework.com/ or ActiveWeb https://code.google.com/p/activeweb/ https://code.google.com/p/activeweb/ ? Both look quite comparable with RoR than Play!

rybosome 14y ago

Does LinkedIn make use of Play's async response features for anything public facing? That's a feature that I am very curious about.

brikis98 14y ago
Our Play frontends are entirely reactive/non-blocking, so yes, we're using the async features very heavily. We'll have a blog post about this in the near future. Our Play backends, if they use JDBC to talk to a database, are fully blocking, since pretty much all JDBC drivers are blocking. One of the nice things about Play is it's easy to configure the thread pool to handle this configuration as well.