дальше было не разумно минимизировать, время дороже обойдется

и это СПА

слово "дальше" тут кажется совсем не подходит
Неколько дней изучения webpack = require не нужен
jquery -> react/view

И в общем то останется только sip.js которй будет добавлять основного веса.
7.5 метра - много

ну в принципе если бизнесу норм то оно и норм

оно летает на малинках, смысла нету извращаться

а реакта я не знаю от слова совсем

как я уже написал -если бизнес боьлшего не требует то конечно норм

но просто я бы это не называл технологическим минимализмом

Это разное

Ну типа открываем хром и смотрим. Одна свежая вкладка — 200-300мб, со временем разрастётся до произвольных величин.

Где-то в пользовательском жаваскрипте утечки памяти. Типа знаешь, кто-то что-то не очищает что уже не нужно: всё равно ведь страницу обновят/закроют/перейдут по ссылке, так что и думать нечего. Поэтому висят тысячи неактивных таймеров (пока ивент не сработает), миллиарды объектов, прицепленных к каждому тегу в объёме двадцати штук, и т.д. Кто-то всего лишь сделал

$(".animated_shit").each(
 function(i){
   $(i).animate(
     function() {
       this.animate({opacity: "-=.1"})
     },
     500,
     function() { this.opacity: .5 }
   }
 }
)

Вот этот вот код, если что, нацепил на каждый элемент класса animated_shit минимум четыре объекта: таймер, табличку с данными и две функции. Вместо того чтобы выставить каждому по своему таймеру, но одни и те же две функции, чтобы хотя бы их не дублировать миллиард раз.

И такая практика в жаваскрипте — повсеместна. Создаём миллиард дубликатов на любой пук. А как же память? Да пофигу, не всё же время сидеть на допотопном пентиуме. Народ собирается открывать больше пяти вкладок? Пфф, просто пусть не открывают, это же просто!

Это всё равно что в ловке делать вот такое вот:

function newObject(x, y, hp)
 local obj = {x = x, y = y, hp = hp}

 function obj.move(vx, vy)
   obj.x = obj.x + vx
   obj.y = obj.y + vy
 end

 function obj.applyDamage(dmg)
   obj.hp = obj.hp - dmg
   if obj.hp <= 0 then
     obj.die()
     return true
   end
 end

 function obj.die()
   obj.setAnimation(death)
 end
 return obj
end

А потом наплодить миллиард таких объектов.

Так как все функции разные, каждая занимает свой участок в памяти, тут не происходит никаких оптимизаций. И никакой jit не поможет, потому что функции разные, несмотря на как бы идентичный байткод.

Карочи, проблемы памяти в браузерах, это в основном кеширование гуглхрома и кривой жаваскрипт.

В общем, не знаю, куда податься, гугел не помог, так что спрошу тут, может кто сталкивался с подобным: у меня полностью пропало окно, появляющееся перед закрытием упавшего приложения, в котором можно было бы подключить отладчик к приложению и посмотреть, что да где упало. При краше просто у курсора появляется кружок загрузки и через полсекунды примерно приложения уже как-будто и не было. В итоге теперь, если я хочу отладить свой луёвый модуль, мне приходится запускать интерпретатор через WinDbg или же студию аттачить к процессу луёв и тогда уже приложение не просто так тихо закроется, а запусится процесс отладки. Когда это началось я не заметил, но предположительно после переустановки винды с дестяки 16го года на самую последнюю версию, редакция Home, образ официальный, взят у мелкомягких

И да, так не только с луями, в тихую у меня падает вообще любое приложение

Проверку системных библиотек на предмет повреждения тоже запускал - ничего не дало, все они целы

Хе, у меня было подобное когда я писал, например, такое:

lua_newtable(L);
lua_pushnumber(L, 10);
lua_rawset(L, -2);

Так что крайне советую глянуть вот это вот:
https://www.lua.org/manual/5.1/manual.html#3.6

3.6 – Error Handling in C
Internally, Lua uses the C longjmp facility to handle errors. (You can also choose to use exceptions if you use C++; see file luaconf.h.) When Lua faces any error (such as memory allocation errors, type errors, syntax errors, and runtime errors) it raises an error; that is, it does a long jump. A protected environment uses setjmp to set a recover point; any error jumps to the most recent active recover point.

Most functions in the API can throw an error, for instance due to a memory allocation error. The documentation for each function indicates whether it can throw errors.

Inside a C function you can throw an error by calling lua_error.

(лично я отлаживаю всё это логами: пока тестирую, пишу в файл этапы и смотрю точку падения, после чего фиксю её, дебаггеры нинужны, кек)

Дело в том, что так не только в луях, а вообще везде