7 ms·

I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Applicatio

I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend. Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times.

bdcravens 12y ago
I really don't think SPAs are very common, though following news of what's hot wouldn't suggest that. Honestly, I'd bet 95% of all web apps being built every day are traditional full request/response apps.
Ben-G 12y ago
I think you really need to differentiate between web applications and websites. Websites still are a lot better off with primarily static websites in terms of SEO and performance (caching static pages is easier). For web applications a SPA approach definitely has advantages; for the biggest part in usability. Given that a vast majority of content on the web are pretty plain websites I'm sure Rails will stay relevant for quite a while longer.
aikah 12y ago
> Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times. It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either. > I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend. Why would you need a different framework for a "rest-backend" and a website that displays html? I dont understand.I pretty sure Rails has a "content negociation" like feature when it comes to json,xml,or html content types.
- echoless 12y ago
  > It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either. Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs. > Why would you need a different framework for a "rest-backend" and a website that displays html? A full-stack framework is overkill as a backend for SPAs.
  - aikah 12y ago
    > A full-stack framework is overkill as a backend for SPAs. A full stack framework doesnt(and shouldnt)force you to use its view layer.I fail to see how it is overkill. What is overkill is using different frameworks for an app that spits json and an app that spits html.A good framework shouldnt care wether you return one or the other to the client,that's exactly what Rails does.
  - cageface 12y ago
    but I think a lot of sites will switch to SPAs in the future, since they offer a better UX Actually I suspect that a lot of these kinds of sites will primarily migrate to native mobile apps. A full-stack framework is overkill as a backend for SPAs. I'm not so sure. HTML rendering is a pretty small part of what a complex framework like Rails does. You still need a database/ORM layer, user management and auth, routing, caching, etc. The same things that make Rails productive for traditional web apps also make it pretty nice for building REST APIs.
    - pmontra 12y ago
      If you switch completely to native mobile applications you disappear from the web. That's a lot of people and a lot of incoming links. Mobile apps are less discoverable and they put the install time between "I want to see this" and "I can see this". Sites are trying hard to shave ms from the home page loading time, go figure how well it fits into the picture the minute it takes to decide to download something and get it installed. I think they'll go for a two pronged approach: traditional web site with content plus a mobile app (actually at least two of them). Furthermore, my phone can display an infinite amount of web sites but it can store only a not so large number of apps. And it doesn't have anything as convenient as start typing the name of a site to have the browser display the right url, inner pages included.
  - jordanthoms 12y ago
    People always seem to prefer Sinatra over Rails for building a SPA backend, because 'rails is overkill'. Then they add Active Record, some autoloader implementation, rspec, caching, sidekiq etc and you end up with a cobbled together version of rails essentially. Rails-API is really nice here, strips out the things you truly don't need for a API in rails but keeps all the other infrastructure.
nileshtrivedi 12y ago
I think Javascript frameworks (like Meteor) will grow in prominence given the promise of code sharing between client and server, better integration with single-page applcation and better libraries for server-side processing.
- jedisct1 12y ago
  Or that compiles to Javascript for the client-side, like Volt (which I have been very impressed by): http://voltframework.com/ http://voltframework.com/
  - bildung 12y ago
    That looks really interesting! Are there comparable approaches using python? I know there are multiple python-to-javascript compilers that could fit the role of opal, but I'm not aware of a whole framework.
adamonduty 12y ago
Rails works quite nicely as a REST backend. Its also much faster in my experience to render json than HTML templates. Rails is great as a general starting point, letting you choose SPA at the start or later.
josephagoss 12y ago
I was always under the impression that these server based frameworks are better for two reasons, the code is safe, so you're leaking less of your code, and that the size of the website on the client is reduced allowing for faster downloads. I could be very wrong, but I feel more comfortable keeping as much code on the server as possible.
juliangregorian 12y ago
You guys need to learn how turbolinks works. Rails already is basically an SPA framework.
- echoless 12y ago
  Turbolinks wipes off the entire DOM and replaces it with the new request's html on link navigation. So no, it is not an adequate replacement for SPAs.
