Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I write both rails and clojure.

There's no good clojure web framework for the fat stuff rails is good at, and it doesn't have the same level of plugin maturity, not by a long shot. That's years away. Clojure's good as an API server for a RIA, but it's probably less productive than rails for many use cases. The tools just aren't there, it takes years for tools to get that good. While the java integration is good, using clojure as java glue isn't so fun.

Clojure's strengths are speed, safety via immutable data, and being concise. It's great for a web server if you legitimately have a case where rails is too slow (you probably really don't though). Clojure's also great for non-web programming tasks.



My current project on which I've been working for the past 2 years is built on top of Python/Django and adjacent tools.

The thing I experienced is this - once you outgrow the primary use-cases for a monolithic framework, all of that nice packaging and conventions and modules that play well with each other - start getting in your way, soon to be replaced by custom implementations of whatever you need and all that time you saved initially will be extra time you have to spend to strip out those functionalities, in addition to the time take for building those same things from scratch.

I also worked with Rails btw - for instance you can find like a gazillion plugins for authentication and yet none of them did what I wanted on one project I had, so I had to implement my own authentication logic, after spending hours trying to tweak such a plugin first. That same project needed storage of files on S3, including pictures. Again, there are like a gazillion plugins for that, but none of them did what I wanted. So again, I had to implement it by myself. After trying endlessly to tweak Paperclip or others.

For this project I'm working on the admin interface was initially bootstrapped on top of Django's Admin. Which eventually became a liability and had to be replaced completely. The Django's ORM is also becoming a liability - because it couldn't handle queries for complex scenarios that were unrelated to "objects", so right now the project also makes use of SQLAlchemy - and I'll probably have to pull Django's ORM completely from the project, because the project is also doing sharding right now and I want to expand that to most tables and I can't work with a connection object that's a singleton, not to mention that the "objects" exposed will end up being completely different than the schema used in the DB table, so the object-mapping that Django's ORM does will stay in my way.

In the end, if I need to sum up the things that are still from Django in this project, there are surprisingly few things left.

So if you think about it, for small projects frameworks like Django/Rails are too heavy and for large projects they kind of get in the way and it's better off to start from scratch, importing components as needed, because that way you'll build abstractions that are suited for your domain and that will last longer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: