5 ms·

This is less about moving on from Rails and more about moving on from building static pages from a database. Lots of web folks have been predicting this. I've b

by bphogan 15y ago

This is less about moving on from Rails and more about moving on from building static pages from a database. Lots of web folks have been predicting this. I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. With things like Backbone, I can bring up a Rails app without views and do something pretty awesome. And then it becomes a question as to what Rails offers. I love Rails. It got me back into web app development in 2005 after nearly burning out. But Rails isn't exactly keeping up and people who need to move on are going to do that.

jshen 15y ago
I just got finished porting an admin panel from rails views to backbone.js and doing anything in backbone.js is a lot more work. Not only that, you still end up using rails views because you probably want to send pre rendered html to the client to minimize their wait time.
- bphogan 15y ago
  Just curious, but did you use a JS templating language? Cos we've been sending json back and pushing it to mustache templates which seem to render pretty quick.
  - jshen 15y ago
    I used underscore templates. Rendering large complex pages is slow. Doing it client side on an iPad is not good.
jiggy2011 15y ago
I'm not sure that is true for even the majority of cases. Remember that most of the web is not applications but simply pages of content server from a database.
- bphogan 15y ago
  But that stuff doesn't need Rails. At all. I'm talking about applications where people do something. The CMS problem is largely solved. Generate static pages from database content. Combine that with bandwidth caps and you start looking at creative ways to make things work more efficiently. One of those ways is to simply stop sending things down the pipe. Like the repeated layout.
  - jiggy2011 15y ago
    I wouldn't say the CMS problem is 'solved' exactly. Sure, you can install drupal or something but in the majority of cases I still end up building something with a web framework to server out mostly static content (i.e stuff that changes, but not on a second by second basis). Off the shelf CMS is often either underkill or overkill. There are plenty of ways to make things more efficient without abandoning HTML altogether.
    - bphogan 15y ago
      I think you misunderstand. Or perhaps my comment wasn't well stated... Serving staic pages is the solved problem. So is CRUD-based Rails apps. We know how to do that. In that sense, it's solved. We can use Wordpress with Rails, or Radiant, or we can roll our own in half a day. When you send HTML to people, it should be for reading content. That's its purpose and I don't see that ever going away. But when you're talking about having them interact with an interface, I don't see much of a reason for developers to continue to treat it like a 1970's terminal screen. We have tools that are getting better all the time. Building a CRUD CMS is as exciting as watching paint dry to me. Yea people pay for it, but that's usually not the part of the project that's interesting. Doing the same "solved problem" over and over gets old. And it gets scary, because new stuff is happening.
      - jiggy2011 15y ago
        I think we are in agreement more or less. Building CRUD apps isn't exciting or particularly difficult for the most part, although I have built some pretty huge complex CMS systems for specialist industries that were highly bespoke and integrated with legacy back-end. You can build applications now using things like <canvas> and Javascript and use almost no HTML to deliver your app over HTTP (although once we get to that point HTTP itself starts to seem like antiquated overhead). I'm more of a Java than Ruby person but from what I understand Rails is mostly a collection of modules put together (ORM , MVC , Scaffolding etc). Most of the web apps I build I spend about 70% of the time in the model layer anyway. Even if you were to use a completely different paradigm for front end development the majority of the components that a good framework provides would still be very useful. This is why I prefer to loosely couple things as much as possible, that way you could in theory decide you wanted to do your entire front end in 3d using OpenGL or something. I think there is also allot of middle ground between having serving content and having a fully interactive application.
