Choosing a Web Framework/Language Combo for the Next Decade

To be honest I still don't see any compelling reason to switch to anything else in 2014, but if I was looking I'd be strongly favouring Go as the language, as it seems like the preeminent forward-looking, popular-ish, well-supported language. Rust and Erlang would also get a look in.

Rails is pretty much the premier MVC framework. If you are going to go MVC, go with Rails. If we are looking for an alternative to Rails, then we are probably looking for an alternative to MVC, and none of these mentioned choices fit the bill.

I wonder when the day will come that we finally get sick of recreating all the libraries that typically go into an MVC framework. That day, Rails will still be going strong and we will probably give up and just go with Rails.

Of all the choices mentioned, not many have been around as long as Rails. For every day that Rails survives, the stronger it becomes. The more likely it will continue while the alternatives shrivel.

One day MVC may become obsolete, but some people might still want to use an MVC framework for whatever reason. That day, Rails will be there waiting for you.

Years ago, I watched the video on how to build a blog in 10(?) minutes. Today, I can still somewhat follow that video. With many of the MVC frameworks in this list, you couldn't do that. ZF1 is not ZF2 for example. The framework was completely changed. They might as well call ZF2 by a different name. If it were called anything more interesting than "Zend Framework" then maybe it would have a different name.

Go is interesting, but the MVC web framework ecosystem has to be created, just like we did for Node. I don't even know if that will happen anytime, or ever. Maybe people are getting sick of doing that. And then you need to wait X years to see if something actually has any lasting power.

Screw it, just go with Rails.

Or Django. ;)

They really aren't. A REST API wants to be simple and orthogonal; if you want two different pieces of data you make two different calls, so they're well suited to the "one controller per URL" paradigm. A traditional web app needs to combine and reuse components on every page (e.g. you might have a "messages" widget or a "user info" widget, which you would want to be encapsulated with their own logic), so you need better support for composing together different pieces of logic, and a single controller no longer makes sense.

With its clear MVC model, clean HTML and a wicked component module, you can create new applications with reusable components quick and easy. Wicket does use a model inheritance for it’s components, which isn’t great due to a bit steeper learning curve.

The existence of markup files for every component gives you a clear separation of concerns between the controller deciding what to display and the view that specifies how to display. This not only reduces development time but also gives your web designers the confidence to modify the HTML code without worrying about crashing and destroying everything.

[1]: http://zeroturnaround.com/rebellabs/the-curious-coders-java-...