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.