bad_user 15y ago
I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. You'll keep saying that for another two or three years at least. With things like Backbone, I can bring up a Rails app without views Backbone-style development sucked when people did it with Microsoft's MFC, it sucked when people did it with Java's Swing and it sucks right now. At least for native graphical interfaces, you have IDEs to help you out with bindings and all that crap. Rails gives you the possibility of doing progressive enhancements, when you need them. You don't have to build an entire Backbone layer, just for updating a small rectangle on your page, when you can just render a partial in a good old-fashioned way. But Rails isn't exactly keeping up It's just a tool and not all of us need to build GMail. People treat Rails like it's their girlfriend or something.
- bphogan 15y ago
  There's so much here I don't even know where to start. At least for native graphical interfaces, you have IDEs to help you out with bindings and all that crap. Yes, and we had slice and dice dreamweaver. But tons of Rails developers hand-coded their views. You're saying that because it's more work, people won't do it? You're probably right. Thankfully for the super lazy, there are Rails plugins for Backbone that generate a scaffold. And there are other JS frameworks out there besides Backbone. And as more folks work on these problems, maybe we'll get an even better solution. Instead of shaking my head going "it's hard" I'd rather dig in and see what I can do. youu don't have to build an entire Backbone layer, just for updating a small rectangle on your page. You said not everyone is building "GMail". Not everyone is buildign CRUD apps anymore either. And for those of us with users that are seeing sites like Facebook and Foursquare and are demanding interactions where the page doesn't refresh, partials become an absolute nightmare. I have many that I work on. It's a mess. I want to use a framework on the frontend for the same reason I want to use one on the backend... a shared codebase that more people than me understand, that offers some organization and guidelines to follow. Rails gives you the possibility of doing progressive enhancements, when you need them. As an ccessibility proponent, I completely agree that Rails gives us the ability to do progressive enhancement. But it becomes a business question - what percentage uses the low-fi version of the site? Does every project require it? I'll be glad it's there, and doing a non-JS site is in my blood, but reality is that I don't think that's going to be the case in the future. Thanks to modern screenreaders and a bit of proper coding, we can build apps that are accessible. It's probably going to be a bit, but I don't want to wait around.
dasil003 15y ago
> I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. No, there are clear use cases either way. On one hand you have documents, on the other you have multi-platform apps. For the former (which still vastly outnumbers the latter BTW), serving HTML from the server is the obvious choice, for the latter, a REST API is the obvious choice. There is a large gray area in between where you basically have documents with a relatively small amount of UI. I agree that SOA based on REST service (particularly using JSON) are where the most interesting innovation is happening on the web today, but the venerable document model of the web will never go away because it actually fills a surprisingly large use case in a remarkably simple way (hence the success of the web in the first place).
- bphogan 15y ago
  Sorry, what I meant about serving HTML from the server was the construction of HTML documents using server-side code. There will always be static pages served with apache or whatnot :)

by bphogan 15y ago

jshen 15y ago

I just got finished porting an admin panel from rails views to backbone.js and doing anything in backbone.js is a lot more work. Not only that, you still end up using rails views because you probably want to send pre rendered html to the client to minimize their wait time.

bphogan 15y ago
Just curious, but did you use a JS templating language? Cos we've been sending json back and pushing it to mustache templates which seem to render pretty quick.
- jshen 15y ago
  I used underscore templates. Rendering large complex pages is slow. Doing it client side on an iPad is not good.

jiggy2011 15y ago

I'm not sure that is true for even the majority of cases. Remember that most of the web is not applications but simply pages of content server from a database.

bphogan 15y ago
But that stuff doesn't need Rails. At all. I'm talking about applications where people do something. The CMS problem is largely solved. Generate static pages from database content. Combine that with bandwidth caps and you start looking at creative ways to make things work more efficiently. One of those ways is to simply stop sending things down the pipe. Like the repeated layout.
- jiggy2011 15y ago
  I wouldn't say the CMS problem is 'solved' exactly. Sure, you can install drupal or something but in the majority of cases I still end up building something with a web framework to server out mostly static content (i.e stuff that changes, but not on a second by second basis). Off the shelf CMS is often either underkill or overkill. There are plenty of ways to make things more efficient without abandoning HTML altogether.
  - bphogan 15y ago
    I think you misunderstand. Or perhaps my comment wasn't well stated... Serving staic pages is the solved problem. So is CRUD-based Rails apps. We know how to do that. In that sense, it's solved. We can use Wordpress with Rails, or Radiant, or we can roll our own in half a day. When you send HTML to people, it should be for reading content. That's its purpose and I don't see that ever going away. But when you're talking about having them interact with an interface, I don't see much of a reason for developers to continue to treat it like a 1970's terminal screen. We have tools that are getting better all the time. Building a CRUD CMS is as exciting as watching paint dry to me. Yea people pay for it, but that's usually not the part of the project that's interesting. Doing the same "solved problem" over and over gets old. And it gets scary, because new stuff is happening.
    - jiggy2011 15y ago
      I think we are in agreement more or less. Building CRUD apps isn't exciting or particularly difficult for the most part, although I have built some pretty huge complex CMS systems for specialist industries that were highly bespoke and integrated with legacy back-end. You can build applications now using things like <canvas> and Javascript and use almost no HTML to deliver your app over HTTP (although once we get to that point HTTP itself starts to seem like antiquated overhead). I'm more of a Java than Ruby person but from what I understand Rails is mostly a collection of modules put together (ORM , MVC , Scaffolding etc). Most of the web apps I build I spend about 70% of the time in the model layer anyway. Even if you were to use a completely different paradigm for front end development the majority of the components that a good framework provides would still be very useful. This is why I prefer to loosely couple things as much as possible, that way you could in theory decide you wanted to do your entire front end in 3d using OpenGL or something. I think there is also allot of middle ground between having serving content and having a fully interactive application.

