On Tue, Nov 2, 2010 at 10:49 AM, Luke VanderHart <luke.vanderh...@gmail.com> wrote: > fanvie, two comments: > > 1. It will get better over time, of course, as standard practices for > Clojure shake out. > 2. You don't need 99% of the special crap that Spring/Grails gives > you. Clojure's abstractions are smaller, yes, but the're just as > powerful, and give you more control, in a more standardized way, then > Spring does.
Given other responses, I'd like to chime in with some agreement with Luke. I think it's important to be aware of what frameworks do for you, and what they don't do. It can be very easy, in a framework like Rails, to get a simple UI for doing basic CRUD operations on a single table, and for indicating basic relationships in the model. And someone's written a little HTML here and there to save you a little effort in the view. But what frameworks *don't* give you is a solution to the particular problem you're working on, and while it seems at first like they've already written 80% of your app, you'll quickly find that it's really a lot closer to 8% -- and the easy 8%, at that. For anything more complicated than a grocery list, the differences between frameworks is dwarfed by the application-specific logic of your project. I'm always amused when people try out some framework by making a blog, "proving" their framework is better because they could do it in 20 lines of code instead of 30. Beware frameworks that claim to be "easy." It usually means that the complexity lurks somewhere else. -- Chris Riddoch -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
