4 ms·

Lol. Use a Java backend, that's performant and solid so it can scale beyond a million subscribers easily and write the Frontend in a framework like Angular/Reac

by akuji1993 8y ago

Lol. Use a Java backend, that's performant and solid so it can scale beyond a million subscribers easily and write the Frontend in a framework like Angular/React/Vuejs and I see no reason why I would want a Rails app instead.

neverminder 8y ago
Agree. Incidentally Play Framework that supports both Java and Scala was modeled after RoR, so you get both convenience of fast prototyping and the power of the JVM at the same time.
- akuji1993 8y ago
  Hm haven’t heard about Play Framework yet thanks. I’ll check it out after I’m done with work today.
- kazagistar 8y ago
  Speaking of having to rewrite your entire application, play framework has changed how it interops with DI and a number of other significant details every single minor release, forcing significant changes to update versions frequently. We were pretty gung ho about it at first, but basically all our engineers have burned out on it and we are going so far as to embrace the relative stability and, dare I say, simplicity of spring-boot. It's possible that for Scala development it is a fairly good option, and some of the pieces like the typesafe config library are pretty nice, but at this point we consider play to be more like a curse word representing incompatible inflexible garbage.
  - vvillena 8y ago
    That's because they are not minor releases. Play seems to follow the Scala style version numbering (epoch.major.minor). In any case, I'm with you in that some of the changes between major versions they did were painful, especially if the code was structured in certain ways.
- vvillena 8y ago
  Having used both Play (with Scala) and Rails to create some APIs in a professional environment, there's no competition. Play is extremely robust and quite featured, but Rails development speed is much much faster. Rails is extremely opinionated, but you can learn from every choice the framework made and apply it elsewhere. Play is much more freely structured, which is a double-edged sword. If I had to create a new API from zero, I'd go with Rails.
  - neverminder 8y ago
    You may be able to go faster with Rails, but scalability is where Play would blow it out of the water. If suddenly tomorrow my Play services get hit with 100 times the usual user number I wouldn't even notice.
    - vvillena 8y ago
      It's the old tradeoff: dev speed vs performance. I just prefer to go with the tech stack that I feel makes me more agile, more capable of changing direction if need be. Both points of view are valid, of course.
baron816 8y ago
I work for a company with a Java backend and no one has ever accused us of being fast. Worse is that development on the backend is so slow that small, competing startup have been able to build out 5x more features (and more useful features at that) than us, leaving us in the dust.
- neverminder 8y ago
  There are modern JVM backends for fast prototyping (Play, Akka-http, etc) and if you use them with Scala for instance your testing surface will be a lot smaller compared to dynamically typed languages due to strict typing.
- akuji1993 8y ago
  Well it's easy to write bad, slow Java code, not the problem of the language.

neverminder 8y ago

Agree. Incidentally Play Framework that supports both Java and Scala was modeled after RoR, so you get both convenience of fast prototyping and the power of the JVM at the same time.

akuji1993 8y ago
Hm haven’t heard about Play Framework yet thanks. I’ll check it out after I’m done with work today.
kazagistar 8y ago
Speaking of having to rewrite your entire application, play framework has changed how it interops with DI and a number of other significant details every single minor release, forcing significant changes to update versions frequently. We were pretty gung ho about it at first, but basically all our engineers have burned out on it and we are going so far as to embrace the relative stability and, dare I say, simplicity of spring-boot. It's possible that for Scala development it is a fairly good option, and some of the pieces like the typesafe config library are pretty nice, but at this point we consider play to be more like a curse word representing incompatible inflexible garbage.
- vvillena 8y ago
  That's because they are not minor releases. Play seems to follow the Scala style version numbering (epoch.major.minor). In any case, I'm with you in that some of the changes between major versions they did were painful, especially if the code was structured in certain ways.
vvillena 8y ago
Having used both Play (with Scala) and Rails to create some APIs in a professional environment, there's no competition. Play is extremely robust and quite featured, but Rails development speed is much much faster. Rails is extremely opinionated, but you can learn from every choice the framework made and apply it elsewhere. Play is much more freely structured, which is a double-edged sword. If I had to create a new API from zero, I'd go with Rails.
- neverminder 8y ago
  You may be able to go faster with Rails, but scalability is where Play would blow it out of the water. If suddenly tomorrow my Play services get hit with 100 times the usual user number I wouldn't even notice.
  - vvillena 8y ago
    It's the old tradeoff: dev speed vs performance. I just prefer to go with the tech stack that I feel makes me more agile, more capable of changing direction if need be. Both points of view are valid, of course.

baron816 8y ago

I work for a company with a Java backend and no one has ever accused us of being fast. Worse is that development on the backend is so slow that small, competing startup have been able to build out 5x more features (and more useful features at that) than us, leaving us in the dust.

neverminder 8y ago
There are modern JVM backends for fast prototyping (Play, Akka-http, etc) and if you use them with Scala for instance your testing surface will be a lot smaller compared to dynamically typed languages due to strict typing.
akuji1993 8y ago
Well it's easy to write bad, slow Java code, not the problem of the language.