Ask HN: In 2016, will Rails & Django be competitive against newer technologies?

[notwhyships]

Do you think Rails and Django (and the like) will evolve to remain competitive with newer technologies like Node.js, Meteor, Play, etc (not to mention, whatever's next)? Or will they largely be legacy technologies, i.e. still in wide-use but not frequently selected for the best new projects?

Edit: Please note that the question is not whether or not Rails and Django developers will still be in demand in 2016. I'm confident they will be. The question is will the best new projects in 2016 consider using Rails and Django.

[quaunaut]

Note, I'm a complete newbie. I spent 12 months doing a Django job, and started a Rails job about ~4 months ago. Before that I followed frameworks but wasn't nearly as engaged.

The impression I get, is that in general, these languages and frameworks will age, get boring, and eventually be something used because of legacy, the existing codebases. Is this bad? Of course not! It means there will always be a wealth of well-documented, high quality software to work with.

But really, the only way to fight off not being 'boring' is by trying to always do the brand new technologies, always having a way of implementing them. Rails with Turbolinks, to pseudo-mimic frontend JS frameworks. Rails also implementing server side events, moving web sockets closer to 'the norm'.

Will they still be the hot go-to languages/frameworks 5-10 years from now? Probably not. Rails will probably feel then like PHP does now('old and safe', with better options available for most cases), and something like Go or some other incredibly thin means of maintaining a backend API to facilitate frontend Javascript frameworks. And after that, who knows. Maybe the web as pages will die 10-15 years from now, instead being replaced by something more akin to a pluggable game or OS engine. Maybe holograms. Maybe we just get robots and call it a day.

[mattmcknight]

PHP does not feel "old and safe". It's probably not the right comparison point to Rails, which is more like CakePHP or Symfony, or the various frameworks influenced by Rails.

Having worked on Rails since 2005, I think the bigger problem is that it has become more complex, and harder to get started with, as the pendulum swings from eliminated.

One bigger change is probably as you state, that we will get away from frameworks whose primary responsibility is generating HTML, which affects all of these things similarly, and node.js would get caught up in the same thing.

Another big change is the pendulum swing from Object/Relational systems to Functional/BigData systems. This is a big mental shift for programmers trained in the Object-Oriented approach.

[dpritchett]

I enjoy the Indeed.com job trends for this sort of thing: http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+n...

I'm a Ruby/Rails developer (and I run MemphisRuby) and while I seriously enjoy working with Rails I don't expect it to be as popular ten years from now.

Rails is still tremendously good at what it does and I don't think it's likely that another framework or language is going to beat it at its own game. The real question is whether or not the things that Rails does best will continue to be important in the marketplace.

We've already seen parts of Rails's core competencies carved out by other tools: Erlang/Node/Go enable saner async programming. Backbone/Angular/Ember enable rich web applications. Scala/Clojure/Go/etc. on the "fast compiled backend services" front. Even PHP is keeping pace with the times (Composer, Laravel) just enough to keep its adherents from having a real reason to jump ship.

Ruby and Rails are still pretty much as good as it gets for rapid development of web applications (the backend parts of MVC, anyway), and there's a growing Ruby niche for configuration management (Chef, Puppet, etc).

Personally I find my investment in learning and working with Ruby has been a great way for me to experience a much wider variety of technologies and architectures than I would have otherwise. Thanks to Rails work I've learned tons about AMQP, Postgres, Chef, Backbone, JavaScript, CSS, Ansible, DNS (bind), and more that I just wouldn't have had the same exposure to in a slower-paced development environment.

Your ending line about "still in wide use but not frequently selected for the best new projects" is a bit complicated. Certainly any language stays in wide use once it falls out of fashion and its projects categorically move to the "legacy" phase, but "best new projects" is a bit much. A lot of what we might think of as the 'best' projects are driven by fashion just as much as technical merits.

[rahoulb]

I think that's the key. I can't imagine much being better at Request/Response MVC-style CRUD apps than Rails (can't speak for Django).

But the question how much demand will there be for that style of app in the future?

In a similar manner, I was asked the other day if I still did any Delphi development - for the first time in about eight years. Delphi was a best-of-class tool in its day, but there just isn't the same demand for database-driven desktop Windows apps any more.

[ThomPete]

+Java (dwarfs the others)

http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+n...

[acron0]

http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+n...

;)

[ThomPete]

http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+n...

ruby, python, php, node, java, .NET, c

:)

