Live data from Hacker News

After reading “Rails is yesterday’s software”, I need to reply

codethinked.com

1–10 of 219 posts

Re: After reading “Rails is yesterday’s software”, I need to reply

#2
Reposting a reply I put on the original submission, but pertinent here as well:

Use whatever tools/framework you want. Whatever it is you use, you will eventually become [the original] OP. The reality is that every language/framework has warts. As you use it and get deeper into it, you will uncover these warts. Eventually, all you can see is the warts.

It's important to take a minute every once in a while and look at the thing you built from a user's perspective. See what problem you've solved for people, or just what cool new thing you've built. Staring at a bug backlog and a mountain of tech debt will always get you down about your project, but that's the reality of programming...bugs and tech debt.

Re: After reading “Rails is yesterday’s software”, I need to reply

#6
This is the old "use the right tool for the job" cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript?

Or do we need an entire new class of tools which have traditionally been used to build large scale systems in the past?

It's a multi-faceted question of type systems, tooling, packaging, dependency resolution and others. And as web apps continue to evolve, my guess is that the current tools will be considered lacking.

It used to be that picking "the right tool" meant choosing between Ruby, Python, PHP, JS. In the future it might mean using (gulp) Java + WebAssembly or a combination of other unusual tools. This would be quite game-changing for most web developers. ;)

Re: After reading “Rails is yesterday’s software”, I need to reply

#7
post #4

Fully agree with the post. Any time you're making decisions based on some dogma versus 'what is the best way to solve my current problem' you aren't guaranteeing an optimal solution.

Depending on the project, I think you have to give weight to long-term maintenance and on going development as well. If you're building SASS software that people use daily and may be in the market place for a long time, you'll need to balance both solving today's problems with being able to meet the future.

It's possible in this scenario, going with a proven solution like Rails me be it. I just wanted to point out that our solutions sometimes have to consider future considerations as well or have to consider continual development of a legacy product. Sometimes developers consider only whats best in the moment, and that has negative long-term consequences.

Re: After reading “Rails is yesterday’s software”, I need to reply

#8
post #5

Great follow up article. Choose the right tool for the job.

"Choose the right tool for the job"

What exactly does that mean? It's a vague response that people have used for years when they don't want to explain why they chose a particular tool. In my experience, many developers take the path of least resistance and use what they are comfortable with and that's why "it's the right tool for the job".

Re: After reading “Rails is yesterday’s software”, I need to reply

#9
post #6

This is the old "use the right tool for the job" cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? Or do we need an entire new class of tools which have traditionally been used to build large scale systems in the past? It's a multi-faceted question of type systems, toolin…

> The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript?

Well, clearly they can, because lots of people are doing it. Maybe some other tools would make it easier than it is now but it is certainly possible now.

Post reply on HN