digitalzombie 12y ago
I've been doing web dev for 6 years, full stack, back and front, mostly somewhere in the middle and front end. From what I've seen, backend rendering ain't going no where. This SPA trends is still wild west. Angular 1 is kind slowing down imo cause of the drastic changes in Angular 2. Ember is bloat. The javascript eco system is meh right now. NodeJS people probably will argue against this. But seriously, javascript needs a module system. RequireJS kinda suck with grunt, it doesn't work so well other grunt modules. Most of the frontend people I've met barely even use Bower. Sure maybe one that it'll be the future but right now it's unclear whose the winner and if people are willing to invest in something that can be obsolete in 1 or 2 years. Seeing how angular 2 is going to come out eventually a year or two, why learn angular 1? Oh there's the react library and other stuff going on too. I haven't use that but it's getting traction... Grunt and Glup are duking it out. In general it's just meh. I wouldn't bet on Angular or Ember anymore. Rails and Django or whatnot at least they're stable enough and have tons of people using it. I'm kinda sick of it and moving toward backend really. It'll be fun architecturing stuff mesos, dockers, etc..
- tinco 12y ago
  Not to one-up you, just since apparently it's worth mentioning, I've been doing webdev for about 9 years, and at least from my perspective backend rendering is definitely going out the window. I started as a Rails dev in 2008, did ASP.Net before that, and last year I've moved from Rails to a pimped up Grape, which is a framework suited more for developing API's. Maybe it's just the sort of apps I'm building (basically SaaS) but I don't see any backend rendering in my feature, if I'm building it, it's going to be either a SPA, or a static site. (I built my sisters' band a single page static site, very nice). Latest project is using Polymer, and no Javascript framework at all. I think you're right, Angular is extremely ugly, and Ember seems to do too much. But plain Javascript has become very powerful and HTML5+CSS3 reduce the need for UI toolkits. Maybe I'm crazy, but I don't see a super hard need for modules either, I define all dependencies at a single location, and just bind everything to window. The not binding things to window rule is only for library/component developers, if you're an app developer you should own window, make it your home and have everything as you expect it to be. Anyway, what I'm hoping is that new Rails editions focus more on the SPA experience, they have been reluctant to. I use Grape, but I immediately pimped it out with all the niceties Rails has, including ActiveSupport and ActiveRecord, but also a console and decent logging. What I do worry about is the amount of people embracing Node.JS over Ruby. It's crazy people would chose Javascript over any language at all in an environment they're not absolutely forced to. My fear is one day I'll be seeking a job, and all there is is shops building webapps in vanilla Javascript, wouldn't that just be a plain horror story?
dgregd 12y ago
Ruby on Rails is still the most productive why to build web apps. Turbolinks prolonged Rails life cycle, as the best web framework, by two or three years. However SPA are the future. Maybe Angular 2 will be good enough to switch. Maybe something build after Angular 2.
- dgregd 12y ago
  Would you please explain why my comment have been down-voted?
  - mratzloff 12y ago
    Resist complaining about being downmodded. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - bshimmin 12y ago
    Probably because you haven't really provided any supporting evidence for your conclusions. Always show your working out. (Also, for many people, the first thing they do on a Rails project is disable Turbolinks.) I actually happen to agree that Rails is still a supremely productive way to build certain types of web sites and/or applications. An experienced Rails guy, leveraging the vast array of gems out there which can solve many different problems with just a few lines of code, can get an MVP out of the door extremely quickly.
    - dgregd 12y ago
      Two years ago I built an app using Angular. Of curse using Rails as the back-end. As a whole this wasn't a good experience. A such simple thing like authorization took a day or two to implement, solution looked like a one big hack. However some SPA/Angular features worked beautiful. Two way data binding and local templates allow to build complex forms very easy. Data validation of one to many associations was straightforward. In Rails we have to use accepts_nested_attributes_for. It is so 'nice' that some people want to move nested attributes functionality to an external gem. The biggest thing Rails is missing: components. There is a discussion today on HN [1] about this. Angular, web components, HTTP2 might really allow to build real object oriented web apps. In Rails there is a view.erb file and that's it [2]. I guess that competition will force developers to build even more user friendly and responsive apps. By that I mean no more separate pages to add a simple record. New apps will allow to click on a record, edit it in place and save with enter. And to do that well we need SPA architecture. [1] https://news.ycombinator.com/item?id=8671590 https://news.ycombinator.com/item?id=8671590 [2] 10 years ago it was a big thing. At that time typical app is was a bunch of PHP files.
deleted 12y ago
[deleted]
mratzloff 12y ago
For over a decade I've heard that SPA and server-side JavaScript is the future. I always believed JavaScript would carve out a place on the server side, but I've always been skeptical about SPA given the often terrible UX and SEO. And besides that, most sites are better off being served statically from a cache. tl;dr Wake me up when even 5% of sites are SPA.
- bshimmin 12y ago
  Where on earth were you hearing about SPAs and server-side JavaScript in 2004? Was "SPA" even a term before about 2010?
  - nes350 12y ago
    Probably he doesn't mean only JavaScript SPAs. The term was introduced around 2010, but the concept is older. Flex is from ~2004 and is typically used for SPAs which behave like the modern JavaScript applications - they just target the Flash platform instead.
  - aikah 12y ago
    It used to be called Ria,"rich internet applications".Then ajax apps before...nothing new here.