bad_user 15y ago

I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. You'll keep saying that for another two or three years at least. With things like Backbone, I can bring up a Rails app without views Backbone-style development sucked when people did it with Microsoft's MFC, it sucked when people did it with Java's Swing and it sucks right now. At least for native graphical interfaces, you have IDEs to help you out with bindings and all that crap. Rails gives you the possibility of doing progressive enhancements, when you need them. You don't have to build an entire Backbone layer, just for updating a small rectangle on your page, when you can just render a partial in a good old-fashioned way. But Rails isn't exactly keeping up It's just a tool and not all of us need to build GMail. People treat Rails like it's their girlfriend or something.

bphogan 15y ago
There's so much here I don't even know where to start. At least for native graphical interfaces, you have IDEs to help you out with bindings and all that crap. Yes, and we had slice and dice dreamweaver. But tons of Rails developers hand-coded their views. You're saying that because it's more work, people won't do it? You're probably right. Thankfully for the super lazy, there are Rails plugins for Backbone that generate a scaffold. And there are other JS frameworks out there besides Backbone. And as more folks work on these problems, maybe we'll get an even better solution. Instead of shaking my head going "it's hard" I'd rather dig in and see what I can do. youu don't have to build an entire Backbone layer, just for updating a small rectangle on your page. You said not everyone is building "GMail". Not everyone is buildign CRUD apps anymore either. And for those of us with users that are seeing sites like Facebook and Foursquare and are demanding interactions where the page doesn't refresh, partials become an absolute nightmare. I have many that I work on. It's a mess. I want to use a framework on the frontend for the same reason I want to use one on the backend... a shared codebase that more people than me understand, that offers some organization and guidelines to follow. Rails gives you the possibility of doing progressive enhancements, when you need them. As an ccessibility proponent, I completely agree that Rails gives us the ability to do progressive enhancement. But it becomes a business question - what percentage uses the low-fi version of the site? Does every project require it? I'll be glad it's there, and doing a non-JS site is in my blood, but reality is that I don't think that's going to be the case in the future. Thanks to modern screenreaders and a bit of proper coding, we can build apps that are accessible. It's probably going to be a bit, but I don't want to wait around.

dasil003 15y ago

> I've been saying for about two years now that the days of serving entire HTML pages from the serverside are numbered. No, there are clear use cases either way. On one hand you have documents, on the other you have multi-platform apps. For the former (which still vastly outnumbers the latter BTW), serving HTML from the server is the obvious choice, for the latter, a REST API is the obvious choice. There is a large gray area in between where you basically have documents with a relatively small amount of UI. I agree that SOA based on REST service (particularly using JSON) are where the most interesting innovation is happening on the web today, but the venerable document model of the web will never go away because it actually fills a surprisingly large use case in a remarkably simple way (hence the success of the web in the first place).

bphogan 15y ago
Sorry, what I meant about serving HTML from the server was the construction of HTML documents using server-side code. There will always be static pages served with apache or whatnot :)