[dpritchett]

http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+n...

You forget how many people get paid to specialize in Excel :)

[acron0]

Haha, okay you win.

[bayesianhorse]

With the risk of starting a flame war, what exactly makes Rails inherently better than Django in standard web applications? If Rails is not better in performance, elegance and rapid development, what then?

[dpritchett]

I didn't mean to imply that Rails was better than Django. I said that nothing beats it! Each offers some conveniences out of the box that the other doesn't. I wouldn't recommend you switch languages just to get Rails over Django or vice versa.

[mountaineer]

For an HN Job trends view, I created a simple trends chart and leaderboard[1]

The shift to front-end dev with Backbone and Angular is an important insight, as server-side frameworks may dumb down over time and/or be replace by pure data access like Parse.

http://www.ryan-williams.net/hacker-news-hiring-trends/

[the1]

http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+n...

so, scala

[laureny]

That's a misleading graph, you switched it to relative values, which is meaningless.

Here is the same graph with absolute values, which shows that Scala is completely invisible compared to the competition:

http://www.indeed.com/jobanalytics/jobtrends?q=ruby%2C+pytho...

[gremlinsinc]

Interesting - it looks like Python is the dog to beat--which actually surprises me - especially that it beats PHP and php is on a downward trend. AS much buzz as Ruby on Rails gets, I'd think it would be going up and up. Personally I like them all -- I use them all -well not so much Django(yet) but will in the near future. I like to rotate frameworks when building stuff, it gives me more experience and it doesn't hurt to be well rounded. Currently though I'm using Laravel and it's the ONLY thing keeping me in the php world.

[tambourine_man]

+ ObjC. Amazing.

http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+n...

[ludicast]

Yes and no. I think:

1) Rails (I don't know Django) will continue to be the quickest way to have a quick full-stack demo/MVP. It is opinionated, and has tools like railsapps that let you customize it. So you can have a solution that includes bootstrap, authentication, stripe-payments, etc., almost completely out of the box.

2) Rails will continue to be plagued with the problems (security, slow dynamic language) etc. but it will always have workarounds like jruby, celluloid, rails-api, in-memory-models (I wish this was more common). The community is vibrant enough to keep plugging along and fixing the gaps.

3) I don't think it's a coincidence that the two most influential frameworks (Rails and Sinatra) were written in Ruby.

4) Eventually people's MVP will move to something like Scala, following the example of Twitter and LinkedIn. Static languages that encourage functional behavior improve speed and safety.

5) Play is interesting. I am checking it out now, and seeing how I can move a rails app to it.

6) Node serves the lowest-common-denominator in my opinion (it caters to non-polyglots). I use it for certain things (a workflow for prototyping phonegap apps, and client-side tooling) but I personally think it is way overhyped. However it definitely has a place, and will continue to have one.

7) If Rails does someday "die" that's okay for dhh's legacy. His framework is spiritually part of whatever comes next and raised the bar as much as Seinfeld did for television.

[Herald_MJ]

> the two most influential frameworks (Rails and Sinatra)

You admit that you're a Ruby developer, so you must see that this is slightly blinkered. Influential on what? There's not much Rails brought to the table which was entirely unique, it was just a very good MVC framework in a pleasant language that came along at the right time. And lets not forget that development on Django (which was also very influential), began long before Rails appeared on the scene.

Sinatra I've only heard of in passing, but in the Python world, web.py, Tornado and flask have been also been very significant.

[dragonwriter]

> You admit that you're a Ruby developer, so you must see that this is slightly blinkered. Influential on what?

On frameworks in other languages, both in terms of design/motivation and expectations; one indication of this is the frequency of phrases like "sinatra style framework" or "rails style framework" to either (a) describe an existing web framework for a different langauge, or (b) describe what someone is looking for in a web framework in a different language.