- alan82 12y ago
  > Wake me up when even 5% of sites are SPA. 5% of all web apps or new build apps?
deleted 12y ago
[deleted]
sandstrom 12y ago
I think Rails is great for API-only backends too. I'd say it's quite common to have clients in JS/iOS/Android, and still use a Rails-backend.
megaman821 12y ago
The browser is becoming more of a platform to deploy to like Android or iOS, instead of a document viewer. I think it is still the wild wild west on the client side for now, but once winners emerge there will be a much larger group of developers creating SPA's. It seems Angular 2.0, Ember 2.0, and React 1.0 are all headed in similar directions with their emphasis on components, so a winning concept might emerge some time soon. That said, development trends on the web slowly play out over years. I expect Rails and Django to have a massive user base for 5+ years at least.
meesterdude 12y ago
Rails isn't going away, as there are plenty of sites on the internet that use it. Everything I build is in rails, and i like it that way. And it makes my life pretty awesome, and is enjoyable to work with. I really can't complain. Single page is an option for some people, and there are several ways to get you there as well. But that's the great thing about the web: we have all kinds of ways to deliver an end product. That doesn't make other rendering methods go away, though. Flash is still around, for example. And there's really no reason to project that rails will suffer some terrible fate in a few years time. It's been around for several years now and has done nothing but grow, so as long as it solves a problem and people go to it, it and other frameworks will hang around.
tomchristie 12y ago
Personally I think they're going to remain strong. More single page apps? Fine, but they still need to be backed by an API and, in most cases, a relational database. Yes there will be more frontend templating, and yes more mature fuller stack JS alternatives will emerge, but those role those frameworks fulfill is still needed, backend template rendering or not.
dec0dedab0de 12y ago
just want to point out that Django is pretty good at making REST backends.

bdcravens 12y ago

I really don't think SPAs are very common, though following news of what's hot wouldn't suggest that. Honestly, I'd bet 95% of all web apps being built every day are traditional full request/response apps.

Ben-G 12y ago

I think you really need to differentiate between web applications and websites. Websites still are a lot better off with primarily static websites in terms of SEO and performance (caching static pages is easier). For web applications a SPA approach definitely has advantages; for the biggest part in usability. Given that a vast majority of content on the web are pretty plain websites I'm sure Rails will stay relevant for quite a while longer.

aikah 12y ago

> Perhaps there will still be a large demand for sites that aren't SPA applications. Interesting times. It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either. > I'm curious about the fate of Rails(and other frameworks like Django) in a few years, seeing that many web applications are moving to the Single-Page-Application model and the server simply acts as a rest backend. Why would you need a different framework for a "rest-backend" and a website that displays html? I dont understand.I pretty sure Rails has a "content negociation" like feature when it comes to json,xml,or html content types.

echoless 12y ago
> It's isnt perhaps,99% of websites outthere arent SPAs.I'm pretty sure a majority of website you visit arent either. Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs. > Why would you need a different framework for a "rest-backend" and a website that displays html? A full-stack framework is overkill as a backend for SPAs.
- aikah 12y ago
  > A full-stack framework is overkill as a backend for SPAs. A full stack framework doesnt(and shouldnt)force you to use its view layer.I fail to see how it is overkill. What is overkill is using different frameworks for an app that spits json and an app that spits html.A good framework shouldnt care wether you return one or the other to the client,that's exactly what Rails does.
- cageface 12y ago
  but I think a lot of sites will switch to SPAs in the future, since they offer a better UX Actually I suspect that a lot of these kinds of sites will primarily migrate to native mobile apps. A full-stack framework is overkill as a backend for SPAs. I'm not so sure. HTML rendering is a pretty small part of what a complex framework like Rails does. You still need a database/ORM layer, user management and auth, routing, caching, etc. The same things that make Rails productive for traditional web apps also make it pretty nice for building REST APIs.
  - pmontra 12y ago
    If you switch completely to native mobile applications you disappear from the web. That's a lot of people and a lot of incoming links. Mobile apps are less discoverable and they put the install time between "I want to see this" and "I can see this". Sites are trying hard to shave ms from the home page loading time, go figure how well it fits into the picture the minute it takes to decide to download something and get it installed. I think they'll go for a two pronged approach: traditional web site with content plus a mobile app (actually at least two of them). Furthermore, my phone can display an infinite amount of web sites but it can store only a not so large number of apps. And it doesn't have anything as convenient as start typing the name of a site to have the browser display the right url, inner pages included.
