Introducing a new Java framework for web development: Micro
8 comments
Very interesting. I've been playing around with Spark a little as of recently (Sinatra inspired minimalistic Java web framework). I think Mu may allow for some out-of-the-box functionality that Spark lacks.
At the end of the day, though, I'd be happy working in a Java framework wherein the experience didn't feel like I was forcing myself to write Java code. It's just such an uphill battle when the dev experience of (rails/node/django/webapp/web.py) is radically different from just about everything Java has to offer. The lack of a sane package manager, for one, is a major downer.
At the end of the day, though, I'd be happy working in a Java framework wherein the experience didn't feel like I was forcing myself to write Java code. It's just such an uphill battle when the dev experience of (rails/node/django/webapp/web.py) is radically different from just about everything Java has to offer. The lack of a sane package manager, for one, is a major downer.
Further more, to a comment I made earlier: http://news.ycombinator.com/item?id=5196565 and regarding the package managers.
As a Ruby developer, my first impulse was to use Rake but I started with Maven, trying to follow the bigger players, and I found myself struggling with managing various Maven dependencies and settings instead of focusing on getting the things done. Then I switched to Ant when I discovered the difference it makes when deploying to Heroku. Mu's compiled slug size deployed with Maven was 57Mb while the same core deployed with Ant today is 11.7Mb, give or take.
I'll commit the Maven configuration files soon, it is not my intention not too, but I will still search for a better solution. Any suggestions? Thank you for your feedback!
As a Ruby developer, my first impulse was to use Rake but I started with Maven, trying to follow the bigger players, and I found myself struggling with managing various Maven dependencies and settings instead of focusing on getting the things done. Then I switched to Ant when I discovered the difference it makes when deploying to Heroku. Mu's compiled slug size deployed with Maven was 57Mb while the same core deployed with Ant today is 11.7Mb, give or take.
I'll commit the Maven configuration files soon, it is not my intention not too, but I will still search for a better solution. Any suggestions? Thank you for your feedback!
You may not like it, and it has its warts, but I have trouble not calling Maven "sane".
Perhaps I'm judging it according to an unfair standard, and I certainly don't have the intention of getting into a language war. However, I personally view Maven (including but not limited to its config files) as quite insane.
When compared to, for instance, NPM or Ruby Gems, I can't honestly say I've found much to like about the Java ecosystem. Part of the problem, of course, is that unlike in the case of the aforementioned two, build & dependency management in Java-land is quite fragmented (ant, maven, gradle, etc.).
When compared to, for instance, NPM or Ruby Gems, I can't honestly say I've found much to like about the Java ecosystem. Part of the problem, of course, is that unlike in the case of the aforementioned two, build & dependency management in Java-land is quite fragmented (ant, maven, gradle, etc.).
Interesting. Will check it out.
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?
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 :)
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.
Here's a thread on the official forum about it : https://groups.google.com/forum/?fromgroups=#!topic/play-fra...
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.
Here's a thread on the official forum about it : https://groups.google.com/forum/?fromgroups=#!topic/play-fra...
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.
I'm developing several apps in Java and Play 2 and I haven't found any problems more than the templates being in Scala.
> How is this different from the recently released Play framework
Just a nitpick: Play was initially released in 2007, so I wouldn't call it a "recent" framework :-)
Just a nitpick: Play was initially released in 2007, so I wouldn't call it a "recent" framework :-)
> How is this different from the recently released Play framework.
I believe a web Designer will be less intimidated by Micro.
I believe a web Designer will be less intimidated by Micro.
Hmm... I don't think so... it was more like 2009.
This looks like an interesting project, I'll be checking it out for sure. I realise it's early days but I want to encourage you to take a look at the excellent docs that sinatra provides in http://www.sinatrarb.com/intro. One of the recurring problems with docs for java projects is that they spend a lot of time talking about how the framework works. The great thing about those sinatra docs is that they're focused on telling you how to do things. As a user of the framework this is great as generally I'm trying to build something and just want to know how to do it as quickly as possible. Having great docs means that more people are going to use your project so it's an area where your efforts will really pay off. It looks like a great project and I look forward to using it.
thank you for feedback. The µ docs site is trying to satisfy the Designer and the Developer, two very important roles in my framework design strategy. You are very right about Sinatra and I will definitely add more examples. Counting on the community to improve the docs as soon as µ gets more traction, this is why the docs site is open source too :)
I come to think that the main issue with doing web with Java is the inability to do auto reload. There is somewhat way to do this in case of using remote debugging, but it works only on method level. And even when this works, most of the Java tooling actually sits in the way of this. For instance web servers/applications, frameworks and build systems.
However having the framework in Java and actual web app logic in some dynamic language works very smoothly - I've done something similar with JS (Rhino) where the server actually takes care of auto reload and module system. Not really finished but: http://code.google.com/p/sodejs-java (wow maybe I should move it to github finally).
However having the framework in Java and actual web app logic in some dynamic language works very smoothly - I've done something similar with JS (Rhino) where the server actually takes care of auto reload and module system. Not really finished but: http://code.google.com/p/sodejs-java (wow maybe I should move it to github finally).
I truly understand your point, and this is why Micro is offering a flexible scripting support. You can quickly prototype your business logic without needing to restart the app, which BTW, it only takes a few seconds. Using Beanshell, for example, allows you to develop and test the business logic and then transfer the code to Java if need be.
However, I am currently working on integrating the JCL (https://github.com/kamranzafar/JCL) library, recently released under a dual license by its author; it used to be LGPL only. This way I hope I can offer the class loading support at runtime, like Play is doing it, for example.
However, I am currently working on integrating the JCL (https://github.com/kamranzafar/JCL) library, recently released under a dual license by its author; it used to be LGPL only. This way I hope I can offer the class loading support at runtime, like Play is doing it, for example.
Play targets the reload problem very efficiently and works.
This looks cool. Will give it a try soon. One comment I have is regarding the jars in the github repo, would you not benefit by using some kind of repository to pull down the jars when compiling (eg. sonar, maven central, clojars etc.) and remove all those deps from there and allow users to use their modified versions if needed. that will also reduce the size of your repo.
Also have you looked at dropwizard (http://dropwizard.codahale.com/) it's really simple to use. Would like to know your thoughts on that and also how your framework compares to theirs.
Also have you looked at dropwizard (http://dropwizard.codahale.com/) it's really simple to use. Would like to know your thoughts on that and also how your framework compares to theirs.
dropwizard looks very cool.
I believe more and more that Micro is talking to a specific audience, where the non-Java users have an important role too in the development of the site; Designers, Content managers, etc. With Micro they can prototype quickly before even calling for dev support. I am glad that when I compare Micro with similar frameworks, I realize how small Micro is:) And I truly like it this way. Sure Micro is lacking the persistence support for now (many other features too, probably) and it will be hard to compare it with other frameworks from this perspective. However, Micro is modular and can be expanded easily! (I am searching for a light ORM that I could add as an optional extension; activejdbc, maybe?)
Honestly, I see all the other similar frameworks as options, not as competitors. Let the users compare and choose based on what they want to accomplish. Maybe they'll use ... I don't know ... Play, to randomly pick one, for building an awesome e-comm web site, but would they use it for developing a .. blog, or a fast REST service front-end layer let's say?! The Ruby world is full with good examples where devs/designers are swinging between the fat Rails and the slimmer Sinatra/etc., shouldn't we be glad we can start doing the same in Java?
;)
I believe more and more that Micro is talking to a specific audience, where the non-Java users have an important role too in the development of the site; Designers, Content managers, etc. With Micro they can prototype quickly before even calling for dev support. I am glad that when I compare Micro with similar frameworks, I realize how small Micro is:) And I truly like it this way. Sure Micro is lacking the persistence support for now (many other features too, probably) and it will be hard to compare it with other frameworks from this perspective. However, Micro is modular and can be expanded easily! (I am searching for a light ORM that I could add as an optional extension; activejdbc, maybe?)
Honestly, I see all the other similar frameworks as options, not as competitors. Let the users compare and choose based on what they want to accomplish. Maybe they'll use ... I don't know ... Play, to randomly pick one, for building an awesome e-comm web site, but would they use it for developing a .. blog, or a fast REST service front-end layer let's say?! The Ruby world is full with good examples where devs/designers are swinging between the fat Rails and the slimmer Sinatra/etc., shouldn't we be glad we can start doing the same in Java?
;)
Thanks for your reply and your thoughts on the different frameworks.
Totally agree about giving better options to dev quickly in java too. There are so many times when I just end up using python to dev quickly and make a proof of concept web api and then when I have to interface with JVM systems, I end up writing thrift interfaces to keep my original python code around and to allow me to do quick changes to the api.
I tried dropwizard and it really makes it easy to write a webapi and is really fast. With that said, I will play with Micro very soon and let you know how it went.
Totally agree about giving better options to dev quickly in java too. There are so many times when I just end up using python to dev quickly and make a proof of concept web api and then when I have to interface with JVM systems, I end up writing thrift interfaces to keep my original python code around and to allow me to do quick changes to the api.
I tried dropwizard and it really makes it easy to write a webapi and is really fast. With that said, I will play with Micro very soon and let you know how it went.
Awesome!
PS : The favicon looks like the uTorrent icon. :P
Thank you. I hope the uTorrent guys don't mind the resemblance of the two favicons. The Greek letter μ is universal. I'll change the colours if need be :)
Thank you for pointing it out.
Thank you for pointing it out.
looks good, I like the option to select different template engines.
On the other hand, your i18n approach is not correct, since you are using only the language and not the country code: en_GB is different than en_US in lots of aspects, i.e. currencies.
Internationalization is the first thing I tend to look at a framework and many fail on it.
Lack of examples, sorry. Country and Language are both supported. You can create the following properties file: messages_en_GB.properties, and you have a language and country based translation!
I will clarify this aspect in the docs, many thanks for catching that!
I will clarify this aspect in the docs, many thanks for catching that!
updated the docs with a better message: http://micro-docs.simplegames.ca/internationalization.md, please note the Country role in naming the translation files. Thank you!
I have one question: How is security being handled? E.g. Setting basic auth for a REST service or form-based login on a webapp?
I will add an example. My goal is to leave the framework as lean as possible and add functionality by using various extensions. I can see the security functionality added as a µ Extension enabling a set of filters and specific web pages; ala Devise. The Extensions allow you to create a completely independent "mini-site" and inject its functions into the main app. With extensions you can add your own filters, routes, controllers and specialized dynamic content/web-UI. Please have a look at: https://github.com/florinpatrascu/micro-extensions/tree/mast..., as an example implementation of the aspects mentioned above. I see something like Devise being built this way.
Thanks for clearing it out!
Documentation: http://micro-docs.simplegames.ca, a Micro web application using Markdown for formatting the content; work in progress and available as an open source project too.
While still in beta, we believe you will find Micro interesting to work with and you are more than welcome to try it out and send us your feedback.
Thank you!