There are two most common types of frameworks: server-side and client-side.
Server-side frameworks (SSF) run, as their name suggests – on the server, and are there to help with the business logic and data of your web application. They do database abstraction – ie. persistance, help with presentation – ie. templating and also with caching, authentication etc. They come in every flavor aka. dynamic language imaginable. Some come with their own webserver, as RoR or build on existing webservers in the same language (as the Java ones do) and some just come as a CGI which run in a “normal” webserver like apache or IIS. Speaking in terms of the MVC pattern, SSFs help with all 3 – the M, the V and C. Read the rest of this entry »
In response to the non-homogeneous landscape of implementations during the time of the browser-wars, developers started implenting client-side virtual machines to deliver “richer” interfaces to the customer. Among these VMs, also known as RIAs, are such notables as Adobe Flex/Flash/AIR, MS Silverlight and Java Applets.
Because of this obvious security risk, browsers employ (as already mentioned) a rigurous security model to disallow the code from doing anything besides alter the content of their current site (tab). RIAs, on the other hand, incorporate a lighter security model, which is why we’ve seen a spike in Flash-based attacks on browsers recently (keyword: drive-by-flash-attack).
Another drawback is the application downloading phase (termed ‘DA’ in the paper “Life above the service tier”). In a RIA this has to occur all at the beginning for the entire application, and the VM has to be started as well. This takes a considerable amount of time. In the early days that was one reason that no one liked flash, and still holds true for Java Applets. Whereas in plain HTML you can do that incrementally by loading each file consecutively which even enables you take advantage of caching or CDNs on the way from the server to the client – a huge advantage.
The only advantage that I can see in a RIA is that they obviously obfuscate the code, because applications for them are normally compiled – well to a bytecode, but still – thus preventing people from stealing your work or being able to look into your business logic (if you absolutely need to execute some of it on the client). While obfuscation is not as simple (automatic) in HTML/JS, it is still possible.
So, again, why run another VM inside, well what amounts to basically two VMs already – the OS and the browser, when current JS and browser implementations are now compatible enough (maybe w/ some help from tools such as GWT) so that you can realize anything with them? Even more so, considering that the internal scripting language of Flash (ActionScript) is actually Ecma-262 aka. EcmaScript, which also happens to be what JS is based on – in effect even the languages are the same.