I'm not sure I've ever seen the same thing with Django, web.py, or Tornado. I've seen it with Flask, but its been basically a subset of the times I've seen it with Sinatra (that is, I've seen things like "Sinatra-style framework" and "Flask/Sinatra-style framework", but not "Flask-style framework" on its own.)

[Herald_MJ]

I've heard "Rails style" about as frequently as I've heard "Django style".

I've never heard "Sinatra style". In fact, when someone first mentioned Sinatra to me, they explained it as "like a web.py style microframework, for Ruby". This was a conversation between two Python developers though, so it makes sense we'd be more familiar with the Python ecosystem. But that's as much a Python-centric bias as your original comment seemed Ruby-centric bias.

Incidentally, I don't think Flask has all that much in common with Sinatra.

[ashray]

Rails and Django have moved from the obscure into the mainstream. 5 years ago if you wanted to hire a Django developer it was pretty hard. It's still way harder to find Django developers compared to PHP devs.

As a company, if you push yourself into a corner with newer tech like Node, Meteor, etc. you may come up against hiring issues. Not only that, but Rails and Django are also evolving with time so they too get better with time.

The "age" of a technology isn't the only reason why it gets selected, it gets selected because of a number of factors including features, programmer availability, programmer expenses (in terms of both time and skill), proven track record, etc. Usually age is a plus point in many ways.

Rails and Django will certainly be around and competitive. However, if you're asking from a programmer salary perspective then yes, there will be many more Rails and Django programmers by 2016, so moving into more edgy tech might give you a USP, but you may also end up without a place to work in. Maybe knowing Rails/Django + "shiny new tech" is a better combo ?

[laureny]

> Rails and Django have moved from the obscure into the mainstream.

For prototyping, maybe (and even that is arguable).

In practice, I see a lot more companies moving away from these frameworks toward JVM-based frameworks than the other way around.

These frameworks simply don't scale past the size of a small project.

[brnlsl]

Built with Rails: Github, Groupon, YellowPages, BaseCamp, Scribd, Shopify, Posterous, Airbnb, Urban Dictionary, Bleacher Report, Kickstarter...

These are not small projects.

[bjt]

> These frameworks simply don't scale past the size of a small project.

That is incorrect. From the Django side, see Instagram (http://instagram-engineering.tumblr.com/post/13649370142/wha...) and Disqus (http://blog.disqus.com/post/62187806135/scaling-django-to-8-...).

[mattmcknight]

Django and Rails both run on the JVM. Both have scaled to massive projects, even without the JVM.

[etchalon]

Play doesn't belong in that list (it's really just a Java-version of the basic request/response cycle design that plagues Django and Rails, Scala or not).

Django is sadly hampered by two fairly complex problems. The first, is their insistence on backwards compatibility and stability. While it's becoming obvious that the basic design of Django creates serious problems when moving away from the request/response cycle, it's a very hard problem to fix if you can't fundamentally change core assumptions within the framework. Second, Python 3 (sans Tulip) just isn't up to snuff for asynchronous coding. Twisted is a mess, Tornado is far too simple.

The Rails team seems more willing to break with the past between releases, but its still hampered by Ruby's inherent performance disadvantages.

Ultimately, while none of these frameworks are disappearing any time soon, it'd be fair to say that many engineers, particularly those working at the edge of the industry, are choosing things like Node, or Go.

[TylerE]

How exactly do you write a web app that doesn't process requests and return a response?

[etchalon]

It's less that requests don't return a response than that a request and response is not assumed to be a clean transaction.

[TylerE]

That doesn't make any sense. Can you give some examples?

[playing_colours]

I cannot imagine web frameworks working beyond request/response. About Play - I believe it's trying to go further than Django/Rails. It is powered by Netty, Akka, has async response support, plus Scala FP features. There's also promising ReactiveMongo driver. All these put it at least half way closer to shiny async future. I worked with Node.js too and for me it's more pleasure to write async code in Scala.

[UK-AL]

Most the frameworks that abstracted request/response away, are now moving towards it. ASP.NET --> ASP.NET MVC for example.

[etchalon]

While my ASP.NET knowledge isn't deep (I've only ever modified existing code), it seemed like the request/response cycle wasn't abstracted away so much as HTTP was.

[UK-AL]

The whole the thing maintained state between views, so it was more like placing controls, on a view and then having events linked to controls. Rather than requesting, then responding with html.

[japhyr]

Do you have any perspective on how Flask fits into this?

[etchalon]

Flask suffers from the same basic problem, though slightly less so because it has fewer core principles that would break if the response/request cycle were removed or augmented by a consistent connection assumption.

[arocks]

