Hacker News Reader

Comment by akuji1993 | Hacker News Reader

akuji1993

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

Yes there is: any JS stack.

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.

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.

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.

>Is there any competition here?

Yes. Building a responsive web application.

https://m.signalvnoise.com/program-to-where-the-performance-...

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.

>Rails has been encapsulating the best practices around server side web apps for 15 years.

Not to be pedantic, but I worked on Rails projects in 2006 and 2007, and had probably heard of it just a bit before that. This was during the initial Web 2 boom. I would not have thought that Rails was created much earlier than that, since I usually keep some track of at least major tech developments (although could be wrong, of course - I could have missed reading about it when it was created, or only first read about it after it became a bit popular). So anyway, I googled, and the Wikipedia article for Rails says:

>Initial release: 13 December 2005; 12 years ago[1]

Haven't used it lately, but I do keep reading that it is very mature and productive, as you say.

Ah, sorry. I was thinking 2003 instead of 2005.

But anyway. A long time.

React is not a stack. It's a component of a stack. Which is never the same anywhere.

http://www.rubymotion.com/

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.

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

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.

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.

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.

Well it's easy to write bad, slow Java code, not the problem of the language.

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.

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.

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.

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.

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.

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.

Hm haven’t heard about Play Framework yet thanks. I’ll check it out after I’m done with work today.

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.

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.

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

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.

Sometimes the bottleneck is your wallet.

If you can't afford to scale, then the bottleneck is your business model. Charge for your app or get funding.

Reply on news.ycombinator.com