How is this different from the recently released Play framework. And can you give us more details as to why it should be used over SpringMVC or frameworks like Play?
I believe Play and SpringMVC are both great frameworks and it will be hard and probably too early to compare Micro with these two. I designed Micro's functionality from outside-in, and tweak it for performance from inside-out; small memory footprint, light and fast, .yml for config, extensions, routing and REST support without Java annotation, scripting support for fast prototyping, template engines for clean dynamic content manipulation. I am trying to bring in as much as I learned from my experience as a Sinatra/Merb developer.
Working with Designers for so many years, I was trying to build something that a Designer can use in minutes and use it for publishing his work with the littlest effort possible; all these without writing a single line of Java code. I am sure Play/SpringMVC can do that too?!
For Micro, the separation of roles and concerns is adamant.
Micro (like jpublish.org) is about helping the publishers taking their dynamic content to the web as easy as possible, while allowing the Developers to bring in as much business logic power as possible but without interfering with the content publishing concern; the true separation of roles and concerns. Please have a look at Micro's documentation web site: http://micro-docs.simplegames.ca/ (source on Github too); hosted at Heroku, it is a Micro web app and its entire content is written in Markdown. This is an example of what most of the web Designers and the small publishers will like to have, I think/hope?! Speaking about the Heroku, the compiled slug size, for a standard web app using Micro, is 11.7Mb. Micro is micro :)
I really hope someone picks up Play 1.2.x and maintains it. The Play 2.x alleges to be bi-lingual, Java and Scala, but it's pretty much an Scala version of Play.
I second that. As javaists are concerned, Play 2.x is not a good thing : bigger, slower, more rigid and with a lot scala dependencies/idioms you don't care about.
Forking Play 1.2.x could be a solution (and maybe remove the python console. After all that's a java framework)
Or.
Or one may use the extensibility of Play 2.x to remove the scala parts javaists don't want.
It shouldn't too hard.
I've tried asking people about adding new features to the Play 1.2.x code, but the developers have firmly said that they would no longer add features to the 1.x line :(
Play is begging to be forked, specially as the developers' vision diverges from that of Play 1.2.x users. We have a big ERP app built on Play 1.2 and have no interest in moving to Scala and 2.0. Our version of Play is, for all intents and purposes, a fork.
Working with Designers for so many years, I was trying to build something that a Designer can use in minutes and use it for publishing his work with the littlest effort possible; all these without writing a single line of Java code. I am sure Play/SpringMVC can do that too?!
For Micro, the separation of roles and concerns is adamant. Micro (like jpublish.org) is about helping the publishers taking their dynamic content to the web as easy as possible, while allowing the Developers to bring in as much business logic power as possible but without interfering with the content publishing concern; the true separation of roles and concerns. Please have a look at Micro's documentation web site: http://micro-docs.simplegames.ca/ (source on Github too); hosted at Heroku, it is a Micro web app and its entire content is written in Markdown. This is an example of what most of the web Designers and the small publishers will like to have, I think/hope?! Speaking about the Heroku, the compiled slug size, for a standard web app using Micro, is 11.7Mb. Micro is micro :)