"YES! You seem to have gotten a lot of disagreement here"
Yes and I am somewhat regretting stiring this up, but I understand it, I was on that side of the fence for a long time, until I was dragged over to the other side.
The other posters are being very pragmatic, and that is a good trait to have. The problem is that we are creatures of habit and when we find something that works no matter how efficient we are hesitant to discard it.
I will tell you that when rich internet applications first came into popular use, I was one of the biggest detractors for the exact reasons that I am defending it's use today.
My initial reaction was that we have just added more convolution to the mix of technology soup that ASP, JSP, PHP have become. Now, not only does a developer need to know a server model but they have to understand a client model.
I thought to myself this is the worst of both worlds. It was not until someone more visionary than I, explained to me my wrong headed thinking. In that you have to abandon the server model for the picture of rich internet applications to become clear.
In the end we have had years of indoctrination to a certain model and it is hard to reason outside of that known reality. I was one of the most guilty of doing this, given that I have been doing this since the beginning.
"To all the doubters, you need to open your mind about this. I'm guessing most of you just don't like JavaScript"
This is a huge concern that I see time and time again, but what is funny is that this liberates the technology selection for so many other systems. No longer do I have to worry about trade-offs like Rails is faster to market but Java has a bigger library. With this form of architecture those decision decoupled. Services can be implemented in whatever language best fits the problem domain. You can use one or you can use many, it is a choice of each development house. Further, you can chose to third party provide whole sections of your application. This works very well at Google some systems are provided in python, some in Java and yet other are implemented in that team of choices language.
As for JavaScript as of now this is a limiting reality. Many of the browsers are working on alternative languages and there are converter that will allow you to write Ruby or Python or whatever and have it converted into JavaScript. But the reality is, yes web client programming is done in JavaScript. For me, it is not a big deal, as I find that UI development is best supported by a rapid prototyping language and JavaScript fits the bill. I am continually amazed at the flexibility of the language. Conversely, I prefer strong typed languages for services.
Yes and I am somewhat regretting stiring this up, but I understand it, I was on that side of the fence for a long time, until I was dragged over to the other side.
The other posters are being very pragmatic, and that is a good trait to have. The problem is that we are creatures of habit and when we find something that works no matter how efficient we are hesitant to discard it.
I will tell you that when rich internet applications first came into popular use, I was one of the biggest detractors for the exact reasons that I am defending it's use today.
My initial reaction was that we have just added more convolution to the mix of technology soup that ASP, JSP, PHP have become. Now, not only does a developer need to know a server model but they have to understand a client model.
I thought to myself this is the worst of both worlds. It was not until someone more visionary than I, explained to me my wrong headed thinking. In that you have to abandon the server model for the picture of rich internet applications to become clear.
In the end we have had years of indoctrination to a certain model and it is hard to reason outside of that known reality. I was one of the most guilty of doing this, given that I have been doing this since the beginning.
"To all the doubters, you need to open your mind about this. I'm guessing most of you just don't like JavaScript"
This is a huge concern that I see time and time again, but what is funny is that this liberates the technology selection for so many other systems. No longer do I have to worry about trade-offs like Rails is faster to market but Java has a bigger library. With this form of architecture those decision decoupled. Services can be implemented in whatever language best fits the problem domain. You can use one or you can use many, it is a choice of each development house. Further, you can chose to third party provide whole sections of your application. This works very well at Google some systems are provided in python, some in Java and yet other are implemented in that team of choices language.
As for JavaScript as of now this is a limiting reality. Many of the browsers are working on alternative languages and there are converter that will allow you to write Ruby or Python or whatever and have it converted into JavaScript. But the reality is, yes web client programming is done in JavaScript. For me, it is not a big deal, as I find that UI development is best supported by a rapid prototyping language and JavaScript fits the bill. I am continually amazed at the flexibility of the language. Conversely, I prefer strong typed languages for services.