Разверну мысли по поводу уместности Java™ внутри браузера.

* идею Java извратили паковкой в JAR

Изначальная идея была такова, что Java-апплеты (приложения) загружают свой код не весь целиком, а по мере востребованности байткода. То есть приложение начинает работать ДО того, как загрузился последний в списке .class-файл. Так как не все функции в приложении востребованы пользователем, то незачем грузить неиспользуемые .class-файлы, что и было реализовано в первоначальной модели распространения апплетов.

Из-за накладных расходов на открытие HTTP/1.0-соединения на каждый затребованный апплетом .class-файл вынуждены были пойти на паковку ВСЕГО клиенского Web-приложения в один файл — сначала в ZIP, потом в JAR с метаинформацией для запуска.
Это убило сразу три возможности:
1) динамическую кодогенерацию верифицированного и проверенного байткода на сервере "по запросу", которая сейчас дана на откуп всяким GWT, которые генерируют медленный интерпретируемый JavaScript;
2) иметь только необходимый байткод на клиенте в кэше браузера, включая части системного кода, а не отдельно установленную JRE с огромным rt.jar;
3) модуляризацию байткода "из коробки" в конце 1990-годов, которую безуспешно пытается сейчас достичь проект Jigsaw.

В свете появления Web-сокетов накладные раскоды на подгрузку очередного затребованного .class-файла ничтожны. Необходимость паковки байткода и ресурсов в JAR-файл отпадает.

* технология опорочена неэффективной JVM

Изначально не было в рекламируемых JVM JIT-технологии трансляции, она была только у Microsoft и позднее появилась в Sun JRE. Из-за этого, а так же из-за долгого старта JVM в качестве плагина к браузеру, пользователи чувствовали тормоза Java-приложений. Они видели замедленную реакцию интерфейса на события мыши и клавиатуры. Отсюда пошла стойкая неприязнь к Java на клиентской стороне.

Заранее запущенная JVM в составе браузера может нивелировать впечатления о работе клиентского байткода. Эта аналогия обоснована примером выполнения интерпретируемого динамического JavaScript внутри движка V8. Байткод статически-типизированного языка выполнялся бы гораздо быстрее.

* апплеты подложили бомбу замедленного действия под клиентскую Java

Апплеты ни дизайном, ни функционалом не вписывались никуда. Они не могли интегрироваться в рабочую среду, так как представляли собой невозможный с эстетической точки зрения концепт приложения "окно-в-окне".