6 ms·

There is also no tech stack in the world that will get you to rewrite your entire application faster than RoR.

by akuji1993 8y ago

sametmax 8y ago
Yes there is: any JS stack.
- 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.
- mkirklions 8y ago
  I dont have much experience, but with react native, you only need to build 1 app for iphone and android, then potentially use react for web. Is there any competition here? I could be unfamiliar with other solutions, but I thought the purpose of using JS was to eliminate re-writing code in multiple front end languages.
  - akuji1993 8y ago
    You can even go the Cordova route and just write your entire application ONCE and use it on any plattform that Cordova can compile it to. The JS hate on HN is obviously always strong, but in this case, not really justified. Ruby and RoR are slow, you can check that in any benchmark and scaling your application will become a nightmare very fast. Experienced that in projects I actively worked in where the Backend was eventually rewritten from scratch in Java.
    - realusername 8y ago
      > You can even go the Cordova route and just write your entire application ONCE and use it on any plattform that Cordova can compile it to. You can't blame Ruby for speed and talk about Cordova just after, it's a bit ironic... Cordova is one of the slowest cross-platform framework I know and that's a big reason the adoption is not going that well.
  - aantix 8y ago
    >Is there any competition here? Yes. Building a responsive web application. https://m.signalvnoise.com/program-to-where-the-performance-puck-is-going-to-be-not-where-it-has-been-2e1c89bac058 https://m.signalvnoise.com/program-to-where-the-performance-...
  - toasterlovin 8y ago
    The code for the server is different from the code for the frontend, even if they're in the same language. You're trying to do vastly different things. Front end is about user interface. Server is about controlling access to and storing data. IMO, you should use the best tool for each. Rails has been encapsulating the best practices around server side web apps for 15 years. The ecosystem is unbelievably mature and productive, regardless of whether you want to do a traditional server rendered app, or a JSON API for a JS, iOS, or Android client.
- pmontra 8y ago
  Or make it die. I had a customer with a full stack JavaScript application, coded when Angular 1 was all the rage. The development stopped, the original contractors moved to other customers. The customer wanted to resume development but after one year they're still having a very hard time finding somebody to work with such an ancient technological stack. Task one would be porting it to whatever is current today and probably rewrite substantial parts of it along the way. My bet is that either they'll spend nearly as much as they did years ago or let it die. On the other side I've got a customer which started with a Rails 2 application in 2011 and ported it with not much pain to new versions of the framework. The next one will be the jump from 4.2 to 5.2.
  - sametmax 8y ago
    That's pretty much the story of most js app i know of. Some cow boy code with "libs not framework" as a moto and has, like every cow boy, a very personnal idea of what the libs should be. Plus a few new ones because testing new toys makes like more fun. The of course, the js ecosystem being what is it, everything changes. Stuff are not compatible anymore, docs disapear, new things are hot. Mean while I have a django 1.4 project we migrated to 1.8 last year. The author was not a great dev. No tests. No docs. But it's a very stable stack, with lots of tutorials and a well integrated and compatible ecosystem. It was work, but not remotly a rewrite, and any python dev could have done it. The current JS state of things, bith technological and cultural, leans to disposable projects. The only successful JS projects i witnessed are ones from great teams. But the world is not made of mostly 10x dev.
ayb 8y ago
That is absolutely false. I've worked with large and small organizations whose whole business ecosystem is built on Rails. Including some very large publicly traded companies.
davidw 8y ago
There are tons and tons and tons of businesses out there that do not need to scale to crazy levels.
- toasterlovin 8y ago
  And even if you do need to scale, the vast majority of apps can just scale horizontally (aka, just deploy more application servers). Your bottle neck is almost always going to be your data store, not your executable code.
  - spudlyo 8y ago
    Sometimes the bottleneck is your wallet.
    - toasterlovin 8y ago
      If you can't afford to scale, then the bottleneck is your business model. Charge for your app or get funding.
thomasfedb 8y ago
Untrue. I have personally cared for several applications that have lived from Rails 2 through to 5 - and most of the code hasn't needed to be touched. Sure things change - hashrockets are out for example - and I have regexed the codebase a few times, but the core business and presentation logic has stayed the same, and the process has been fairly painless, even when skipping a version now and then.

