Well, I said they "concentrate on", meaning all the examples I've seen mix application code with the HTMl like classic ASP. I didn't know AFP offered another option so thanks for that info.
It's just as simple to deploy a vfp mtdll. It's a simple matter to have the main app code in an external .prg that is not locked and can be replaced at will (AVFP 3 uses this technique) as well as the HTML templates which are never locked.
AFP still uses VFP background server processes which can be fast under small loads. However, they will not scale as well as a multi-threaded server. Yes, you could throw more hardware at it and get some good numbers, but, I wouldn't give this technique a high grade for efficiency when mtdlls are available...

>What you say above is not accurate. AFP3 allows you to place code in the .afp page, or in a .afp.code file (for each web page) or in application wide code file(s) so, no spaghetti, and you do not have to place any code in "dll or exe" to process in a "code behind" method. This make for massively easier deployment and debugging than having to recompile a Fox MTDLL. In AFP3, if you make a change to code, you only have to copy the new code file to the web server and the next time the page is executed, the page and the code is automatically re-compiled on the fly. Couldn't be simpler, its fast and it scales.
>>AFP and Foxweb concentrate on placing vfp code within the HTML like Classic ASP does. This is an older way of creating web apps that can end up being hard to manage (spaghetti code). ActiveVFP and wwc offer this way and the option to keep the application code in the dll or exe and process HTML templates. This is the more modern way and the way ASP.NET works (code-behind).
>