{"id":13855,"date":"2021-07-21T15:50:27","date_gmt":"2021-07-21T12:50:27","guid":{"rendered":"https:\/\/railsware.com\/blog\/?p=13855"},"modified":"2025-02-26T12:15:35","modified_gmt":"2025-02-26T09:15:35","slug":"django-vs-ruby-on-rails-comparison","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/django-vs-ruby-on-rails-comparison\/","title":{"rendered":"Django vs. Ruby on Rails Comparison"},"content":{"rendered":"<p class=\"intro-text\">When it comes to Object-Oriented Programming (OOP), two languages stand out from the pack in terms of maturity, community and worldwide use, namely Ruby and Python. And since a large portion of programming languages are used in conjunction with web development, we have to discuss their respective web frameworks: Ruby on Rails and Django.<\/p>\n<a target=\"_blank\" rel=\"noopener noreferrer\">\n<img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-13874\" src=\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2021\/07\/django-vs-ruby-on-rails-comparison-1024x538.jpg\" alt=\"Django vs Rails comparison\" width=\"1024\" height=\"538\" srcset=\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2021\/07\/django-vs-ruby-on-rails-comparison-1024x538.jpg 1024w, https:\/\/railsware.com\/blog\/wp-content\/uploads\/2021\/07\/django-vs-ruby-on-rails-comparison-360x189.jpg 360w, https:\/\/railsware.com\/blog\/wp-content\/uploads\/2021\/07\/django-vs-ruby-on-rails-comparison-768x403.jpg 768w, https:\/\/railsware.com\/blog\/wp-content\/uploads\/2021\/07\/django-vs-ruby-on-rails-comparison-1536x806.jpg 1536w, https:\/\/railsware.com\/blog\/wp-content\/uploads\/2021\/07\/django-vs-ruby-on-rails-comparison-2048x1075.jpg 2048w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/a>\n<h2>But which framework is best suited for you in 2021?<\/h2>\nYou can think about web development as any application that is intended to be used directly over the internet. Depending on what your company\u2019s needs are and the resources available to you, some choices become more apparent than others.\nAs with traveling \u2013 where you can choose from multiple routes and means of transportation to reach your destination \u2013 so do programming languages offer different means of achieving the same desired outcome.\n\nSome notable differences between various languages include functional programming vs. OOP programming and declarative vs procedural programming (derived from imperative programming ).\n\nThese represent different flavours of programming and encompass unique quirks and features. But, much like how debating which is better out of vanilla and pistachio ice cream is meaningless since it is a question of taste, so is comparing functional vs. OOP.\n\nHowever, if you know you like pistachio ice cream, comparing which brand offers the best pistachio ice cream is a worthy pursuit, hence today we will discuss the comparison between Django and Ruby on Rails.\n<h2>Main similarities between Django and Ruby on Rails<\/h2>\nFirst of all, both of these are web frameworks and should not be confused with their respective languages. A web framework (WF) or web application framework (WAF) is a software framework that is designed to support the development of web applications including web services, web resources, and web APIs \u2013 basically any application that is designed to be used over the web and as such adheres to web protocols and standard practices.\n\nBoth of their underlying languages are OOP languages, meaning that they are used to create objects that pass messages since everything is an object in OOP.\nNote: If you\u2019re unfamiliar with what OOP is, in short, the whole idea behind OOP is passing messages and that every object doesn\u2019t care who the message receiver is or who the message sender is. This means that objects can change behavior depending on what messages they work with. That is the whole basis of polymorphism.\n<h3>Communities behind Django and Ruby on Rails<\/h3>\nBoth respective languages and frameworks have large and rather close knit communities, which is quite rare. This means that, in general, their respective communities share a consensus on how things should be done as opposed to, let\u2019s say, the JavaScript community, which only shares the language as a commonality and not much else.\n\nWhat this means is that you can be sure when you hit a wall during development \u2013 a bug, unexpected or unwanted behavior, or even not knowing what direction you should go in \u2013 you can easily search for your issue online and find plenty of solutions, examples, and recommendations. And the best part is that, for most issues documented and resolved, there is community consensus. You never have to worry about \u201cpicking the right answer\u201d to your problem.\n\nBecause of these communities and their consensus on how things should be done, both frameworks offer bootstrapping tools in the form of commonly used libraries and packages for resolving specific issues.\n<h3>Plenty of libraries for Ruby on Rails and Django<\/h3>\nThese external libraries come in the form of \u201cgems\u201d in Rails and \u201cpackages\u201d in Django. The installing procedure and syntax is extremely similar.\n\nFor example, if you want to add user authentication in your Rails application, all you need to do is:\n<ul>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Add gem &#8216;devise&#8217;, &#8216;~&gt; 4.7&#8217;, &#8216;&gt;= 4.7.3&#8217; in your rails gemfile<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Run bundle install in your terminal<\/a><\/li>\n<\/ul>\nFor Django, you would use the ubiquitous pip install command (preferably with pip3):\n<ul>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">pip3 install Flask-Authorization in your terminal<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Or add it to your requirements file and execute that<\/a><\/li>\n<\/ul>\nNote: Bundle install is a command of the tool Bundler, which is also a gem \u2013 a gem that manages gems in Rails.\n<h3>Language version management for Django and Rails<\/h3>\nAnother cool similarity is environment control&#8230; well, sort off.\n\nWorking on multiple projects at once can be difficult regardless if they are in Django or Rails since dependencies often change depending on the project. One notable dependency is the language version.\n\nIt is true that Ruby and Python are singular languages, but each one in part hosts multiple versions of themselves. And sometimes switching projects without switching language versions in your system environment can break your work \u2013 unless you are using Docker.\n\nTo solve this problem, the ruby community uses version managers, the most popular two choices being <code>rvm<\/code> and <code>rbenv<\/code>, the latter being the more recommended one.\n\nFor python, <code>pyenv<\/code> is the preferred tool of choice.\n<h2>Other noteworthy similarities<\/h2>\n<ul>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Open sourced<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Dynamic type<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Maturity \u2013 both languages are over two decades old and both web frameworks are over 15 years old<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Late binding<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Syntactic sugar<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Highly extensible<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Human-friendly syntax<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Human-friendly syntax<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">General purpose<\/a><\/li>\n \t<li><a target=\"_blank\" rel=\"noopener noreferrer\">Free to use<\/a><\/li>\n<\/ul>\n<h2>Major differences between Ruby on Rails and Django Framework<\/h2>\n<h3>Underlying language<\/h3>\nWe already touched upon the main difference between the two frameworks as being the underlying languages.\n\nShort history lesson: the initial idea behind Python came about in the late 80\u2019s from Guido van Rossum in the Netherlands. The intent was to have a language capable of exception handling and interfacing with the Amoeba operating system.\n\nOn the other side, Ruby was birthed in the mid-90s in Japan by Yukihiro &#8220;Matz&#8221; Matsumoto, who wanted something more serious than Pearl and \u201cmore object oriented\u201d than Python. In 1999, Matz was quoted as saying, \u201cI knew Python then. But I didn&#8217;t like it, because I didn&#8217;t think it was a true object-oriented language \u2013 OO features appeared to be an add-on to the language.\u201d\n\nFast forward to 2021 and the current stable versions available for both languages are Ruby 3.0.0 and Python 3.9.2\n\nThe differences in numbering come about from how many major and minor releases both language developers have made since both languages took decades to arrive at their current iteration.\n<h3>User interface<\/h3>\nThere aren\u2019t many differences when it comes to user interface. I mean, there are differences between Django and Ruby on Rails, but more of a flavor difference rather than a type difference.\n\nBoth are very heavily adapted to handle all free market requirements for 21st century web development. When it comes to web frameworks, chances are if it\u2019s something you cannot do with Django or Ruby on Rails, it\u2019s not really something that can be done.\n\nSo it\u2019s more a question of taste which you should choose when it comes to their respective interface. You should experiment with both to get a feel for them and make a decision afterwards.\n<h3>Performance<\/h3>\nBack in the 80s and 90s, developer time was cheap and processor time was expensive. Every problem encountered was in similar parts an issue of hardware as much as software.\n\nFast forward to the present and the situation is the inverse. With such high human resource costs and how hard it is to attract new developers, the developer time has become significantly more expensive as opposed to the new generation style of hardware available that provides super fast run times, computational power, and hosting solutions.\n\nHowever, just because computers and servers nowadays can \u201chandle it\u201d, that doesn\u2019t mean that we should be sloppy. As such, when it comes to speed, both frameworks and underlying languages perform very well, taking into account their scope of use. But if you must be excessively picky, it was observed that Rails is slightly faster, even if by a very small margin.\n<h3>Bootstrapping<\/h3>\nHow many people actually enjoy setting up environments? Well, if you go by the ever-increasing popularity of containers \u2013 and I&#8217;m speaking about Docker here \u2013 then apparently not a lot.\n\nHow fast \u2013 in a download-to-develop sense \u2013 are you really with either platform?\n\nWell, it is a matter of luck to be brutally honest. If everything goes smoothly, both are very easy to install and set up by following their respective installation guides. And where Rails will have you installing gems, Django will have you installing packages.\n\nBut much like how setting up Django on Windows or MacOs might be different than on Linux, so can differences appear between both frameworks on the same machine. It depends on the machine and on the requirements \u2013 aka dependencies \u2013 you need for your specific task.\nDo you want a certain type of database setup? Is it an Sql database or a NoSql?\n\nAnd this goes further down depending on which specific database you want. Do you need to perform simple straightforward user interactions on your app or do you maybe require handling big data sets, and even analyzing and interpreting them?\nIf so, you will need to research beforehand what libraries are currently available for both frameworks. And depending on what libraries there are and what dependencies each of them has, then initial installation and configuration can quickly become burdensome.\nSo you cannot really answer the question of which is faster to set up. But it\u2019s fair to say both can be equally as simple or as frustrating to get started with, depending on your particular circumstances and luck.\n<h3>Availability of documentation and user references<\/h3>\nBoth frameworks have very large communities behind them and as such there is a plethora of user references, documented user experience, and also community driven guides and guidelines \u2013 all to facilitate ease of use and ease of understanding. For businesses looking to build scalable and high-performance applications, choosing to <a href=\"https:\/\/djangostars.com\/services\/hire-django-developers\/\" target=\"_blank\" rel=\"noopener\">hire Django developers<\/a> can provide the expertise needed to leverage Django\u2019s robust features and streamline web development processes.\nOn the official side, since both underlying languages and frameworks are old enough to be considered mature (through and through), it comes as no surprise that both offer extensible, well maintained, and up-to-date documentation.\n\nThis documentation coverage ranges from installation and download, which are very generic issues, to edge case scenarios.\n\nIt is safe to say that no matter what framework you choose, you will never be in the dark when it comes to functionality, expected results, edge cases, gotchas, and the like. Whether with Django or with Rails, you will never feel alone in your development career.\n<h3>Flexibility of use<\/h3>\nPython is the darling of the academic world when it comes to data science, and that makes sense when you think of the relationship between Python and the graphics card industry.\n\nSo if your webapp is designed to center around big data sets, machine learning, and all that crowdfunding terminology, then you should go with Django so as to be able to leverage all the existing libraries that already tackle those issues.\n\nIf you focus on the custom things you need to apply your business domain knowledge, how you manipulate data from your database, and all the cool tricks you need to distinguish your app from your competitors, then you should go the Rails route. Its developer-centered philosophy and flexibility of use \u2013 with metaprogramming, DSLs, and syntactic sugar \u2013 gives your engineers significant freedom and fun when developing. Caution though: Rails gives you enough rope to either have fun or really hurt yourself.\n<h3>Learning curve<\/h3>\nPython is fairly easy to pick up and learn, but difficult to master \u2013 as with all things worthwhile \u2013 and as such Django follows behind with the same curvature. It is a great first language and a great first framework.\n\nIt also works great if you decide to switch fields and pick it up after years of, let\u2019s say, Java or PHP.\n\nRails has a whole philosophy behind it. If you are in tune with it, it is very easy to pick it up \u2013 maybe even easier than Django. The caveat is that you must first understand the philosophy behind it. Things like \u201cConvention over Configuration\u201d and \u201cDRY\u201d (Don\u2019t Repeat Yourself) are cornerstones of \u201cThe Rails Way\u201d, to name a few.\n\nThis underlying philosophy with its guiding principles and specific way of doing things takes time to rummage around and adopt. This is also why plenty of people recommend Rails to more seasoned developers, people who know the pain of programming and the realities of the industry, and as such are equipped with the necessary background or experience to very easily adopt the Rails Way.\n<h2>The driving force behind the technology<\/h2>\nHave you ever had the feeling that maybe, just maybe, a specific language shouldn\u2019t exist? Or worse, wonder in awe at the large scale popularity of a tool that makes no empirical sense? I\u2019ve had that same feeling, and it drove me to research and understand \u2013 at least on a superficial level \u2013 the historical reasons why some languages succeeded where so many others failed.\n\nPHP is a scripting language first and, loosely defined, a general purpose language secondly. But why did it ever achieve popularity despite its many quirks and flaws? Simply put, it was in the right place at the right time \u2013 namely, the dot com bubble.\n\nA lot of the dot com bubble sites and online pages were done with PHP, and any language that is widely used at one point in time is guaranteed to stick around for a long time to come.\n\n<a target=\"_blank\" rel=\"noopener noreferrer\">The most common method of consuming dynamic data, using web apps, is through the internet via a frontend. This guarantees that Javascript will not die out. For the foreseeable future, there will always be a need for JavaScript. Case in point: with the use of node, you can do full stack development with Javascript, server side too. You can check out a <\/a><a href=\"https:\/\/railsware.com\/blog\/python-vs-ruby-vs-node-js-which-platform-is-a-fit-for-your-project\/\" target=\"_blank\" rel=\"noopener noreferrer\">neat comparison of Python vs. Ruby vs. Node.js<\/a>.\n\nC is the de facto language for creating other languages. To make a new language, you need a language parser, and these are done in C. Ruby is written in C and so is Python. So as long as computer languages are needed, so will the need to use C be.\n<h2>Why did Django gain popularity?<\/h2>\nPython was picked up as a study and teaching language in universities for a variety of good reasons. When the same universities got grants for research in AI, NLP (Natural Language Process) and Big Data Analysis, the language for their research was Python. When graphics cards started being heavily used for data science through GPU computing, Python became the obvious choice. As such, the most popular and diverse libraries for data science are available in Python. The same is true for GPU computing on graphics cards, where Python is obligatory as well.\n\nAfter so many years and so much work done, Python is unavoidable for this specific field of computer programming regardless of whether it\u2019s still the best choice or not. What this means is that even if the developers behind Python \u201cdrop the ball\u201d, so to speak, the language itself is guaranteed to remain popular for the same reasons that Javascript and C are popular, or more correctly put, totally unavoidable for their specific niche.\n\nSince Python is so popular and so many new developers pick it up, its de facto web framework, Django, is and will continue to be extremely popular as well.\n<h2>Why did Ruby on Rails gain popularity?<\/h2>\nBefore Rails appeared, Ruby was a mostly unknown language, especially outside of Japan. It was used then, as it is now, in the Japanese automotive industry for embedded Ruby solutions. You could also make a point that it made sense for Japanese manufacturers to use a Japanese programming language either out of pride, a nationalistic sentiment or for security reasons.\n\nWhen D.H.H. \u2013 David Heinemeier Hansson \u2013 presented <a href=\"https:\/\/railsware.com\/blog\/ruby-on-rails-guide\/\" target=\"_blank\" rel=\"noopener noreferrer\">Ruby on Rails<\/a> in 2004 and showcased how you can launch a working web app in under 2 hours, the industry went crazy. You can still find the video of the first presentation of Rails online and I recommend watching it.\n\nWhat D.H.H. did back then, and still does to this day, is keep a very close eye on free market requirements and generate tools to speed up development in a fast and straightforward manner. It is also the main reason behind the \u201cRails Way\u201d \u2013 the philosophy behind Rails and how to use it.\n\nIt also helps that Ruby has a similar underlying philosophy powering it and as such synergizes so well with Rails.\n\nIn short, there aren\u2019t any singular objective reasons for Ruby or Rails\u2019 popularity. It\u2019s not the darling of academia like Python, it did not leverage the dot com bubble like PHP, it isn\u2019t as old as C, or a monopoly like JavaScript.\n\nThe main reason why Rails is popular is because the free market made an informed decision that Rails is the best solution for their problems at hand. Its popularity is dictated by charm, ease of use and the camaraderie in the world wide online community.\n<h2>What should you pick?<\/h2>\nIf this were a perfect world and time was of no constraint, then the obvious choice would be to pick both.\n\nYou will grow way faster and stronger as a developer if you experiment in a production environment with more than just one language or framework.\n\nBut if you are like me, and everyone else on Earth for that matter, and lack the time to indulge in everything that is new and interesting, then you will have to make your choice based on the realities you live in.\nSome things to help guide your choice may include:\n\n<strong>Personal reasons:<\/strong>\n<ul>\n \t<li>Number of jobs available<\/li>\n \t<li>Average industry salary in your area<\/li>\n \t<li>Growth opportunities in your area<\/li>\n \t<li>Disposition for travel or lack thereof<\/li>\n \t<li>Availability of mentors<\/li>\n<\/ul>\n<strong>Technical reasons:<\/strong>\n<ul>\n \t<li>Business application \u2013 what type of application is it?<\/li>\n \t<li>Competition<\/li>\n \t<li>Availability of libraries and prior research<\/li>\n \t<li>Availability of human resource \u2013 how scarce are developers?<\/li>\n \t<li>Can it be done with that technology?<\/li>\n \t<li>Should it be done with that technology or are there better alternatives?<\/li>\n<\/ul>\nYou have to be mindful of these same reasons if you are planning to launch a startup.\n\nUsually startups are the type of business entities where the rules of engagement are not clearly defined, especially in the first couple of years. This means that usually the founders are the ones that handle most of the initial requirements, including the language skills necessary to develop the app.\n\nThat being said, you have to take into account the availability of talent when picking a tech stack. Simply put, if you are a Django developer, but there are no other available Python or Django devs in your area, then this is a clear sign that you will have a hard time finding and hiring help. The same applies for Ruby on Rails developers.\n\nThis is also the main reason why so many companies look for remote devs.\nThe advantage is that there is a big pool of worldwide talent that is used to work in a fully distributed and asynchronous environment, so you can cast a big net.\n\nThe disadvantage is that you cannot work face-to-face. You will have to do a cost-to-benefit analysis on this aspect and see what fits best for your company.\nIn short, it is recommended that you stay in the realm you are familiar with. If you have a background in OOP, pick an OOP tool. If you are a Django dev by trade, go the Django way. If you have Rails devs in your team, pick Rails as the tool for your new project or startup \u2013 better the devil you know than the devil you don\u2019t.\n<h2>Successful business apps powered by Django<\/h2>\n<ul>\n \t<li>Instagram<\/li>\n \t<li>Spotify<\/li>\n \t<li>YouTube<\/li>\n \t<li>The Washington Post<\/li>\n \t<li>Bitbucket<\/li>\n \t<li>Dropbox<\/li>\n \t<li>Mozilla<\/li>\n \t<li>Uber<\/li>\n \t<li>Lyft<\/li>\n \t<li>Facebook<\/li>\n \t<li>Netflix<\/li>\n \t<li>Reddit<\/li>\n<\/ul>\n<h2>Successful business apps powered by Ruby on Rails<\/h2>\n<ul>\n \t<li>Basecamp<\/li>\n \t<li>GitHub<\/li>\n \t<li>Kickstarter<\/li>\n \t<li>Indiegogo<\/li>\n \t<li>Fiverr<\/li>\n \t<li>ASKfm<\/li>\n \t<li>Groupon<\/li>\n \t<li>Shopify<\/li>\n \t<li>Twitter<\/li>\n \t<li>Twitch<\/li>\n \t<li>Hulu<\/li>\n \t<li>SoundCloud<\/li>\n \t<li>UrbanDictionary<\/li>\n \t<li>Bloomberg<\/li>\n<\/ul>\n<h2>More comparisons<\/h2>\nIf you\u2019re interested in a further comparison of web frameworks, be sure to check our articles:\n<ul>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/ruby-vs-php-in-quest-of-the-most-suitable-programming-language-for-your-startup\/\" target=\"_blank\" rel=\"noopener noreferrer\">Ruby on Rails vs PHP<\/a><\/li>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/ruby-vs-java-elegance-contra-ubiquity\/\" target=\"_blank\" rel=\"noopener noreferrer\">Ruby on Rails vs Java<\/a><\/li>\n<\/ul>\n<h2>Additional resources<\/h2>\n<ul>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/why-use-ruby-on-rails-for-your-product\/\" target=\"_blank\" rel=\"noopener noreferrer\">Ruby on Rails advantages<\/a><\/li>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/ruby-on-rails-ecommerce\/\" target=\"_blank\" rel=\"noopener noreferrer\">Ruby on Rails for E-commerce products<\/a><\/li>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/ruby-on-rails-websites\/\" target=\"_blank\" rel=\"noopener noreferrer\">Top websites built with Ruby on Rails<\/a><\/li>\n \t<li><a href=\"https:\/\/railsware.com\/services\/ruby-on-rails-web-development-services\/\" target=\"_blank\" rel=\"noopener noreferrer\">Ruby on Rails development services<\/a><\/li>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/top-online-courses-and-tutorials-to-learn-ruby-on-rails-web-development\/\" target=\"_blank\" rel=\"noopener noreferrer\">Best Ruby on Rails courses and tutorials<\/a><\/li>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/best-books-to-learn-ruby-on-rails\/\" target=\"_blank\" rel=\"noopener noreferrer\">Best books to learn Ruby on Rails<\/a><\/li>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/how-to-hire-good-ruby-on-rails-developer\/\" target=\"_blank\" rel=\"noopener noreferrer\">How to hire Ruby on Rails developers<\/a><\/li>\n \t<li><a href=\"https:\/\/railsware.com\/blog\/ruby-on-rails-hosting-providers-for-your-application\/\" target=\"_blank\" rel=\"noopener noreferrer\">Best Ruby on Rails hosting providers<\/a><\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>When it comes to Object-Oriented Programming (OOP), two languages stand out from the pack in terms of maturity, community and worldwide use, namely Ruby and Python. And since a large portion of programming languages are used in conjunction with web development, we have to discuss their respective web frameworks: Ruby on Rails and Django. But&#8230;<\/p>\n","protected":false},"author":77,"featured_media":13875,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Piotr Ma\u0142ek"],"class_list":["post-13855","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2021\/07\/django-vs-ruby-on-rails-comparison-1024x538.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/13855","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/77"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=13855"}],"version-history":[{"count":18,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/13855\/revisions"}],"predecessor-version":[{"id":18173,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/13855\/revisions\/18173"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/13875"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=13855"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=13855"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=13855"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=13855"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}