Web stacks that support change - but what kind?
I've recently made a transition from using dependency-injection heavy Java frameworks (Spring, Java EE) to full-stack dynamic language frameworks like Grails, Django, Ruby on Rails etc.
With these full-stack frameworks, you need much less code to get something done, between the magic of dynamic languages, and the elimination of dependency injection . As a result it's easier to iterate rapidly as business requirements change, because there's fewer places to touch and fewer layers of indirection to sort through.
It made me wonder whether dependency injection in Spring and Java EE was intended to address a different kind of flexibility - flexibility to change out pieces of the tech stack. I feel like this kind of flexibility is still a hangover from EJB 2.x. The legacy use case was something like this: maybe EJB won't always suck so you put your business logic in a service that gets injected, and you could replace your POJO implementation with an EJB without changing the dependencies.
I feel like the flexibility from dependency injection was overrated - think about how often during the typical lifecycle you make a significant tech stack change, and think about how much time you spend wading through all those extra layers of indirection and configuration to make a functional change. Also, these days with the proliferation of viable technologies, you are almost as likely to try something totally different (node.js, perhaps?) than to change out your ORM in isolation.
Yes, things are better today with annotations and better dynamic bytecode generation (e.g., no gratuitous interface with single implementation). Still it feels like dynamic proxies are a clumsy mechanism for providing services like transactions, when compared with frameworks that provide these capabilities through dynamic language features or closures. Given the choice, I think I'd rather go with a tech stack that makes it simpler and more efficient to address business requirement changes, even if it makes it harder to switch between EclipseLink and Hibernate.
With these full-stack frameworks, you need much less code to get something done, between the magic of dynamic languages, and the elimination of dependency injection . As a result it's easier to iterate rapidly as business requirements change, because there's fewer places to touch and fewer layers of indirection to sort through.
It made me wonder whether dependency injection in Spring and Java EE was intended to address a different kind of flexibility - flexibility to change out pieces of the tech stack. I feel like this kind of flexibility is still a hangover from EJB 2.x. The legacy use case was something like this: maybe EJB won't always suck so you put your business logic in a service that gets injected, and you could replace your POJO implementation with an EJB without changing the dependencies.
I feel like the flexibility from dependency injection was overrated - think about how often during the typical lifecycle you make a significant tech stack change, and think about how much time you spend wading through all those extra layers of indirection and configuration to make a functional change. Also, these days with the proliferation of viable technologies, you are almost as likely to try something totally different (node.js, perhaps?) than to change out your ORM in isolation.
Yes, things are better today with annotations and better dynamic bytecode generation (e.g., no gratuitous interface with single implementation). Still it feels like dynamic proxies are a clumsy mechanism for providing services like transactions, when compared with frameworks that provide these capabilities through dynamic language features or closures. Given the choice, I think I'd rather go with a tech stack that makes it simpler and more efficient to address business requirement changes, even if it makes it harder to switch between EclipseLink and Hibernate.
Written on November 24, 2013