8 ms·

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

• apphrase 13y ago
  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.
• antihero 13y ago
  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.
• secstate 13y ago
  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.
• ashray 13y ago
  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 13y ago
    > 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.
    • mattmcknight 13y ago
      Django and Rails both run on the JVM. Both have scaled to massive projects, even without the JVM.
    • brnlsl 13y ago
      Built with Rails: Github, Groupon, YellowPages, BaseCamp, Scribd, Shopify, Posterous, Airbnb, Urban Dictionary, Bleacher Report, Kickstarter... These are not small projects.
    • bjt 13y ago
      > 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/what-powers-instagram-hundreds-of-instances-dozens-of http://instagram-engineering.tumblr.com/post/13649370142/wha...) and Disqus (http://blog.disqus.com/post/62187806135/scaling-django-to-8-billion-page-views http://blog.disqus.com/post/62187806135/scaling-django-to-8-...).
• quaunaut 13y ago
  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 13y ago
    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.
• etchalon 13y ago
  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.
  • japhyr 13y ago
    Do you have any perspective on how Flask fits into this?
    • etchalon 13y ago
      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.
  • TylerE 13y ago
    How exactly do you write a web app that doesn't process requests and return a response?
    • etchalon 13y ago
      It's less that requests don't return a response than that a request and response is not assumed to be a clean transaction.
      • 13y ago
• mdasen 13y ago
  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!
• bayesianhorse 13y ago
  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.
• natural219 13y ago
  http://www.google.com/trends/explore#q=clojure%2C%20ruby%20on%20rails%2C%20node.js%2C%20golang&cmpt=q http://www.google.com/trends/explore#q=clojure%2C%20ruby%20o...
• dpritchett 13y ago
  I enjoy the Indeed.com job trends for this sort of thing: http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+node&l= 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.
  • ThomPete 13y ago
    +Java (dwarfs the others) http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+node%2C+java&l= http://www.indeed.com/jobtrends?q=ruby%2C+python%2C+php%2C+n...
    • deleted 13y ago
      [deleted]
    • 13y ago
• al2o3cr 13y ago
  I dunno, is C still "competitive" with newer technologies? ;)
  • atburrow 13y ago
    C isn't a framework.
    • dasil003 13y ago
      C is to low-level OS-independent programming as Rails is to web programming.
      • ssmoot 13y ago
        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 13y ago
          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 13y ago
          Obviously things become less "foundational" as you go higher up the stack.
    • numbsafari 13y ago
      The C standard library is pretty much a framework, isn't it?
      • kamaal 13y ago
        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.
• agibsonccc 13y ago
  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.
  • lhc- 13y ago
    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.
  • webjprgm 13y ago
    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.
    • cpursley 13y ago
      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)?
    • agibsonccc 13y ago
      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.
• ludicast 13y ago
  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 13y ago
    > 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 13y ago
      > 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.)
• dragonwriter 13y ago
  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.
• danso 13y ago
  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 13y ago
    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.
• arocks 13y ago
  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-philosophies/ https://docs.djangoproject.com/en/dev/misc/design-philosophi...
• cies 13y ago
  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 13y ago
    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. :-)
• tomasien 13y ago
  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!
• k1w1 13y ago
  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 13y ago
    >we borrowed a technique from Meteor and made our views reactive Do you have any links or resource to share on that style?
    • k1w1 13y ago
      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 13y ago
        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.
• itsbits 13y ago
  with Play and Laravel catching up, its hard to see Rails surviving long...