A good friend and colleague sent me this article, and it describes very well the difficulties that a UI guy has to live with. I do agree with most of it, but also i have to add that not all the front-end developers have the skills to fulfill the position. Sometimes a developer become a front-end developer because that’s where the wave took him, bot because you like been a UI guy (developer, architect, engineer or designer). To be a good UI guy, you have to love it, its not just about the coding skills, but you have to have many other “talents”, the more he has the better. I see it like, you might be able to learn how to sing, but a singer was born with that talent, he love it and it comes natural he can definitely improve, but he has it,  as well as a good web designer was born with that good taste, common sense, good visual prospective that let him make everything look good for most of the people, or the same as a good developer was born with the ability to see functions, methods and classes as objects flying and connecting to each other on his mind. Now on this article Paul Carvill is talking about the hard to find developer that can do all that alone, there are really good ones out there, but they definitely not easy find. So i thing is very important what he say at the end:

“Know your value
What does this mean if you’re a front-end or client-side web developer? Know your value. What are your skills? Are you a developer, an engineer, a User Experience architect or an Interaction Designer? Advertise your value. Shout about it. Don’t be knowingly undermined or ignored. Create a User Experience team within your business. If they’ve already got one, join it! Your job is incredibly important, and your present employer needs to realize that, as they stand to benefit.”

When a developer was born with the web application mind set, is not that easy to move to a Rich Internet Application architecture. Is hard to make that change because they are way too used to stuff the request with data, to then be able to write it to the client browser as HTML and keep the state on the server side session.
When I say Rich Internet Applications, I am not just talking about Flex, there are some other JavaScript/HTML frameworks that provides some type of RIA architecture, for those that have been using something like that or any other type of desktop applications, this stateful client might sound familiar.
Because right now I have been working with JSF I always use it as an example to compare standard web applications with RIA, but it would be the same with Struts or any other web development framework, so for example:
When you have a JSF application, the only thing that the final user will get to his browser will be html pages, some JavaScript files, images, images, etc. But that’s it, nothing else. The user will click a button that will submit the whole page,  then the JSF servlet will get the request, execute the life cycle, then execute the action where the developer will have some logic and then the response will be sent to the client as another html page. After all this, the only thing that the user will see is a flashing on the screen, coming back with another page, but we all know that a lot of things happened during that time, and the most important thing that we want to point here is that we managed the transaction on the server, leaving the data and everything related to that current user instance on a server side session, sending to the client ONLY the data needed to manage that next screen transaction, all the screens, data and resources are stored on the server, and if something is needed, we have to make a call from the client to the server to get that something.
Now, in a Flex application is totally different, when we build a Flex application everything will get packaged on a single .swf file, which is basically the same type of file that you load when you go to a flash website. Inside that file you typically will have everything needed by the client, screens, resources, and sometimes even static data. So this is basically going to perform better than a typical web application because the transactions will be less expensive, we are not sending the whole page back and forth, we are going to query the server only for data, so the request/response will be faster, then that data will be stored on the client, changed, manipulated, then when is ready, will be sent back to the server, not that the state will be on the client not on the server. Some people claim that this will make the application chatty, but I don’t agree, is the same kind of problem you will have with any other web application, if is not well designed and well coded, then yes, any application can become chatty. With the appropriate RIA framework as Flex and good design, the performance and usability of this type of application will be dramatically improved.
If you are a  JEE, interested on Flex, one thing i will tell you, you have an advantage because currently Flex developers have realize that in Java we have been sucessfull with our patterns, so you will find a lot of things that will sound familiat to you, like DTO, VO, Proxy, etc, so I would suggest you to start with the basics of flex and actionscript, then jump to BlazeDS that will give you the ability to communicate with your serverside objects, take a look at the Cairngorm (I get it was not a marketing person that named that framework ) that seems to be a good option if you are planning to use it on a large applications, the only thing that I don’t like about them is that they are following the command event pattern, that at the end it might lead you to a lot of files because you have to have one class per command button ( I am working on another way to do that, so I will be posting later about it), and take a look at the DAOFlex that give you and idea of how this work.
If you have any question do not hesitate to write me.