There is also no tech stack in the world that will get you to rewrite your entire application faster than RoR.

sametmax 8y ago

Yes there is: any JS stack.

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.
mkirklions 8y ago
I dont have much experience, but with react native, you only need to build 1 app for iphone and android, then potentially use react for web. Is there any competition here? I could be unfamiliar with other solutions, but I thought the purpose of using JS was to eliminate re-writing code in multiple front end languages.
- akuji1993 8y ago
  You can even go the Cordova route and just write your entire application ONCE and use it on any plattform that Cordova can compile it to. The JS hate on HN is obviously always strong, but in this case, not really justified. Ruby and RoR are slow, you can check that in any benchmark and scaling your application will become a nightmare very fast. Experienced that in projects I actively worked in where the Backend was eventually rewritten from scratch in Java.
  - realusername 8y ago
    > You can even go the Cordova route and just write your entire application ONCE and use it on any plattform that Cordova can compile it to. You can't blame Ruby for speed and talk about Cordova just after, it's a bit ironic... Cordova is one of the slowest cross-platform framework I know and that's a big reason the adoption is not going that well.
- aantix 8y ago
  >Is there any competition here? Yes. Building a responsive web application. https://m.signalvnoise.com/program-to-where-the-performance-puck-is-going-to-be-not-where-it-has-been-2e1c89bac058 https://m.signalvnoise.com/program-to-where-the-performance-...
- toasterlovin 8y ago
  The code for the server is different from the code for the frontend, even if they're in the same language. You're trying to do vastly different things. Front end is about user interface. Server is about controlling access to and storing data. IMO, you should use the best tool for each. Rails has been encapsulating the best practices around server side web apps for 15 years. The ecosystem is unbelievably mature and productive, regardless of whether you want to do a traditional server rendered app, or a JSON API for a JS, iOS, or Android client.
pmontra 8y ago
Or make it die. I had a customer with a full stack JavaScript application, coded when Angular 1 was all the rage. The development stopped, the original contractors moved to other customers. The customer wanted to resume development but after one year they're still having a very hard time finding somebody to work with such an ancient technological stack. Task one would be porting it to whatever is current today and probably rewrite substantial parts of it along the way. My bet is that either they'll spend nearly as much as they did years ago or let it die. On the other side I've got a customer which started with a Rails 2 application in 2011 and ported it with not much pain to new versions of the framework. The next one will be the jump from 4.2 to 5.2.
- sametmax 8y ago
  That's pretty much the story of most js app i know of. Some cow boy code with "libs not framework" as a moto and has, like every cow boy, a very personnal idea of what the libs should be. Plus a few new ones because testing new toys makes like more fun. The of course, the js ecosystem being what is it, everything changes. Stuff are not compatible anymore, docs disapear, new things are hot. Mean while I have a django 1.4 project we migrated to 1.8 last year. The author was not a great dev. No tests. No docs. But it's a very stable stack, with lots of tutorials and a well integrated and compatible ecosystem. It was work, but not remotly a rewrite, and any python dev could have done it. The current JS state of things, bith technological and cultural, leans to disposable projects. The only successful JS projects i witnessed are ones from great teams. But the world is not made of mostly 10x dev.

ayb 8y ago

That is absolutely false. I've worked with large and small organizations whose whole business ecosystem is built on Rails. Including some very large publicly traded companies.

davidw 8y ago

There are tons and tons and tons of businesses out there that do not need to scale to crazy levels.

toasterlovin 8y ago
And even if you do need to scale, the vast majority of apps can just scale horizontally (aka, just deploy more application servers). Your bottle neck is almost always going to be your data store, not your executable code.
- spudlyo 8y ago
  Sometimes the bottleneck is your wallet.
  - toasterlovin 8y ago
    If you can't afford to scale, then the bottleneck is your business model. Charge for your app or get funding.

thomasfedb 8y ago

Untrue. I have personally cared for several applications that have lived from Rails 2 through to 5 - and most of the code hasn't needed to be touched. Sure things change - hashrockets are out for example - and I have regexed the codebase a few times, but the core business and presentation logic has stayed the same, and the process has been fairly painless, even when skipping a version now and then.