- jordanthoms 12y ago
  People always seem to prefer Sinatra over Rails for building a SPA backend, because 'rails is overkill'. Then they add Active Record, some autoloader implementation, rspec, caching, sidekiq etc and you end up with a cobbled together version of rails essentially. Rails-API is really nice here, strips out the things you truly don't need for a API in rails but keeps all the other infrastructure.

nileshtrivedi 12y ago

I think Javascript frameworks (like Meteor) will grow in prominence given the promise of code sharing between client and server, better integration with single-page applcation and better libraries for server-side processing.

jedisct1 12y ago
Or that compiles to Javascript for the client-side, like Volt (which I have been very impressed by): http://voltframework.com/ http://voltframework.com/
- bildung 12y ago
  That looks really interesting! Are there comparable approaches using python? I know there are multiple python-to-javascript compilers that could fit the role of opal, but I'm not aware of a whole framework.

adamonduty 12y ago

Rails works quite nicely as a REST backend. Its also much faster in my experience to render json than HTML templates. Rails is great as a general starting point, letting you choose SPA at the start or later.

josephagoss 12y ago

I was always under the impression that these server based frameworks are better for two reasons, the code is safe, so you're leaking less of your code, and that the size of the website on the client is reduced allowing for faster downloads. I could be very wrong, but I feel more comfortable keeping as much code on the server as possible.

juliangregorian 12y ago

You guys need to learn how turbolinks works. Rails already is basically an SPA framework.

echoless 12y ago
Turbolinks wipes off the entire DOM and replaces it with the new request's html on link navigation. So no, it is not an adequate replacement for SPAs.

digitalzombie 12y ago

I've been doing web dev for 6 years, full stack, back and front, mostly somewhere in the middle and front end. From what I've seen, backend rendering ain't going no where. This SPA trends is still wild west. Angular 1 is kind slowing down imo cause of the drastic changes in Angular 2. Ember is bloat. The javascript eco system is meh right now. NodeJS people probably will argue against this. But seriously, javascript needs a module system. RequireJS kinda suck with grunt, it doesn't work so well other grunt modules. Most of the frontend people I've met barely even use Bower. Sure maybe one that it'll be the future but right now it's unclear whose the winner and if people are willing to invest in something that can be obsolete in 1 or 2 years. Seeing how angular 2 is going to come out eventually a year or two, why learn angular 1? Oh there's the react library and other stuff going on too. I haven't use that but it's getting traction... Grunt and Glup are duking it out. In general it's just meh. I wouldn't bet on Angular or Ember anymore. Rails and Django or whatnot at least they're stable enough and have tons of people using it. I'm kinda sick of it and moving toward backend really. It'll be fun architecturing stuff mesos, dockers, etc..

tinco 12y ago
Not to one-up you, just since apparently it's worth mentioning, I've been doing webdev for about 9 years, and at least from my perspective backend rendering is definitely going out the window. I started as a Rails dev in 2008, did ASP.Net before that, and last year I've moved from Rails to a pimped up Grape, which is a framework suited more for developing API's. Maybe it's just the sort of apps I'm building (basically SaaS) but I don't see any backend rendering in my feature, if I'm building it, it's going to be either a SPA, or a static site. (I built my sisters' band a single page static site, very nice). Latest project is using Polymer, and no Javascript framework at all. I think you're right, Angular is extremely ugly, and Ember seems to do too much. But plain Javascript has become very powerful and HTML5+CSS3 reduce the need for UI toolkits. Maybe I'm crazy, but I don't see a super hard need for modules either, I define all dependencies at a single location, and just bind everything to window. The not binding things to window rule is only for library/component developers, if you're an app developer you should own window, make it your home and have everything as you expect it to be. Anyway, what I'm hoping is that new Rails editions focus more on the SPA experience, they have been reluctant to. I use Grape, but I immediately pimped it out with all the niceties Rails has, including ActiveSupport and ActiveRecord, but also a console and decent logging. What I do worry about is the amount of people embracing Node.JS over Ruby. It's crazy people would chose Javascript over any language at all in an environment they're not absolutely forced to. My fear is one day I'll be seeking a job, and all there is is shops building webapps in vanilla Javascript, wouldn't that just be a plain horror story?

