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