4 ms·

> The productivity of Rails absolutely trounces JS-framework-de-jour in my experience. It’s almost certainly the framework I would be recommending for a CRUD ap

> The productivity of Rails absolutely trounces JS-framework-de-jour in my experience. It’s almost certainly the framework I would be recommending for a CRUD app, which covers the vast majority of business software. Rails is certainly productive in the early days of building something, because so much of what you need is already built. But as time goes on that productivity edge vanishes. It's far easier to build slick modern UIs in other frameworks, and there are now Typescript frameworks (e.g. Remix) where you can use the same types (and get type safety, IDE auto-completion, IDE warnings, etc.) across the entire stack (it's amazing!) The fact you don't need import statements to use code across a Rails app feels like a blessing at the start, but as the codebase grows, it can become a nightmare trying to figure out where something is defined or how something has been altered. The lack of typing leads to way more maintenance - I have Rails apps that are years old and I still get regular error notifications (method doesn't exist on nil is a particularly common one) whereas I have Typescript apps that I built a few months ago that have never triggered an error ever. The list goes on. The world turns, frameworks come and go, and the heyday of Rails is over. I don't know why this is a problem for people, quite frankly. If you didn't want to learn new things, then being a software developer wasn't the right career choice, and you were probably told that on day 1!

danmaz74 3y ago
Isn't remix just dealing with view and controller of MVC? That looks difficult to compare with Rails
- deleted 3y ago
  [deleted]
- 3c6bYDXLMj 3y ago
  Okay, so Remix and some persistence layer. What’s the point?
3c6bYDXLMj 3y ago
Implying that anyone touting the benefits of an established technology is against learning is just intellectually dishonest. Being able to tell what is and what is not worth looking further into is a mark of a seasoned expert in any field.
- arp242 3y ago
  And most of the newer things are more or less the same thing as the old, except different. Sometimes that's good, sometimes it's not, and often it either depends or doesn't actually matter all that much. The trade-offs are often different, but it's of course fanatically denied by the zealots who claim that the trade-off doesn't even exists in the first place.