dgregd 12y ago

Ruby on Rails is still the most productive why to build web apps. Turbolinks prolonged Rails life cycle, as the best web framework, by two or three years. However SPA are the future. Maybe Angular 2 will be good enough to switch. Maybe something build after Angular 2.

dgregd 12y ago
Would you please explain why my comment have been down-voted?
- mratzloff 12y ago
  Resist complaining about being downmodded. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- bshimmin 12y ago
  Probably because you haven't really provided any supporting evidence for your conclusions. Always show your working out. (Also, for many people, the first thing they do on a Rails project is disable Turbolinks.) I actually happen to agree that Rails is still a supremely productive way to build certain types of web sites and/or applications. An experienced Rails guy, leveraging the vast array of gems out there which can solve many different problems with just a few lines of code, can get an MVP out of the door extremely quickly.
  - dgregd 12y ago
    Two years ago I built an app using Angular. Of curse using Rails as the back-end. As a whole this wasn't a good experience. A such simple thing like authorization took a day or two to implement, solution looked like a one big hack. However some SPA/Angular features worked beautiful. Two way data binding and local templates allow to build complex forms very easy. Data validation of one to many associations was straightforward. In Rails we have to use accepts_nested_attributes_for. It is so 'nice' that some people want to move nested attributes functionality to an external gem. The biggest thing Rails is missing: components. There is a discussion today on HN [1] about this. Angular, web components, HTTP2 might really allow to build real object oriented web apps. In Rails there is a view.erb file and that's it [2]. I guess that competition will force developers to build even more user friendly and responsive apps. By that I mean no more separate pages to add a simple record. New apps will allow to click on a record, edit it in place and save with enter. And to do that well we need SPA architecture. [1] https://news.ycombinator.com/item?id=8671590 https://news.ycombinator.com/item?id=8671590 [2] 10 years ago it was a big thing. At that time typical app is was a bunch of PHP files.

deleted 12y ago

[deleted]

mratzloff 12y ago

For over a decade I've heard that SPA and server-side JavaScript is the future. I always believed JavaScript would carve out a place on the server side, but I've always been skeptical about SPA given the often terrible UX and SEO. And besides that, most sites are better off being served statically from a cache. tl;dr Wake me up when even 5% of sites are SPA.

bshimmin 12y ago
Where on earth were you hearing about SPAs and server-side JavaScript in 2004? Was "SPA" even a term before about 2010?
- nes350 12y ago
  Probably he doesn't mean only JavaScript SPAs. The term was introduced around 2010, but the concept is older. Flex is from ~2004 and is typically used for SPAs which behave like the modern JavaScript applications - they just target the Flash platform instead.
- aikah 12y ago
  It used to be called Ria,"rich internet applications".Then ajax apps before...nothing new here.
alan82 12y ago
> Wake me up when even 5% of sites are SPA. 5% of all web apps or new build apps?

deleted 12y ago

[deleted]

sandstrom 12y ago

I think Rails is great for API-only backends too. I'd say it's quite common to have clients in JS/iOS/Android, and still use a Rails-backend.

megaman821 12y ago

The browser is becoming more of a platform to deploy to like Android or iOS, instead of a document viewer. I think it is still the wild wild west on the client side for now, but once winners emerge there will be a much larger group of developers creating SPA's. It seems Angular 2.0, Ember 2.0, and React 1.0 are all headed in similar directions with their emphasis on components, so a winning concept might emerge some time soon. That said, development trends on the web slowly play out over years. I expect Rails and Django to have a massive user base for 5+ years at least.

meesterdude 12y ago

Rails isn't going away, as there are plenty of sites on the internet that use it. Everything I build is in rails, and i like it that way. And it makes my life pretty awesome, and is enjoyable to work with. I really can't complain. Single page is an option for some people, and there are several ways to get you there as well. But that's the great thing about the web: we have all kinds of ways to deliver an end product. That doesn't make other rendering methods go away, though. Flash is still around, for example. And there's really no reason to project that rails will suffer some terrible fate in a few years time. It's been around for several years now and has done nothing but grow, so as long as it solves a problem and people go to it, it and other frameworks will hang around.

tomchristie 12y ago

Personally I think they're going to remain strong. More single page apps? Fine, but they still need to be backed by an API and, in most cases, a relational database. Yes there will be more frontend templating, and yes more mature fuller stack JS alternatives will emerge, but those role those frameworks fulfill is still needed, backend template rendering or not.

dec0dedab0de 12y ago

just want to point out that Django is pretty good at making REST backends.