Live data from Hacker News

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

news.ycombinator.com

51–60 of 81 posts

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

#51
post #46

Earlier quoted context omitted.

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.).

[deleted]

I think you're missing the real point of Play which is reactive programming. Integration with Akka, simple support for Comet/WebSockets, fully asynchronous. That's what makes Play awesome, not its support for request/response.

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

#53

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…

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?

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.

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

#54

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 follow…

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 adap…

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)?

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

#55
post #42
post #19

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 th…

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-sco…

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.

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

#56
post #32
post #5

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 bet…

> 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.

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

These are not small projects.

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

#57
post #23

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 i…

>we borrowed a technique from Meteor and made our views reactive Do you have any links or resource to share on that style?

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.

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

#58
post #19

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 th…

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

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.

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

#59
post #38

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).…

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.

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

#60
post #18
post #7

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,…

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

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.
Post reply on HN