| Languages like PHP and others make this distinction harder, especially for new programmers because it blends the client part and the server part into one jumbled mess and it takes programmers a while to realize when and where different parts of their "page" are executed. |
So very true. When I was at cayen, and we were first starting development of the Web version of our flagship app, we brought in the guy who was the main developer of the access version of the app.
He had the hardest time figuring out when everything is being run, loaded, displayed, and that was before ajax was commonplace. After about two weeks, he realized he couldn't hack it (har har), and gave up trying to do web development.
It's an odd beast, and for us, it makes sense, only because we've been around it so long. But the idea that you have the server process and format the server-side stuff, then send it to the client, which renders it in the new order of the formatted code, then you have the onready event (with jQuery anyway), which doesn't guarantee that the other images have loaded yet, then the onload event once everything's loaded. And after all that, you have ajax to further muddie it up.
It's confusing as shit when you try to explain it to someone who doesn't get how the web works.
Websockets should bring a pretty reasonable change to how the web works, and make it a little nicer to work with.
But I still like web development (I'm having a lot of fun with Erlang for web development, too).
Web *design* on the other hand, ugh, no thanks.
----
Do it for the Lobster