Frameworks evolve and adapt to changing needs. But they try to stick to their core design philosophies. Django's philosophy is quite general[1] and might stand the test of time.

Some of the reasons Rails and Django might fall into legacy could be the due to the underlying language itself. If Python continues to be affected by GIL related multiprogramming issues or lack of stronger types, then the associated web frameworks like Django would also be affected. Then there are always non-technical factors like hype and community interest.

Currently, Rails and Django have crossed a certain critical mass in adoption, they are effective for a majority of web programming usecases and have a thriving third party developer community. So my guess is that it would be pretty much a solid choice in 2016 as well.

[1]: https://docs.djangoproject.com/en/dev/misc/design-philosophi...

[bayesianhorse]

I don't see anything "in the pipeline" which would be able to compete with Django in its core domain. Not even Rails, whose main advantage over Django are larger adoption and some better tooling (IMHO).

Certainly not Node.js. The tooling isn't there yet, the javascript language is still a barrier for maintainable code and the asynchronous model as a default comes with very high complexity costs.

Play requires Scala, and I just don't see typical web folks switch to Scala (an otherwise great language) in droves.

Clojure? Really? Yes, Lisp is great. But it's not going to get popular in 2 years and it seems to require some intellectual fortitude that is probably harder to find on the job market than Django talent.

[secstate]

I've said this before here, but to me Django occupies a very different place from a lot of the more recently developed frameworks. And as lame as it sounds, a big part of it is in the large, complicated content-heavy site (go figure, it was developed in a newspaper environment).

Sure, Django can be used to build single page sites and flow-heavy web apps. But that's not its strength. Just as you end up having to do a lot of custom programming to make Meteor or Node/Derby work for a site with 15 different content types and multiple backend administrators, but that's not their strength.

[tomasien]

Rails was released in 2003, and 2013 is almost over. So the question is "in 2 years, will Ruby on Rails still be popular and competitive" - yes. VERY much yes. In 10 years, we can debate that, but in 2016? No way!

[agibsonccc]

I think one notable thing to observe with any of these frameworks is that backends as REST APIs with a javascript heavy front end are becoming more common.

Many of these frameworks won't disappear but I think adapt to the newer trends.

Whether we like it or not java is still here and used, I don't see why rails and django won't be.

The whole point of software is it evolves. These projects both have enough of a following to receive updates to fit those new paradigms.

They may not be as suited for something built from the ground up for that specific use case, but that doesn't mean they will disappear.

[webjprgm]

I worked on a project not long ago that used Rails to serve up purely JSON via a REST API and the front-end was all Ember and Coffeescript. (Coffeescript because an intern started prototyping part of the UI in it, and we all figured it'd be fun to learn. I'm not sold on it though.)

We designed our JSON model differently than Ember Data expected, though, so we basically had to make our own Ruby GEMs and EmberData adapter. But with those in place it's fairly easy to use Ruby as just a back end.

[agibsonccc]

Exactly. I think a lot of web developers could easily find a transition to that model.

There's a lot of great libraries out there for this use case. Not surprised you had to do a bit of customizing though.

I think over time this will be come easier if not baked in to the frameworks themselves.

[cpursley]

Interesting. How did you like the Ember/Rails combo?

Were you using the Rails asset-pipeline to server the Ember app, or did you separate the Ember app (served statically and hitting API)?

[dragonwriter]

> I think one notable thing to observe with any of these frameworks is that backends as REST APIs with a javascript heavy front end are becoming more common.

Backends as HTTP APIs with a javascript heavy front end are becoming very common; REST, not as much, though it seems to be popular now to call any non-SOAP HTTP API a "REST API".

[lhc-]

Django is already pretty good at this with plugins like Tastypie. At my current job our backend is Django + Tastypie and just provides a REST API to an Ext.js frontend.

[apphrase]

The framework choice is not an independent evaluation, you have to take into consideration the accumulated experience level of prospective engineers you can grab within your reach. That's why actually all of the mentioned frameworks will be alive and going. It is increasingly hard to go exotic, if you are thinking of growth and agility. Otherwise you can paint yourself into a corner where recruitment is impossible and a big rewrite is inevitable.

[danso]

What is the perspective of longtime PHP/Wordpress/Drupal developers on this? I've done WP and Drupal briefly before doing Rails, basically all the time. But since then I've also built things in Sinatra and JS frameworks, too.

