Scrum nie ma nic wspólnego z fullstackiem, no może prawdopodobnie oprócz tego, że usłyszałeś o nich w podobnym czasie. Ja sam jestem full-stackiem od zawsze (robiłem GUI webowe, w Swingu, piszę zapytania SQL, skrypty bashowe, ale przede wszystkim tworzę backend), ale z frontendem idzie mi dość słabo, podobnie zresztą jak i kolegom fullstackowcom z zespołu. Bycie ekspertem we wszystkim jest po prostu niemożliwe, bo czas nie jest z gumy. Dalej też nie widzę zysku z wciskania jednego badziewnego języka we wszystkie możliwe miejsca. SQLa na pewno nie zastąpisz JavaScriptem - zresztą znajomość składni SQL jest najmniejszym problemem, gdy pojawiają się problemy z bazką. Najwięcej czasu zajmuje ogarnięcie tego jak baza optymalizuje zapytania i odpowiednie dostosowanie zapytań, indeksów i struktury bazy danych. Podobnie z GUI webowym największym problemem zwykle nie jest JavaScript, a CSS czyli wiecznie rozjeżdżająca się strona.


No to chyba w Sunie pracowali cudotwórcy marketingu - wybierz JSF, a zajedziesz 10x więcej serwerów! Ta perspektywa na pewno pomogła Sunowi sprzedać tuziny serwerów.
A tak na poważnie to JSF jest zasobożerny dlatego, że jest serwerowym frameworkiem stanowym, a programiści rzadko kiedy staraja się zoptymalizować rozmiar stanu. Przez to rozmiar pojedynczej sesji puchnie i cierpi na tym skalowalność. JSF powstało 2 lata przed jQuery, nie mówiąc już o popularyzacji SPA, które nastąpiło lata później. Dzisiaj stan trzyma się u klienta (w przeglądarce), a to oznacza znacznie mniejsze problemy ze skalowalnością GUI. 100 MB stanu na sesję to dzisiaj niewiele jeśli sesja trzymana jest w przeglądarce (taki Chrome 100 MB zjada na starcie). Jeśli jednak na serwerze trzymamy 100 MB sesji na użytkownika to zaledwie 10 aktywnych sesji naraz oznacza 1 GB zajętej pamięci po stronie serwera.


Przejrzałem historię procesorów SPARC i żadnego specjalnego wsparcia dla bajtkodu Javowego nie znalazłem. Nie dość, że masz wiedzę przestarzałą o 16 lat to jeszcze nie wiadomo czy ci się to w ogóle nie przyśniło. Z tego co teraz udało mi się znaleźć wynikają zupełnie odwrotne wnioski do twoich. Jeden z eksperymentów Suna to MAJC https://en.wikipedia.org/wiki/MAJC czyli procesor zupełnie nieprzystosowany do wykonywania bajtkodu Javowego (jeszcze mniej niż x86, bo VLIW wydajność opiera na wykonywaniu wielu instrukcji jednocześnie, a to stoi w zupełnej sprzeczności z ciągłymi operacjami na stosie), ale strategią Suna było JITowanie bajtkodu do specyficznej dla danej wersji procesora architektury VLIW. Innym projektem jest PicoJava https://en.wikipedia.org/wiki/PicoJava ale to jest rozwiązanie do systemów wbudowanych, gdzie pełnoprawnego JITa się nie zmieści.


Wykonywanie funkcji z biblioteki z kodem natywnym to zupełnie inna rzecz niż JITowanie Javowego bajtkodu. Jeśli piszę w C++ i dołączam bibliotekę DLL to kompilator też mi magicznie nie podmieni konwencji wywołania. Sama konwencja wywołania funkcji to też jeden z mniejszych problemów podczas wywołań JNI. Największym problemem jest to, że pamięć jest zarządzana i to uniemożliwia swobodne przekazywanie referencji do obiektów z kodu Javowego do kodu natywnego. Wyjścia są (co najmniej) dwa. Jedno to blokowanie odśmiecacza pamięci na czas wywołania JNI - wtedy mamy pewność że GC nie przemieści nam obiektu. Drugie rozwiązanie to alokowanie dodatkowej pamięci poza stertą zarządzaną przez JVMa i kopiowanie danych w tą i w tamtą. Oba rozwiązania są kosztowne. Z drugiej strony powstaje jednak rozwiązanie, które pozwoli na zredukowanie narzutu na wywołania kodu natywnego, a nawet na inline'ing pomiędzy bajtkodem Javy, a bitkodem LLVMa. Rozwiązaniem tym jest GraalVM/ Sulong: https://github.com/graalvm/sulong . Z benchmarków wynika, że Sulong osiąga średnio jakieś 70% wydajności clang -O3 i to mimo tego, że Sulong sandboxuje bitkod LLVMa, tzn wprowadza wszędzie sprawdzenia wskaźników tak by kod LLVMowy nie nadpisał nie swojej pamięci (bo to naruszyłoby bezpieczeństwo JVMa, który zresztą zachowałby się nieprzewidywalnie).

Mówię tylko z własnego doświadczenia