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.
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.
It's about time to keep up with Zed Shaw tradition: the prediction that Alpha nerds will leave what was hot a few years ago with a lot of crappy code for the next generation.
Here's a prediction: 6 years from now, there will be more crappy heavy JavaScript based web-application out there and the biggest money making is to maintain and fix these apps.
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.
Instead of shaking my head going "it's hard"
I'd rather dig in and see what I can do.
If you're a doer, then good for you. However this development model you're talking about is inherently difficult and better tooling support doesn't help it. You are free to try and fix it however.
Backbone is just a particular example, mentioning other JS frameworks is irrelevant as long as it gets you further away from the simple request/response model. And this is the crux of the problem - most websites and online apps do not need anything more than this simple model, which has served us well and will continue to do so for a long time. And developers felt in love with it because of its simplicity and effectiveness.
So here's my prediction - in 5 years from now, Wikipedia will still be running on top of the current platform (which is universally recognized to be aged and quite shitty), using the same model of interaction with users, but it will still be the most popular and valuable content website from this planet, powered by the biggest database of human knowledge.
I want to use a framework on the frontend for the
same reason I want to use one on the backend
I'm having problems parsing your opinion, because you are mixing things. It is my feeling that you're trying to justify the usage of Node.js, coming up with reasons other than the language itself, especially since Node.js is quite immature in many regards.
Which is why I gave you a reply in the first place - you're making general statements because of very specific needs. I know it is fashionable to build a Facebook or Foursquare clone, however the UI is really not your biggest problem. There are other problems that are more important for applications like this, upon which you should pass judgment on choosing Node.js or Rails or something Java (IMHO, for applications like this I'm more inclined to use Java, as it has no technical limitations).
what percentage uses the low-fi version of the site?
Progressive enhancements are much more useful than catering to users that haven't upgraded their browsers. It also helps with crawlers for instance, because the truth is only Google can crawl your website if it is JS-enabled and even they are having screwups. And maybe you think that Google should be the only game in town, however such a decision would be like optimizing your website for IExplorer only back in the day.
And the way I see it - you can add progressive enhancements when you need them, not sooner. Starting with a dumb version of a site and enhancing it gradually also makes business sense.
It is my feeling that you're trying to justify the
usage of Node.js
I said nothing about Node.js. I said I want a framework on the client-side for the same reasons I want one on the server-side. A framework. Like Rails. For the client-side. So I can have organized code that people other than me understand.
wikipedia
Wikipedia is a content site. I'm not talking about content sites. I'm talking about web apps. There's a huge difference. When I need a blog or a CMS, I guarantee you I'm not reinventing that in Rails. I'm using one that is proven and already solves that problem. And that's a whole other area of discussion. There will always be static pages. Those are the majority. But nobody should be serving those directly from a database. Those should be coming from disk or a cache or something.
I'm talking about interactive user experiences. In web apps.
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.
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.
> 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).
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 :)
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.
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.
In my own experience, using an existing CMS has rarely fulfilled project requirements very well. It's never about just "static pages". You want things like menus and sidebars with specific structure, multi-language support, commenting, search, etc. Then you fight with the existing features and plugins of the CMS and try to bend them to your will.
For instance working with Drupal, my usual procedure was to immediately set up a custom extension, so I could start adding custom features there. I also spent a lot of time learning the filenames of special override templates to use to customize some very small portion of the UI. Sometimes something was impossible without forking an extension or even forking the Drupal core.
Eventually I mostly gave up on the CMS approach and started building websites using frameworks like Rails and Django, which can provide all the features of a CMS as components (gems/apps) which you can use as you wish. I found that this approach almost always suited my development needs much better, because I was no longer "fighting" the CMS.
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.
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.
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.
Yeah. That's kinda what this guy was saying in his artle that we're commenting on. He wasn't really "moving on from Rails"... he was leaving the view layer behind. And then evaluating what else he really doens't need.
There's a strong movement among some of the more verteran Rails devs to write abstractions, ensuring that the ap doesn't depend on the framework as much. So as needs change, things can, and probably should, change with it.
Comments
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.
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.
It's just a tool and not all of us need to build GMail. People treat Rails like it's their girlfriend or something.It's about time to keep up with Zed Shaw tradition: the prediction that Alpha nerds will leave what was hot a few years ago with a lot of crappy code for the next generation.
Here's a prediction: 6 years from now, there will be more crappy heavy JavaScript based web-application out there and the biggest money making is to maintain and fix these apps.
That's not far off. I've made good money fixing Rails apps that have no tests :)
There's so much here I don't even know where to start.
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. 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.
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.
Backbone is just a particular example, mentioning other JS frameworks is irrelevant as long as it gets you further away from the simple request/response model. And this is the crux of the problem - most websites and online apps do not need anything more than this simple model, which has served us well and will continue to do so for a long time. And developers felt in love with it because of its simplicity and effectiveness.
So here's my prediction - in 5 years from now, Wikipedia will still be running on top of the current platform (which is universally recognized to be aged and quite shitty), using the same model of interaction with users, but it will still be the most popular and valuable content website from this planet, powered by the biggest database of human knowledge.
I'm having problems parsing your opinion, because you are mixing things. It is my feeling that you're trying to justify the usage of Node.js, coming up with reasons other than the language itself, especially since Node.js is quite immature in many regards.Which is why I gave you a reply in the first place - you're making general statements because of very specific needs. I know it is fashionable to build a Facebook or Foursquare clone, however the UI is really not your biggest problem. There are other problems that are more important for applications like this, upon which you should pass judgment on choosing Node.js or Rails or something Java (IMHO, for applications like this I'm more inclined to use Java, as it has no technical limitations).
Progressive enhancements are much more useful than catering to users that haven't upgraded their browsers. It also helps with crawlers for instance, because the truth is only Google can crawl your website if it is JS-enabled and even they are having screwups. And maybe you think that Google should be the only game in town, however such a decision would be like optimizing your website for IExplorer only back in the day.And the way I see it - you can add progressive enhancements when you need them, not sooner. Starting with a dumb version of a site and enhancing it gradually also makes business sense.
I'm talking about interactive user experiences. In web apps.
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.
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.
I used underscore templates. Rendering large complex pages is slow. Doing it client side on an iPad is not good.
> 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).
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 :)
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.
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.
In my own experience, using an existing CMS has rarely fulfilled project requirements very well. It's never about just "static pages". You want things like menus and sidebars with specific structure, multi-language support, commenting, search, etc. Then you fight with the existing features and plugins of the CMS and try to bend them to your will.
For instance working with Drupal, my usual procedure was to immediately set up a custom extension, so I could start adding custom features there. I also spent a lot of time learning the filenames of special override templates to use to customize some very small portion of the UI. Sometimes something was impossible without forking an extension or even forking the Drupal core.
Eventually I mostly gave up on the CMS approach and started building websites using frameworks like Rails and Django, which can provide all the features of a CMS as components (gems/apps) which you can use as you wish. I found that this approach almost always suited my development needs much better, because I was no longer "fighting" the CMS.
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.
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.
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.
Yeah. That's kinda what this guy was saying in his artle that we're commenting on. He wasn't really "moving on from Rails"... he was leaving the view layer behind. And then evaluating what else he really doens't need.
There's a strong movement among some of the more verteran Rails devs to write abstractions, ensuring that the ap doesn't depend on the framework as much. So as needs change, things can, and probably should, change with it.