DoesntMatter22 3y ago
It's comical to say that Rails heyday is over when Remix hasn't even had a heyday. The half life of these backend frameworks is pretty short. Rails has built a lot of billion dollar businesses. Wake me up when Remix does that.
shotmoon 3y ago
> The world turns, frameworks come and go, and the heyday of Rails is over. I don't know why this is a problem for people, quite frankly. If you didn't want to learn new things, then being a software developer wasn't the right career choice, and you were probably told that on day 1! Nobody asked your opinion on who could be a software developer. Stop being a gate keeper and let people make their choice on what technology works for them.
realusername 3y ago
> The lack of typing leads to way more maintenance Surely you are joking, maintenance is THE downside of the node ecosystem if I had to pick the biggest one. At work we have a roughly 50/50 Rails/React app but on the maintenance side though it's 20% Rails / 80% React. The package churn in the node ecosystem is absolutely insane and just keeping up with it is almost a full time job. And to add even more to the maintenance burden, on the node world the packages are rarely tested well (if at all), you are building on moving sand and theoretically you would need even more testing than in the Rails part to compensate that. I'm not saying Rails has the best maintenance story, far from it but it's not nearly as bad as anything JS based.
JohnBooty 3y ago
The fact you don't need import statements to use code across a Rails app feels like a blessing at the start, but as the codebase grows, it can become a nightmare trying to figure out where something is defined or how something has been altered Are you willing to share examples? I was a Rails developer for a long time and it certainly has its pitfalls. But I don't feel that this was one of them and I certainly don't think that explicit imports would solve this problem for you. Do you have a bunch of global variables (or external data stores like Redis caches etc) being modified by only-God-knows-what? I don't know how explicit imports would solve that. I'm not sure how "import Foo" versus "Foo=42" is going to help you, unless perhaps if you've given your global thing an identifier that is impossible to grep for. You can also have the behavior you want in Rails, anyway! You have full control over autoloads! Put your code in a non-autoloaded folder. Boom, now you have to explicitly `require` it before using it. The lack of typing leads to way more maintenance - I have Rails apps that are years old and I still get regular error notifications (method doesn't exist on nil is a particularly common one) Static typing isn't your answer. Unexpected nils/nulls/whatever are a runtime error, and are almost always caused by some external resource (typically, the results of a database query or maybe an external API call) being unexpectedly nil, coupled with a sloppy lack of proper exception handling. I don't care how iron-clad your language's type system is, it won't magically help you handle unexpected external runtime data or make up for a lack of exception handling and/or testing.

danmaz74 3y ago

Isn't remix just dealing with view and controller of MVC? That looks difficult to compare with Rails

deleted 3y ago
[deleted]
3c6bYDXLMj 3y ago
Okay, so Remix and some persistence layer. What’s the point?

3c6bYDXLMj 3y ago

Implying that anyone touting the benefits of an established technology is against learning is just intellectually dishonest. Being able to tell what is and what is not worth looking further into is a mark of a seasoned expert in any field.

arp242 3y ago
And most of the newer things are more or less the same thing as the old, except different. Sometimes that's good, sometimes it's not, and often it either depends or doesn't actually matter all that much. The trade-offs are often different, but it's of course fanatically denied by the zealots who claim that the trade-off doesn't even exists in the first place.

DoesntMatter22 3y ago

It's comical to say that Rails heyday is over when Remix hasn't even had a heyday. The half life of these backend frameworks is pretty short. Rails has built a lot of billion dollar businesses. Wake me up when Remix does that.

shotmoon 3y ago

> The world turns, frameworks come and go, and the heyday of Rails is over. I don't know why this is a problem for people, quite frankly. If you didn't want to learn new things, then being a software developer wasn't the right career choice, and you were probably told that on day 1! Nobody asked your opinion on who could be a software developer. Stop being a gate keeper and let people make their choice on what technology works for them.

realusername 3y ago

> The lack of typing leads to way more maintenance Surely you are joking, maintenance is THE downside of the node ecosystem if I had to pick the biggest one. At work we have a roughly 50/50 Rails/React app but on the maintenance side though it's 20% Rails / 80% React. The package churn in the node ecosystem is absolutely insane and just keeping up with it is almost a full time job. And to add even more to the maintenance burden, on the node world the packages are rarely tested well (if at all), you are building on moving sand and theoretically you would need even more testing than in the Rails part to compensate that. I'm not saying Rails has the best maintenance story, far from it but it's not nearly as bad as anything JS based.

JohnBooty 3y ago

The fact you don't need import statements to use code across a Rails app feels like a blessing at the start, but as the codebase grows, it can become a nightmare trying to figure out where something is defined or how something has been altered Are you willing to share examples? I was a Rails developer for a long time and it certainly has its pitfalls. But I don't feel that this was one of them and I certainly don't think that explicit imports would solve this problem for you. Do you have a bunch of global variables (or external data stores like Redis caches etc) being modified by only-God-knows-what? I don't know how explicit imports would solve that. I'm not sure how "import Foo" versus "Foo=42" is going to help you, unless perhaps if you've given your global thing an identifier that is impossible to grep for. You can also have the behavior you want in Rails, anyway! You have full control over autoloads! Put your code in a non-autoloaded folder. Boom, now you have to explicitly `require` it before using it. The lack of typing leads to way more maintenance - I have Rails apps that are years old and I still get regular error notifications (method doesn't exist on nil is a particularly common one) Static typing isn't your answer. Unexpected nils/nulls/whatever are a runtime error, and are almost always caused by some external resource (typically, the results of a database query or maybe an external API call) being unexpectedly nil, coupled with a sloppy lack of proper exception handling. I don't care how iron-clad your language's type system is, it won't magically help you handle unexpected external runtime data or make up for a lack of exception handling and/or testing.