For awhile, I didn't touch Rails but went back to it and was pleasantly surprised that even though I enjoyed using Sinatra and Padrino, the weight that Rails's magic adds is counter-balanced by convenience that is most welcome to developers.

I contrast this with Drupal/Wordpress, in which the version upgrades make the platforms easier to build out for clients, but not much easier to develop for, in terms of either developing plugins or customizing the install (not sure with Drupal, I quit at around v5).

To me, it seems like Rails is adding some things I may never use, but those things seem to be optional...And from 3 to 4, they did cut back on some magic-hacks, such as the magic-finders that were too susceptible to security flaws.

I think a big part of why Rails may have better longevity than previous uber-platforms is because of its focus on testing. So it's quite feasible that Rails can always adapt (by being more modular) without causing unmitigated chaos in the developer ecosystem.

[gremlinsinc]

As someone who put all his cards in Rails for a few months to develop an app - to find out my company wanted it rewritten for lamp stack -- I am extremely LUCKY that I found Laravel-- it is Rails in all it's glory minus some popular gems, --but it's growing (500+ packages already) and Laravel 4 is just awesome to work w/ ... If it weren't for laravel, I'd drop php altogether..though for enterprise Symfony would be worth a look -but I currently don't need anything beyond Laravel.

[k1w1]

I think that Rails has a lot of life left because it be influenced by the new techniques that are being pioneered in other frameworks. In the same way that Rails inspired frameworks in other languages - new technologies like node and meteor can inspire Rails too.

For example, at aha.io we use Rails, and wanted to get the front-end performance of a Javascript-heavy app, but by taking advantage of what we know (which is writing ActiveRecord models, Rails controllers and ERB views). So we borrowed a technique from Meteor and made our views reactive - using Rails for the view rendering. That way we get the best of both worlds: the code only needs to be written once in Ruby, but the performance and reactivity is like an app that has a Javascript front-end.

This is just one example, but there lots of similar examples (think about the increasing use of functional programming styles). The incredibly rich ecosystem around Rails means that stuff just gets done faster - the ecosystem has done most of the work for you. Apart from Django, every other framework is still playing catchup.

[macarthy12]

>we borrowed a technique from Meteor and made our views reactive

Do you have any links or resource to share on that style?

[k1w1]

I intend to extract the code from our project so we can share it, but haven't gotten around to it yet. It is a combination of Faye (for real-time updates), Rails for view rendering, and some clever Javascript that efficiently merges DOM changes. The last part is the key - it makes it efficient to update large parts of the screen without flickering, or needing to reattach JS event handlers.

The beauty is that it supports even the most complex reactive update use-cases. E.g. reactively updating sort order of a list for one user when another user renames an item in the list. The key benefit though is that you allows you to just write Rails code - there is no need to write Javascript for each new reactive view.

[macarthy12]

Sounds interesting. Love to see it when you release it, better yet do a talk somewhere that gets on confreaks, then I'll see it!

It seems like a conf worthy talk.

[cies]

Play is not "beyond" Rails, it is merely an other community (Java/Scala) that catches up with Rails.

Node.js is a joke, I see more and more people "get it". It sure serves a purpose, but the language not being for general purpose, the syntactical problems of JS and the single-trick concurrency model don't make it fit for true disruption.

Meteor might be a contender for "next level" (currently it is build on Node i think, but that might change one day), I also consider Yesod (Haskell) and some of the web stuff on Clojure to be good contenders.

I think it will not be merely a new FW that changes the scene, I expect it to be a new language along with that.

[ssmoot]

WARNING: A lot of Play/Scala cheerleading from a former Ruby developer. I can't help it. I love my job. Feel free to summarily disregard. ;-)

Play is an evolution for sure. But I'd consider it "beyond". Validation concerns are where they should be: At input. Not the Models. Comet, Websockets, etc are all trivial. Chunked Responses FTW. You don't need different responders. Render _anything_ by having a Writable in-scope.

Our API calls to render our models as JSON look like this:

  api.photos.get(id) map(Ok(_))

The plugin universe isn't there yet, but I tend to think most apps out-grow most framework plugins pretty quickly.

Honestly, I find Play/Scala _more_ productive than Ruby MVC in general. Fewer bugs. Much better performance and memory usage, so fewer constraints (that one is huge). Rework is much easier, but also much less necessary. The language itself is a joy (IMO) to work with.

