Today I accept that Rails is yesterday’s software
1–10 of 166 posts
Re: Today I accept that Rails is yesterday’s software
#2So, Rails has warts. What system that is used to build real world software doesn't? I've built systems in a number of languages and frameworks and they all had warts and issues.
How much research has the author done to find other solutions? The plea at the end seemed very lazywebish to me. Or maybe ghost of Christmas Future-esque?
Re: Today I accept that Rails is yesterday’s software
#3The article seems to be lamenting three things:
1) Batteries-included web frameworks (like Rails and Django)
2) Interpreted languages without strict typing (like Ruby and Python)
3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and the resulting difficulty in reasoning about the software
The last paragraph then goes on to suggest that different languages are required. This seems wrong. If you want to write web software you can reason about, you can still use web frameworks (maybe Flask or Sinatra) and you can still use third party packages (gems or things from pypi).
If you import a library (left pad or whatever) and call it from your code, then you can still reason about what's going on. The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running.
Re: Today I accept that Rails is yesterday’s software
#4I agree with some of the issues that the author points in Rails; but, at the same time, he is unable to name what is "today's software" using his words. Until then, I will stay with Rails. Until then.
Moreover, the author seems to be imagining Rails as a huge monolithic piece of software. That does not need to be true.
Re: Today I accept that Rails is yesterday’s software
#5Being "yesterday's software" is a necessary step. It's the final part of the Gartner hype cycle: maturity.
https://speakerdeck.com/tehviking/surviving-the-framework-hy...
Re: Today I accept that Rails is yesterday’s software
#6I was dubious when I saw the Medium.com tld and a clickbaity title but it actually puts word on what I feel after 16 (ouch) years of web development. The difference was that I was blaming the tools and screaming "#fail" with the other rather than thinking like the author that we're in a conceptual dead-end (at least with popular tools).
Re: Today I accept that Rails is yesterday’s software
#7I agree with some of the issues that the author points in Rails; but, at the same time, he is unable to name what is "today's software" using his words. Until then, I will stay with Rails. Until then. Moreover, the author seems to be imagining Rails as a huge monolithic piece of software. That does not need to be true.
Doesn't the author end by saying Swift, Rust and Go are "tomorrow's languages"?
Re: Today I accept that Rails is yesterday’s software
#8While it's true that Rails is sinking under the weight of its own cleverness, and is clearly the old hotness, this has nothing to do with Ruby the language.
Rails' problems are its own, and Ruby's limitations and problem domain are well known.
This is a terrible blog post by someone without much perspective. I award it no stars.
Re: Today I accept that Rails is yesterday’s software
#9I…don’t understand the point of the article? Ok Ruby is duck typed and has a dynamic runtime. It has for…all of the time since it was created. Rails has magic… since…all of the time since it was created.
I’m not even defending Ruby or Rails here. Use at your own benefit/risk…as with every other programming language and framework.
Re: Today I accept that Rails is yesterday’s software
#10While I agree with many of the individual points he makes (rails dev myself), I think there is a kind of fundamental issue there that we have seen with most web framework/language combinations and will see with future ones, and that is that they usually come to life when one concept or idea they embody the best (for example mvc for crud apps with Rails, frontend/backend unification with node, native concurrency with Erlang, puristic http for microservices with Go) is becoming prevalent at some point, and then people put stuff on top of stuff which they put on top of other stuff, and then they realize that the problem they still have to solve is good architecture. And they need to balance that with business needs and developer availability.
I don't think any of that is going to change by switching to the next fashionable concept to base a web app on.