What are some of the barriers client-server developers face to understand Web applications/development? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

Would you guys mind to shed some light 开发者_如何学JAVAabout what are the difficulties that a client-server programmer faces (has to overcome) to be able to understand (and be able to move to) web application programming?

Think someone that has been writing windows forms client-server database applications for at least 10 years.

---

1. The nature of HTTP is such that a server won't just sit there and wait for a client's response. It can't. (ASP.net acts like it can, but that's an illusion/abstraction provided by the framework. Evidence: If IsPostBack.) Each HTTP request is separate from every other, so you must include enough information with each request to remind the server what it was doing. Session cookies help a bit here, but the main point is that once you need input, everything stops -- and the next request starts everything over again.

2. Most everything you'd do in a fat client will now be done on the web server. That is, one server (or two, if you count the DB server too) is doing most/all of the heavy lifting. That embarassingly slow solution that worked on the fat client is now using up CPU cycles that are shared between all the users. Keep performance and scalability in mind as secondary goals (behind getting stuff to work).

3. The app's UI is no longer directly under your control (unless you wanna be a jackass and demand IE6, in which case you won't be developing web apps for long). You'll need to test in a number of different browsers (at least the latest versions of FF and Chrome, and versions 7-9 of IE. Safari/Mac too if possible. More if you plan to support mobile phone browsers). And each one has its quirks. You'll want to stick to the lowest common denominator for stuff that has to work, and only use browser quirks for extra spiff. And don't try for pixel-perfect identicality in every browser. That way lies madness, especially if you have to support old versions of IE, phones, etc. Instead try for a layout flexible enough that small rendering differences aren't a big deal.

4. Almost by definition, you'll have times when you're working with 3 different languages at the same time (HTML, Javascript, and your server-side language) for two different environments (browser and server). You need to always be aware of when and where your code will run, and what limitations it'll have while it's there. There's a bit of a wall between server code and client code, and they don't share variables by default. If you need them to, you'll need to provide a way to do so.