The Java ecosystem is a huge enabler. You can have complete control over resizing images in ImgScalr, faster, with no external dependencies, in less code and a flatter learning curve than anything I've ever used in Ruby. Scala itself presents a lot of new things to learn and get comfortable with language-wise until you feel you're back in the groove, but once you've got it, I've found that the ecosystem makes the complex things much easier, and the language itself makes the easy things engaging as well.

Ruby doesn't really help much trying to tackle hard problems IME. Image Resizing? Better shell out to ImageMagick. Dubbing a video? Hello shell my old friend. Cache coherency across a cluster? Fire up another external service (maybe Redis) to manage and start working through failure modes and failover scripts if you care about availability. Compare that to Hazelcast. Need to serve static assets? Better setup an NGinx proxy. In-memory near-caching? You don't have the memory for it, and the GC can't handle it anyways, stick to Redis.

Put a crew of experienced Play developers head-to-head with experienced Rails developers, give them the same goals (and non-goals), and you'll have a faster, more maintainable solution from the Play team in the same or less time for anything but the most trivial apps.

IMO. :-)

[yxhuvud]

Most of these seem pretty silly to me, as the tasks you say Rails are bad at happen to be the same that SOA tells us should be separate services anyhow.

I really don't want to handle the side effects of dubbing videos in my web app. That kind of stuff belongs in a dedicated service anyhow - big monoliths are really the killer of maintainability.

[ssmoot]

"Most" seems a bit harsh. Cache coherency is a hard problem for sure, but if you can handle memory efficiently, local-in-memory near-caches are awesome things to have access to.

Just because it's popular to farm that out to another service (and another operations bill) in Ruby because, lets face it, there's not much alternative, doesn't mean it's the best solution. It's just the practical one given the constraints. Lift the constraints, expand your options and there you go.

Some of my others might seem silly to you. Fair enough. There's just at the top of my head.

Dubbing is an IO problem mostly, and pretty cheap. Unless you're doing a lot of it, adding complexity and (really large) performance hits by having to integrate with external services is not a "better" or "easier" solution if you can just say:

  val dubbedVideo = Dub(inputVideo, newAudioSource)

Same for simple image resizing. You have to be pushing a lot of resize operations to make that something you'd want to farm out as opposed to just tossing 'em over to an actor system. And then you should probably be trying to bypass your application server entirely so you don't trade a CPU spike for a lot of IO. Again, more complex.

I've worked in a number of very large Ruby apps. Did a lot of dumb things. Maintainability issues though? That hasn't come from ImageMagick, FFMpeg, Redis, etc. Those things are (mostly) just big up-front expenses. Would Zencoder have made any of our apps more maintainable? No. Absolutely, Definitely, Unequivocally not easier to maintain than the already simple internal API calls that haven't been touched much in years. Zencoder's API has changed more than our own I'm sure.

I would use Zencoder today as opposed to doing the same again. The up-front cost just can't be justified. But even so, maintainability isn't the issue there.

You write a dozen lines of code to do a thing. That code lives in-process. You don't touch it for years. You never have to worry about system dependencies. You never spend an additional dime on operations costs for it. You never had to develop a contingency plan for failover. You never have to worry about it suddenly breaking or a change in it's behavior that isn't directly related to a commit you made you can find with nothing more than "git blame". That's maintainability.

Using external services over bundled libraries is a decision you make on either 1. Cost or 2. Performance. If you don't have performance constraints, and you have access to a simple library someone else has developed you never choose the external service on the basis of maintainability for a given application. It's more expensive in every way.

I guess it's just hard to convey what an enabler solid, mature libraries that don't break can be if all you've experienced is the churn of Ruby and the limitations of having to farm out work to third parties because your system simply can't handle it without worrying about tying up 1 of your limited pool of 16 processes able to service requests under Unicorn for the duration of the operation. Or you're worried about scaling and cache cohernecy so you have to build a cluster of Redis servers, with custom failover scripts, additional system monitoring services to ensure it's both available and that you have a peek into it's behavior. Or you have to talk to a service to get even basic thumbnails and now you're spending 5 seconds to do what could have been done with just a few lines of code in in one second locally with no additional concerns for availability, another bill to pay, or it breaking some day because the service made "improvements".

