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

121–130 of 219 posts

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

#121

Post by busterarm »

engineerDave wrote: post #120
busterarm wrote: post #109

Earlier quoted context omitted.

I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and…

Fair points all. But the breaking changes I'm referring to are items like changing method names, most likely because OCD, and helper methods, etc. While good/great tests will catch this type of stuff in your code, it will still be a lot of chasing your tail refactoring code because someone didn't like the way something was named. I see this a lot in the ruby community. Its like some sort of crazy insanity that ruby d…

Yeah changing your method names around in a publicly-exposed API that has users on an incremental release is more than a little bit belligerent.

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

#122

Post by ryanmarsh »

Many of the complaints against Rails in this HN discussion are around code base maintainability, gem proliferation, and amateurs.

Any tool that allows the rapid (almost effortless) accretion of complexity will suffer these problems. It goes with the territory.

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

#123

Post by jetheredge »

lr4444lr wrote: post #31

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…

I considered speaking to that, but then I felt like I was delving into religious arguments. My framework is more efficient than your framework! I felt it would have drawn people away from my main point, which is to think deeply about the tools you choose, and everyone needs different tools.

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

#124

Post by engineerDave »

mordocai wrote: post #101
eric_h wrote: post #94

Earlier quoted context omitted.

There's an argument to be made that Rails, by not actually enforcing conventions like TDD, gives an amateur/impatient developer a very high calibre footgun. Unfortunately, of course, that gun doesn't usually go off until it's handed to someone else.

Is there anything that actually "enforces" TDD? Because if there is I want to stay away from it.

Yes. Being forced to push changes to production with zero test coverage, and hence zero confidence in your code on a Friday night. (true story)

After that you always make sure test exist before even pondering a push of potentially breaking changes! :P

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

#125

Post by geebee »

danenania wrote: post #64

Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory. 'Tomorrow's' languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and…

I think this is a strong point. If rails is yesterday's technology, then what is today's?

To be clear, by no means am I trying to claim that Rails is the clear winner over other technology choices, or that a good answer to this question needs to be one single, unambiguous answer. I've learned a lot about other possibilities. Node of course, but it's still relatively new, and you need to prefer (or at least be ok with) javascript instead of ruby. Pheonix and Elixir sound promising. My own personal prediction (probably better to call it a suspicion, since I'm wary of predictions) is that an "isometric" approach like Volt will become more common (the approach, not necessarily that specific implementation, though it is of course a possibility as well).

But for now? Some will do this, but I wouldn't use Volt, though that has more to do with the requirements of my job than anything wrong with Volt (there really is no need for me to go so bleeding edge in what I do). I personally am hesitant to invest too much in Javascript, even on the client side, since there is still a great deal of churn. Again, this may simply not be a possibility for everyone, it depends on the kind of app you're writing.

So it's not so much that I don't see good, perhaps preferable alternatives to Rails. I just don't see a sufficiently unambiguous case that Rails is out of date to be calling it yesterday's technology - yet.

And lastly, as I mentioned in he other thread about this, when Rails isn't working for me, either because of code clarity or performance, I tend to go to older, more established technologies, not newer ones. For very elaborate sql, I use… sql, not contortions in ActiveRecord that I think are much harder to read and understand than a sql statement. I also often go to raw sql for performance reasons (mass inserts, queries that result in very large result sets that need to be optimized for speed). Unix, networking, specialized languages and environments for scientific computing, machine learning, stats, or other specialized tasks. That tends to be where I go.

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

#126

Post by jetheredge »

Benjamin_Dobell wrote: post #67

Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruc…

I've felt like any project horribly out of date is a pain to get current, Rails is no exception to that. Sure, many Rails projects have a lot of dependencies, but so do other frameworks. Sure, part of your argument is static vs dynamic, but I'm not going to join you in that argument.

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

#127

Post by spdionis »

collyw wrote: post #28
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…

Actually I would put Ruby, Python and PHP and server side JS into the same category. Need something more performant, look at C or Java. JS has it's own niche on the front end, so you don't really have a choice there. Need concurrency, look at Erlang or GO.

This. For backend applications the difference between ruby/pyhon/php is negligible. Maybe node.js is a bit different.

Don't forget about .NET along Java.

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

#129

Post by carsongross »

conradfr wrote: post #108
carsongross wrote: post #13

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 the current thick-clients-in-javascript trend cools off I think that's wishful thinking. The drawing you link is great though.

Maybe. I've been through three JavaScript hype cycles now, though, so it isn't as unlikely as a lot of folks think.

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

#130

Post by mordocai »

engineerDave wrote: post #124
mordocai wrote: post #101

Earlier quoted context omitted.

Is there anything that actually "enforces" TDD? Because if there is I want to stay away from it.

Yes. Being forced to push changes to production with zero test coverage, and hence zero confidence in your code on a Friday night. (true story) After that you always make sure test exist before even pondering a push of potentially breaking changes! :P

Oh yeah, I mean I always write tests for anything for work. I don't do TDD all the time though, sometimes I write the tests after the code. A language/framework that forced me to do TDD would just piss me off, which was my original point.
Post reply on HN