Problem tworzenia aplikacji internetowych. Można go zaatakować z dwóch stron – mamy tu do czynienia z klasycznym przypadkiem interakcji serwer-klient.
Od strony serwera poprzez stosowanie w wybranym języku serwerowym rusztowań (frameworków) które nie tylko stanowią owijkę dla dla jego języka (wprowadzają słynny model MVC jak np. PHP Cake lub bardziej złożony ale uniwersalny ZEND) ale DODATKOWO pozwalają również na wstrzykiwanie kodu do przeglądarki internetowej po stronie klienta przez co aplikjacja robi się bardziej reaktywna (np. EXT PHP, ZEND).
Od strony klienta działającego w przeglądarce internetowej który realizuje cały GUI po stronie klienta a dobiera sobie dane poprzez AJAX od serwera. Tutaj mamy uniwersalny ale niskopoziomowy AJAX, lub frameworki jQuery/EXT JS i inne, z dodatkami OO jak np. Javascript MVC.
Innym, ciekawym rozwiązaniem jest poleganie na narzędziach RAD, które w sobie mają wbudowane jakieś frameworki np. SENCHA lub Appcelerator (z przejętą przez niego Aptaną).
Innym zasługującym na uwagę zjawiskiem jest sytuacja w obszarze mobilnych urządzeń. Mamy tu powtórkę całej historii informatyzacji w pigułce. Najpierw tworzono aplikacje lokalne (w rozumieniu tego urządzenia) w językach które miały na danej zabawce swoją maszynę wirtualną np. Java VM (zubożona Java ME), rzadziej .NET i były to najczęściej gry. Później uległy zaawansowaniu systemy operacyjne tych urządzeń i pojawiły się aplikacje systemowo-narzędziowe chociażby przeglądarki internetowe. Pozwoliło to na wykorzystanie języków skryptowych tych przeglądarek (najczęściej Javascript) do tworzenia aplikacji w środowisku przeglądarkowym. A że przeglądarki uniknęły syndromu IE (chodzi o skarłowaciałe wersje IE 4/5/6 a nawet 7) i opierały się na bibliotece WebKit (Safari lub Chrome) lub Mozille (Firefox) z wersją HTML 5, moża było od razu wykorzystać AJAX i inne zaawansowane biblioteki jak jQuery, Dojo. Tutaj już następuje wyjście na świat zewnętrzny – dostęp do dowolnego serwera i technologii tworzenia aplikacji po jego stronie. Tak naprawdę przeglądarce było obojętne co jest TAM po drugiej stronie – komunikacja z nią odbywała się poprzez URI (początki REST). Teraz zaczęto wbudowywać w VM Jay wsparcie dla innych języków dynamicznym i mamy pełny wysyp języków znanych ze świata PC jak Ruby, JS, Python. Dzięki nim możemy tworzyć aplikacje lokalne i internetowe pomijając przeglądarkę internetową jako kontener runtimemowy czasu uruchamiana – framework dla Androida o nazwie S4A, Jednakże przeglądarka nie przestaje być atrakcyjnym pojemnikiem dla uruchamiania aplikacji ponieważ daje już na pczątek dwie ważne rzeczy deweloperowi: możliwość standardowego kontaktu z siecią internet (poprzez warstwę AJAX i inne, na niej zbudowane warstwy jak REST) oraz zunifikowany sposób wyświetlania danych poprzez GUI oparty na HTML5 obudowany w framework wizualizacyjny choćby jQuery Mobile lub zapeto.
Ażby usprawnić i przyśpieszyć działanie aplikacji próbuje się stworzyć taki system operacyny który ma wbudowaną przeglądarkę i języki skryptowe a nawet języki 3GL (kompilowalne) jak to ma miejsce w przypadku OS Chrome. I tu powtarza się sytuacja MS w latach powstawania Internetu, MS wbudował w OS wsparcie dla przeglądarki IE3 oraz języków skryptowych (JS), a potem został potępiony i musiał przeglądarkę odłączyć od niego.