90% of the "maintenance" problems I've seen with Ruby code can be categorized as: Scaling, Typos, or simply doing the wrong thing and talking to code or services you shouldn't have (i.e.: A SQL update to bypass validations in an offline batch processing scenario, but later on critical business logic is added and now events to trigger those side-effects are also inadvertently bypassed).

Don't validate your models beyond very basic database integrity. Don't worry about farming out services unless it's an actual organizational goal for internally developed services or it becomes a scaling or cost issue. Always favor libraries over services. Your entire stack is libraries. 99% of the code that runs your business is libraries. Services are important, but they solve a niche problem. Don't prematurely optimize for services and commit to the maintenance overhead they bring if you can't justify that with improved time-to-market or scaling because the alternative would be to roll your own. I'm not suggesting you roll your own. I'm suggesting you look on Github first unless you actually have a scaling concern.

So that was a tangent… ;-) But yeah. Maintainability is my current cause-du-jour. Because IME, the Ruby ecosystem has one of the worst maintainability track-records for time and cost of any platform I've ever worked with (and I think I'm fairly qualified to make that claim. I started with Rails v0.7, written some pretty massive open source Ruby projects, have dozens of Gems to my name and have been paid to write and maintain applications in Ruby going on 7 years now).

[PeterisP]

I can second the thought about Yesod - in terms of how it feels it rather comparable with Rails, but is more concise with less boilerplate and stable in the sense that it's hard to accidentally break something; if your change compiles, then it generally works correctly and safely. Tracing /debugging can be a pain sometimes, though.

[microtonal]

Play is not "beyond" Rails, it is merely an other community (Java/Scala) that catches up with Rails.

In many ways, it is beyond Rails. For instance, it offers type-safe URLs and builds upon the Akka actor framework (allowing you to schedule asynchronous tasks, make reactive web applications, etc.).

[saryant]

> builds upon the Akka actor framework

This is really where Play shines. I wouldn't bother with Play for a basic CRUD app, it makes you do too much grunt work yourself (e.g., authentication). But when you have a backend built on Akka and want to build a reactive, event-driven front-end Play makes it trivial.

Akka is the key. Its actor model just makes reasoning about concurrency so easy because of how it deals with state. Add in remoting and clustering and you've got a highly scalable, event-driven clustered backend without too much extra work on your part. Play fits into that sort of ecosystem quite nicely.

[dpritchett]

Worse might be Better in the case of Node, though. It's also benefiting from a great package manager. NPM already has 2/3 as many packages as RubyGems and 20% more than PyPI.

[tejinderss]

I think Rust with a new framework might get some momentum in coming years.

[chrismorgan]

That's my hope. I have one or two ideas that I haven't seen elsewhere and various other ideas that I hadn't seen elsewhere until I looked at certain esoteric frameworks like Yesod (plus a couple of other Haskell ones and Ur/Web), as well as all the normal ideas. Three of my key goals are speed, safety and correctness, all things that are simply lacking (and often drive people away from them in the end) in frameworks like Ruby on Rails and Django (which, incidentally, has been my preferred framework with Python as my preferred language).

However, before I can build the web framework I want in Rust, I'm having to write the HTTP library I want in Rust (with similar goals), and that's the stage I'm currently at: http://github.com/chris-morgan/rust-http.

[tejinderss]

I am aware of your work and I really appreciate it.

[dragonwriter]

It's worth noting that Rails has adapted to compete with alternative Ruby frameworks that arose to deal with Rails issues (both general and specific use cases), and has merged with one of the alternatives. Insofar as either Ruby the language or the main Ruby implementation are issues holding Rails back, both have evolved considerably and continue to, and several alternative implementations capable of hosting Rails have developed.

Rails has quite a bit of life left. Sure, with more choices of frameworks available, there'll be fewer cases where it's the only viable choice for a project, but it will be competitive for some time.

[mdasen]

I feel like this isn't asking the right question. The answers you're going to get are going to be a combination of a) people's perception of what Rails and Django can do and b) people's perception of what the future of the web.

So, let's first look at what Rails and Django can do. Ruby and Python are both slow languages compared to Java, Go, C, and even JavaScript (thanks to companies pouring a lot of work into it). However, computing power is increasing. In the Ruby and Rails world, there has been good work on JRuby, Puma, etc. to help concurrency and move away from the process-based concurrency model. I'm less familiar with Django here, but Python does have frameworks built for concurrency.

