Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

codethinked.com

Post reply on HN
Print view View original

11–20 of 219 posts

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

#11

Post by emodendroket »

melling wrote: post #8
troxwalt wrote: 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".

Well, why not? "My team and I are familiar with these tools and confident that we can use them to deliver the desired result" seems like a fine reason to call something the right tool for the job.

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

#12

Post by Karunamon »

melling wrote: post #8
troxwalt wrote: 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".

Sometimes that's exactly what it means. The reason you see frameworks like Rails catching on, slow and bloated as it can be (and I say this as someone that loves the RoR ecosystem), is that developer time is generally more expensive than CPU time.

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

#13

Post by carsongross »

I've got my problems with Rails: routing is overly complicated, the asset pipeline can be tricky, and so on.

But Rails is very good at producing HTML and, in particular, partial chunks of HTML. As the current thick-clients-in-javascript trend cools off (it's happening, this was at the top of /r/webdev yesterday: https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_p...) people are going to migrate back to HTML as a transport for web apps, using libraries like http://intercoolerjs.org. (Disclosure: I developed it)

Rails is well positioned for that.

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

#14

Post by blub »

emodendroket wrote: post #9
blub wrote: 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.

With a wide interpretation of "can", the answer will be yes. But that's not a particularly interesting question to ask, as you've said it yourself. If X makes it 50% easier to create a complex product than LAMP, that's a huge difference.

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

#16

Post by mbell »

blub wrote: 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.

If there was depth, I missed it. The only two points I got from it were 'I prefer static typing over duck typing' and 'avoid dependency hell'. The original post didn't add anything new to either argument and both have existed and been rehashed over and over again for decades.

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

#17

Post by adventured »

n0us wrote: post #10

Some software does become "yesterday's software." I'm looking at you Cold Fusion, Flash, COBOL, the Abacus. I don't think Rails belongs in this group. I recognize that it's a good framework even if I don't personally like.

It's the same empty argument that started being thrown at PHP six or seven years ago. Because it's not the hot new thing, it's yesterday's software, regardless of whether it's still fully up to the task. Rails will still be going strong ten years from now without question, and there will be frequent articles proclaiming that it's terrible that whole time.

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

#20

Post by gavinpc »

blub wrote: 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 (not this OP) was clearly a response to Rich Hickey's talk "Simplicity Matters," which was given at a Ruby conference.[0] Particularly the part about "1,000 gems," which Hickey calls "hairballs" in the talk. I've started calling all packages hairballs since watching that.

[1] https://www.youtube.com/watch?v=rI8tNMsozo0&t=15m39s

Post reply on HN