API Chrome (“chrome.”*) udostępniane rozszerzeniom, których część programowa jest w języku Javascript, zostało oparte na technice procedur ‘callback’ (zwykle anonimowych, definiowanych w miejscu użycia). Funkcje w typowych technologiach programowania wykonywane sekwencyjnie, tutaj są wieloma procedurami API tylko wywoływane, ale bez gwarancji zakończenia. Dlatego dla niezawodności programu rozszerzenia konieczne jest zawsze używanie udostępnionego argumentu na funkcję wykonywaną po zakończeniu polecenia, gdzie definiuje się dalszą część programu przez zagnieżdżenie, nie wpisując już żadnej instrukcji po takiej instrukcji w tym samym bloku strukturalnym Javascript.
Więc z powodu niedostępności procedur synchronicznych dla wykonywania funkcji, które są konieczne do wykonania normalnie, sekwencyjnie — została utrudniona składnia programowania rozszerzeń Chrome. Natomiast można wygodnie używać znanego z Javascript automatycznego zarządzania pamięcią zmiennych (dynamicznych), w szczególności podczas przenoszenia danych pomiędzy stronami ‘html’ rozszerzenia. Ponadto zastosowano pewien system grupowego ograniczania uprawnień, który w rzeczywistości jest dość prosty do ominięcia przez stosowanie przenoszenia danych pomiędzy stronami ‘html’ rozszerzenia i stronami ‘www’. Użytkownik jest pytany tylko podczas instalacji rozszerzenia o zezwolenie na grupowe uprawnienia, ale i tak zwykle nie wie, co naprawdę dane rozszerzenie robi, bez zaawansowanej znajomości technik programowania wymaganych do pisania tych rozszerzeń, a mimo znajomości — i tak API wprost wymusza stosowanie składniowych karkołomnych zagnieżdżeń i przepływu danych typu ‘broadcast’, więc nie da się rozważać ścieżek wykonania cudzego programu, ponieważ trzeba by rozważać ścieżki zapętlania, co jest wynikiem błędnej (źle rozwiązanej mimo usiłowań) architektury.
Stąd można przewidywać, że rozszerzenia pisane do przeglądarki Chrome będą oczywiście wykonywać potrzebne użytkownikom funkcje, ale wraz z końcem Chrome wymrą wszystkie algorytmy tych rozszerzeń — nie z powodu utraty platformy wykonywania, ale z powodu utraty konieczności wymyślania składniowej implementacji wobec już istniejących języków programowania, które nie wymagają składniowej gimnastyki do wykonania tego samego. Te ‚algorytmy’ używane w pisanych rozszerzeniach Chrome nie są czymś potrzebnym, ale są wymagane dla błędnego formalizmu składni, która nic nie daje, a utrudnia. Dlatego nie będę pisał rozszerzeń Chrome dla innego celu niż z konieczności używania czegoś właśnie w tej przeglądarce ‘www’ (a nie w samodzielnym programie) oraz będę starał się stosować centralizację rozwiązań wbrew zaleceniom dla programistów, ponieważ dzięki temu będę mógł scalić wiele drobnych rozwiązań w jednym rozszerzeniu z centralizacją funkcji usługowych i obsługi danych, z jednorodnym formatowaniem graficznym oraz oszczędnością pamięci operacyjnej przeznaczanej na odrębne rozszerzenia.