Now let's look at Node.js, Java, and Go. All three have good support for handling multiple connections within the same process (via. eventing, threading, and goroutines). Rather than taking up a process per connection, they just add a little bit of RAM overhead and get to stay in the same memory space with cheaper context switching (or none in an evented system). That deals well with long-running processes that would otherwise block a process, tie up RAM, etc.

So, Rails is improving its support for running in a threaded environment and while I don't know as much about Django, Python does have other options addressing this issue. But as it stands today, alternatives have a speed advantage and somewhat by-default operate in a better way for concurrency.

Now, if we're looking toward the future, what do we need this for? We don't need this for things like serving CRUD. If you're trying to keep lots of connections for a chat application waiting for a response, that can be better served by alternatives. However, it should be noted that 37signals does chat via Rails. When thinking about the future, you should think about what is happening in the application and how that affects things like context switching, RAM usage, etc. I don't want to predict the future. If you want to, think about how applications may work that would be better served by systems that don't rely on process-based concurrency.

As some unsolicited closing advice, I find that a lot of people spend an inordinate amount of time worrying over their tools. They want to pick the one set of tools that will last for eternity. Just as your laptop will age and be replaced, the code you write will. Obsessing over tools keeps many from doing anything. There's a lot of low hanging fruit. I'm guessing you see things you want to build - things you could improve upon. Don't worry about having to modify, extend, and do things differently in the future if it's keeping you from doing anything today. Tools are just that: tools. They aren't your product. They're meaningful. Using a better tool is more enjoyable and can create a better outcome. But don't obsess about it trying to guess the future and insulate yourself from future work. Build!

[bhauer]

This is a great answer!

Although I personally believe that with present-day framework performance spanning multiple orders of magnitude, the lower-performance frameworks have a substantial amount of ground to cover before I personally would consider using them. Higher-performance frameworks have, for my use-cases and in my opinion, reached or nearly reached parity in developer efficiency while providing significant pain-reduction on the performance and scale side. In other words, why not enjoy both performance and efficiency?

That said, everything is evolving, so whatever we see today is subject to change. As you said, our answers to this question will be a matter of opinion and belief about what will happen in the future.

Looking forward with only the context of today's technologies, I personally believe that WebSocket and the various protocols built on top of it may eventually supersede the conventional HTTP request-response conversation. To me, this would mean simpler and more direct communication between client and server, putting the two on equal footing with respect to the conversation semantics (the server can take the lead, for example). It's something I have been wanting ever since I replaced an old client-server app with a web application in the late 1990s with a boggled sense of "Why am I shoehorning an application on top of this hypertext document fetching protocol?"

So when building an application today, I like selecting platforms and frameworks that have natively implemented WebSocket.

But echoing your point again, it's impossible to know what else will come up in a few years' time. Unless your system needs to survive for a very long time, technology is too unpredictable to expend that much worry on the long-term future.

[natural219]

http://www.google.com/trends/explore#q=clojure%2C%20ruby%20o...

[al2o3cr]

I dunno, is C still "competitive" with newer technologies? ;)

[atburrow]

C isn't a framework.

[dasil003]

C is to low-level OS-independent programming as Rails is to web programming.

[ssmoot]

No it's not.

Ruby/Rails is the past decade's version of VBScript/ASP3. It's not a foundational technology. As huge of a fanboy as I am of Scala/Play, the C comparison would be as unjustifiable with those as well.

[numbsafari]

Yeah, it's probably more appropriate to say that Javascript, HTML and CSS are to web programming what C is to low-level programming.

[dasil003]

Obviously things become less "foundational" as you go higher up the stack.

[numbsafari]

The C standard library is pretty much a framework, isn't it?

[kamaal]

Absolutely not.

If you have done embedded programming you would know C standard library is pretty much a bunch of standard utils to do stuff like copy char arrays, print and do some memory related stuff.

That is hardly a framework.

[antihero]

Yes, because they are perfectly suitable to a great deal of use cases (websites with interesting things), and provide a huge amount of functionality that you do not get with the other ones.

[itsbits]

with Play and Laravel catching up, its hard to see Rails surviving long...