How Rails saves time vs J2EE from an architect's POV
These are my impressions so far
J2EE so far means Struts + Spring + Hibernate
Structure:
In rails the application structure is given. The hierarchy is very clean and simple (controller, model, view, helper). In J2EE there is a WAR structure, a JAR structure, an EAR structure, SAR, etc. All of these different structures take time to setup when you start a project. Also if every you decide to change the structure the refactoring can be a nightmare. Classpath problems, classloading order problems, etc.
Interpreted language:
The fact that the development -> test cycle is so short (like PHP) you can get in so many more development revs. This is huge. Now that projects are test driven anyway I'm wondering what the added value of a compiler is? If the project doesn't compile your tests won't pass anyway. By eliminating the compiler then the whole concept of "continuous integration" is inherant in the language. Why?
1. Source and deployment are one (ooohhhhmmmm). If there's no compiler then your source tree is your deployment tree. No big ant scripts that clean build directories, make build directories, compile, copy all those wonderfully huge and error prone config files, and then make them into WARs, JARs, EARs deployment structures.
2. Codetime and development runtime are one (breathe and repeat ooohhhhmmmmm). If the language is interpreted then there's no deployment. Waiting for the container to start or for Spring to lazily inject all of those dependancies the first time you access a service can take a 10, 20,... 40 seconds? No big deal, but when you do this 200 times a day it just gets developers into the habit of working sloooowwwly. In fact there's no need for that wonderful J2EE ointment Spring. Yeah! no seperate environments: one for development and testing without the container and one for the "real production EJB container" integration environment.
Convention over Configuration:
This just seems like a good design pattern or common sense to me. Like ordering a "Caramel Macchiato". Specifying Espresso with vanilla and caramel syrup on the foamed milk in a grid pattern just takes too long. And you'll probably screw it up so the "Barrista" will then have to ask you if again and you then have to repeat your order again. Imagine if everyone in line did this? The orders would be exact but it would be very confusing, there would be many errors, and it would take a long time. There would probably even be "order consultants" to help you speed your way and books written about how to order. Sounds a lot like J2EE.
So Rails makes it easy for the majority of people to get what they want fast and then let the few demanding types order custom [insert favorite Starbuck's drink here]. We can do this in Java but we don't. Why? The ethos is more about being able to customize and control everything and all possible future extendable combinations first then using Java to build applications.
J2EE so far means Struts + Spring + Hibernate
Structure:
In rails the application structure is given. The hierarchy is very clean and simple (controller, model, view, helper). In J2EE there is a WAR structure, a JAR structure, an EAR structure, SAR, etc. All of these different structures take time to setup when you start a project. Also if every you decide to change the structure the refactoring can be a nightmare. Classpath problems, classloading order problems, etc.
Interpreted language:
The fact that the development -> test cycle is so short (like PHP) you can get in so many more development revs. This is huge. Now that projects are test driven anyway I'm wondering what the added value of a compiler is? If the project doesn't compile your tests won't pass anyway. By eliminating the compiler then the whole concept of "continuous integration" is inherant in the language. Why?
1. Source and deployment are one (ooohhhhmmmm). If there's no compiler then your source tree is your deployment tree. No big ant scripts that clean build directories, make build directories, compile, copy all those wonderfully huge and error prone config files, and then make them into WARs, JARs, EARs deployment structures.
2. Codetime and development runtime are one (breathe and repeat ooohhhhmmmmm). If the language is interpreted then there's no deployment. Waiting for the container to start or for Spring to lazily inject all of those dependancies the first time you access a service can take a 10, 20,... 40 seconds? No big deal, but when you do this 200 times a day it just gets developers into the habit of working sloooowwwly. In fact there's no need for that wonderful J2EE ointment Spring. Yeah! no seperate environments: one for development and testing without the container and one for the "real production EJB container" integration environment.
Convention over Configuration:
This just seems like a good design pattern or common sense to me. Like ordering a "Caramel Macchiato". Specifying Espresso with vanilla and caramel syrup on the foamed milk in a grid pattern just takes too long. And you'll probably screw it up so the "Barrista" will then have to ask you if again and you then have to repeat your order again. Imagine if everyone in line did this? The orders would be exact but it would be very confusing, there would be many errors, and it would take a long time. There would probably even be "order consultants" to help you speed your way and books written about how to order. Sounds a lot like J2EE.
So Rails makes it easy for the majority of people to get what they want fast and then let the few demanding types order custom [insert favorite Starbuck's drink here]. We can do this in Java but we don't. Why? The ethos is more about being able to customize and control everything and all possible future extendable combinations first then using Java to build applications.
posted by Lee at 1:24 PM
0 Comments:
Post a Comment
<< Home