Здравствуйте. У меня лично вопрос по Javascript. Даже несколько. Я только начал его изучать (будучи программистом C++), и есть непонятные мне вещи.
1. Как осуществляется выгрузка объекта из памяти?
2. Как обрабатываются исключения?
3. Как создать точку останова, чтобы нормальным отладчиком по коду, выполняя его по шагам?..

1) Этим вопросом занимается garbage collector в автоматическом режиме без участия программиста. От программиста единственное что следует сделать, чтобы при следующей автоматической сборке мусора объект был удален из памяти - это освободить данный объект от всех ссылок любого вида на него.
2) Синхронные операции через классический try catch. Асинхронные исключения - через специальное API браузера при участии той или иной команды. Например в промисах - это 2 параметр команды then(paramFunc1, paramFunc2). В иных случаях исключение тупо валит код и светится красным предупреждением в консоли браузера или иной среды окружения
3) в любом месте кода вписываете специальное ключевое слово debugger; - и запускаете код, предварительно открыв консоль. Интерпретатор, дойдя до этой точки остановит выполнение кода, а дальше с помощью кнопочек браузера вы сможете пошагово отследить все характеристики выполнения кода (стек, замыкания, значения переменных и тд)

Это ключевое слово идёт в Production потом? Или программист перед сборкой обязан отыскать все места, где он его использовал, и удалить?

вы про debugger который тормозит код в конкретном месте?

Да, про него

да, идет в продакшен. Программист сам должен позаботиться о том, чтобы везде его стереть в коде.  ВОзможно, допускаю, программы сборщики можно настроить так, чтобы они вычищали данную инструкцию в автоматическом режиме. Но это надо спросить более опытных специалистов, кто с таким сталкивался.

Спасибо, но это очень странно, чтобы перед прожакшном надо было вычищать из программы точки останова. Неужели нет никакой глобальной директивы, определяющий, что вот этот билд - это дебаг, а вот этот - релиз? Чтобы хотя бы сделать что-то вроде
#ifdef DEBUG
debugger;
?

Да, вот эту идею которую вы указали - люди и используют. Оборачивают debugger  и другие служебные команды в if( ){ } .  А в условие if прокидывают переменную окружения, в котором запускается код. Условно говоря if(dot.env === 'development'){debugger;}

ПОсле этого, перед каждой сборкой заранее настраивается окружение на тот или иной тип сборки . 99%   - это SET ENV = 'development'  и запускается сборка. Не помню команды настройки окружения Unix  или переменных сред в винде - но общая схема такая есть и очень широко распространена

Эти вопросы на данном этапе развития JS уже сильно развиты и сильно автоматизированы. Я лишь подтвердил основную вашу идею, за счет которой это все крутиться в современном JS

В принципе, логично. Но вот язык JS же интерпретируемый, то есть, браузер видит весь код? И в теории юзер может в твой код залезть? А если ещё и debugger не убрал, сможет его дебажить?

Да. JS изначально позиционируется как клиентский язык. Будучи доставленной на устройство конечного пользователя - этот конечный пользователь, если он не идиот, - полный бог в вашей программе.

С трудом удерживаюсь от фейспалма... Есть ли хоть какие-нибудь защиты? Отдавать клиенту код на языке высокого уровня - на самом деле, гениально просто.

а зачем защищать код на JS? Я немного повис в ваших мыслях. Нет, средств защиты нет. Никакая обфускация, сжимание  не смогут его защитить от продвинутого пользователя.
ПРосто понимаете, JS - изначально разрабатывался не для работы с данными, а для того чтобы помогать красиво браузеру рюшечки выводить.

А если твоё приложение взаимодействует с сервером REST? Клиент может понять логику взаимодействия и совершить нежелательные действия, например, получить информацию и подготовить какую-нибудь атаку

поэтому основная защита всегда должна идти на сервере. JS лишь создан для удобства пользователя, чтобы ему подсказать, что он пароль вводит не на том языке для примера. Никогда серьезных защит на клиентском JS не было  и не будет.

Тем более ну во возьмем компилируемое приложение. Разве опытному спецу не составит труда его реверс-инженирить? Тоже клиент возьмет и прочухает всю логику взаимодействия с сервером.

А логику взаимодействия с сервером можно вообще узнать на сетевом уровне , например через wireshark. Знай -сиди - анализируй пакеты,  ответы заголовки, особенно если протокол без шифрования.

В общем если что-то ушло клиенту - априори никогда нельзя считать этот код недоступным и безопасным. Поэтому только сервер и только он отвечает за валидацию того, что к нему приходит

Если код написан на компилируемом языке, чтобы его реверс-инженерить, надо иметь огромный опыт и очень хорошо знать ассемблер. В JS же сможет разобраться практически любой студент или даже школьник

Ваша правда. Это так

Вы сейчас плюнете на JS махнете на него рукой, и будете подбирать какой-то другой язык программирования?  Вот ведь как я, расстроил человека =)

Я просто понял, что... Лучше останусь на плюсах. JS какое-то разочарование.
Но вот правда, вы работаете в банковской сфере, и у вас есть приложение, вылизанное, красивое. Хотите сделать его онлайн-версию.
И при этом отдаёте свой код под проприетарной лицензией фактически в лапы потенциального врага.
Не говоря уже о возможности плагиата ваших удачных решений

Гм, вы не спешите. Поспрашивайте еще кого-то. Одно мнение ничего не значит. Тем более я еще зеленый джун. Может кто-то, кто реально пишет приложения для банковской сферы на JS, вас переубедит..... Блин, простите банковское приложение на JS - 😂 до чего же забавно это звучит