The author leaves the business needs completely off the table, even though it would help his case. If you have a limited amount of time to launch your product in your current round of funding, and you want a framework that helps a small number of tech employees build working first generation critical features reasonably quickly, handle a large number of tasks not critical to the company's value proposition reasonably well, can be maintained and scaled on a variety of PaaS options well long enough until the company is profitable enough to move to the next phase of tech infrastructure, is Rails attractive software? I'm not an expert with it, and I don't even enjoy using it, but I believe it is.
After reading “Rails is yesterday’s software”, I need to reply
31–40 of 219 posts
Re: After reading “Rails is yesterday’s software”, I need to reply
#32Some 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.
Interesting comment; I believe if you are going to implicate Cold Fusion, you also need to rope in PHP.
My first exposure to web programming was HTMLScript at my university in the mid 90s (now called MivaScript and is the language used to build the MivaMerchant product). Soon after, I switched to PHP 3, but I found that I preferred Miva.
I have not touched Miva in years after spending some time as a freelancer in the late 90s, but because it is tied to a successful niche e-commerce platform, the language survives. It is very similar to Cold Fusion minus the enterprise level database support.
I worked with CF for a time in the late 90s/00s (when it was still a product of Allaire) along side of ASP (pre .net), and I actually preferred it to both ASP and PHP - mainly because the mixing of mark up and DSL blocks seemed really unscalable.
PHP may have been seen as an evolution in web programming since it abstracted the mixing of logic and presentation a bit more than Miva or CF, but in retrospect I believe PHP was not an improvement. It made general web programming easier, but software maintenance is easier in languages like CF and Miva that embrace embedded mark up/logic.
The frameworks provided by Ruby, Python, Perl, and even TCL (among others) seem to have reached a point where only blurring the lines between client and server seem like the only logical paradigm change - and that's not to say it's an improvement.
Re: After reading “Rails is yesterday’s software”, I need to reply
#33I'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…
What makes you think that being able to produce HTML is such an important piece, and that Raila delivers better than most other frameworks?
Re: After reading “Rails is yesterday’s software”, I need to reply
#34This 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.
And he didn't point out how any of his "todays languages" are any better at avoiding dependency hell.
Re: After reading “Rails is yesterday’s software”, I need to reply
#35This 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…
Rails codebases do not age well, and are always unpleasant to work on. I never saw the same issue with django codebases of a similar age. Nor even ones from Perl or PHP frameworks either. No. It is a special combination of the shiny insecure magic of Rails, mixed with the happy meal mentality and abilities of most Rails developers.
The last two codebases I have inherited in Python have been fairly poor. And the Java ones before that. I don't think its a language specific thing.
Re: After reading “Rails is yesterday’s software”, I need to reply
#36Earlier quoted context omitted.
"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.
They aren't the same thing but there's basically no room between "these are the tools I know"-thinking and "if all you have is a hammer"-thinking.
Freely admit this is somewhat irrelevant though as most languages are the difference between a felling-ax and a splitting-ax or two sizes of screwdriver, as opposed to hammer vs drill.
Re: After reading “Rails is yesterday’s software”, I need to reply
#37Fully 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 th…
Definitely!
Re: After reading “Rails is yesterday’s software”, I need to reply
#38Author is being nice, but I'm happy to point out that author of replied-to post is revealing they are a frustrated novice. All the focus on "Rails made programming cool" tells me "I do things for dumb reasons." Clear case of chasing the dragon.
Aren't most if not all Rails programmers just chasing shiny magic features? Rails programmers tend to be like a McDonald's happy meal - uninspired, fills a hole, make do.
Haha perhaps.
/me is a Rails programmer, a lot of the time.
Re: After reading “Rails is yesterday’s software”, I need to reply
#39Great 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".
The problem is more that writing a post that is a list of if you have problem X use solution Y is a nonstarter. People like different things, have different skill sets, and are dealing with a different set of requirements. Finally, it is the sort of thing you would have to keep up to date with the latest version of every framework, language, and OS.
To discuss by means of example, lets talk about floors.
You decide to redo the floor in your place of residence. Do you:
0. Hire it out, using a cheap contractor
1. Hire it out, use a vendor in the middle of the quality/cost curve
2. Hire it out, using the classiest floor shop in town
3. Do it yourself, using a rental sander and a youtube video for training, sand your floors down and refinish using stain the guy at Home Depot recommended
4. Do it yourself, tear the floors out and replace them from the beams up using reclaimed lumber from the local artists collective.
5. Do it yourself, linoleum is fast to install, looks okay, and its super cheap.
6. Do it yourself, spend 6 years learning carpentry from a master artisan in the wilds of Scandinavia, fell your own timber using an axe you made yourself, assemble the timber into the master work of flooring using expensive danish hand.
Personally I try to do #1 for floors and #4 for software but that doesn't meant that works for you. If you have already done the first half of #6 I would be temped to just go all the way.
That said if someone gets bored we could do a sort of survey on a timed basis and rate different tools for different strengths ans weaknesses. Something where you could be like "optimize speed of development versus XML Parsing Quality" and it would give you a nice chart as long as you provide a few quick survey answers.
Might Give writing it a try later on. would be interesting to see what metrics people cared about.
Re: After reading “Rails is yesterday’s software”, I need to reply
#40This 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…
can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript? They absolutely can be built using just Rails (or python) and HTML. I won't shill any harder about how, but it's not only possible, it's enjoyable and easy. I've done it.
Claiming it is easy is probably bit of a stretch. I can't imagine any large-scale web app or native desktop app being easy to implement, regardless of the tools.