Ubermacht

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

23 года? И столько тлена в словах? Ну ловите мою кулстори, у меня тлена в 23 было куда больше...
Чуть менее двух лет назад, летом 2013, мне было 23, и я имел НОЛЬ опыта работы (если не считать 2 месяца стажерства в магазине комп техники по практике от универа). Кое-как устроился seo-шником в местную веб-студию, даже не зная что это за работа, во время отправления резюме (гуглил после уже). Конечно, как только приступил к работе, сразу понял что seo это не мое, но это помогло мне через 3 месяца на том же месте стать веб-джуниором. И вот я стал джуном, имея за плечами 4 курса на codecademy и одну, плохо прочитанную, книгу. С космической зп в 12к рублей! Через 5 месяцев я уже приступил к работе по удаленке с другими людьми, где платили 30к, и при этом можно было работать по 15-25 часов в неделю. Это позволило мне читать все интернеты на тему фронтенда, а потом, самое важное, пилить демки на кодпене, засиживаясь до ночи. В марте уволился, отдохнул, и в апреле начал очень лениво заполнять профили на зарубежных фриланс биржах. А потом на меня внезапно свалилось подобие сарафана из-за моих демок, и люди просто стали писать мне с предложением что-нибудь запилить, хотя профили я так и не запилил на биржах. Сейчас пилю 2 проекта, с рейтом в 30$/h, для клиентов пустяковая цифра, а для моего Архангельска это вообще какой-то криминал :)
Ну а вам, с вашим имеющимся бэкграундом, вообще не знаю чего бояться. Проблемы могут быть, только если окажется что программирование это "не ваше". Если же вы любите это дело, то просто садитесь, и начинайте пахать. В первую очередь на свое саморазвитие, поначалу я бы даже посоветовал искать что-то с удобным графиком/местом работы, ибо "неудобная" офисная жизнь убивает весь энтузиазм как правило. А без энтузиазма на старте никуда не уехать.

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

Значит заходите на hh и отфильтровываете вакансии по городу. Выписываете контакты десятка самых крупных фирм. Только не вебстудий всяких. Пишете в каждую письмо с предложением работы у них с предварительным периодом обучения на понимежном окладе. Профит.

Крупные фирмы очень часто выращивают себе сотрудников т.к. это часто получается выгоднее, чем искать сеньора с завышеной самооценкой. Например в головной офис Тандера требуются разрабы на питоне и яве.

Мне тоже 23 года. Без профильного образования. Первую работу (три года назад) нашел без проблем. Начал с 25к, через 5 мес получал почти 40к, на том же месте. Сейчас получаю 80к, но уже в другой фирме.

Я вас понимаю, у меня тоже был психологический барьер чтобы начать. Думал, что я дурак и ничего не знаю. Потом жизнь приперла, срочно понадобились деньги - за 4 дня устроился программистом. А как потом оказалось, я знал больше своих коллег. Это я к тому, что разработчиками работает куча балбесов без вменяемых навыков и не парятся. Если у вас есть желание учиться и развиваться, скажите об этом потенциальному работодателю. Этот вариант будет выгоден и вам и ему.

Понятно, что первые полгода о зп в 50к говорить не приходится. Но стоит ужать свои расходы и пойти на этот шаг. Потому что в будушем (не таком далеком) это даст большой профит. За полгода усердной работы вы наберетесь достаточно опыта, чтобы нормально развивать дальше свою карьеру. Сможете работать удаленно на другой горов или страну и получать много больше, чем могли бы в Краснодаре.

1 Я называю таблицы в единственном числе, как и модели.
пример
blog_post
blog_category
blog_category_many или по фен-шую blog_category_pivot в общем любая many_to_many таблица заканчиваться на pivot
И еще, если это таблица относиться к блогу вначале всегда будет идти будет blog_ , так легче потом ориентироваться по БД.

Связи как меня учили манахи, которые часто используються в моделях я выношу в trait

UserRelationshipUserId
User что я в этой связи получаю Relationship - говорит мне что за трейт UserId по какому полю я получаю User модель

Большая чать роли как говорил мне сенсей являеться поддержка phpdoc в комментариях для IDE

<?php
namespace app\models\traits;
use app\models\User;

/**
 * Class UserRelationUserId
 *
 * @package app\models\traits
 * @property \app\models\User $user
 */
trait UserRelationUserId
{
	/**
	 * Relationship get user
	 * @return \yii\db\ActiveQuery
	 */
	public function getUser()
	{
		/**@var \yii\db\ActiveRecord $this */
		return $this->hasOne(User::className(), ['id' => 'user_id']);
	}
}

4 Обычно из CRUD я использую только генерацию модели, так как ручное создание кода модели с нуля тратит мою чакру в пустую)

Есть развернутый ответ для С++ кода, но его можно обобщить и на другие языки и платформы:

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

1) Важно понимать, что алгоритмическая оптимизация практически всегда может дать лучший эффект, чем программная. Так, если алгоритм имеет сложность O(n^2), то на больших исходных данных он при любой оптимизации будет медленнее, чем неоптимизированный алгоритм сложности O(n). Впрочем, при выборе алгоритма, опираться только на его сложность не стоит: если объем исходных данных не велик, то вполне может оказаться, что алгоритм со сложностью O(n^2) будет работать быстрее, чем с O(n).
2) Очень важно повторное использование (кеширование) промежуточных данных, вычисленных в программе – ибо быстрее всего выполняется работа, которую не надо делать. Тем не менее, не надо чрезмерно кешированием увлекаться – если объем кэшируемых данных слишком велик, то это может отрицательно сказаться на общей производительности программы (некоторые данные быстрее вычислять на лету, чем считывать из памяти).
3) Следует избегать излишнего копирования данных (например, передавать сложные типы данных по ссылке, а не по значению).
4) По возможности следует избегать условных операторов во вложенных циклах. Так как условные переходы, вызываемые такими операторами, плохо обрабатываются современными процессорами с конвейерной архитектурой.
5) Данные в памяти, которые используются алгоритмами, должны по возможности лежать упорядочено, и использоваться последовательно. Это позволит процессору их эффективно кешировать. Важно помнить, что доступ к кэшу процессора значительнее быстрее, чем к оперативной памяти.
6) Если алгоритмы это позволяют, то возможно стоит реализовать их параллельное исполнение (в отдельных потоках или процессах). Это позволит эффективно задействовать современные многоядерные процессы.
7) В некоторых случаях (например обработка изображений) большого эффекта можно достичь применением специализированных расширений процессора (SSE, SSE2, AXX, AVX2 и другие). Стоит отметить, что большинство современных компиляторов (GCC, MSVS, ICC) поддерживают непосредственное использование данных расширений непосредственно из С++ кода при помощи специальных встроенных функций (intrinsics). Минусами такого подхода является потеря переносимости (впрочем, эта проблема решается наличием разных веток программы под разные процессоры) и значительное усложнение программы.
8) Также большого эффекта можно достичь применением специализированных ускорителей, например GPU (технологии CUDA, OpenCL). Минусами таких решений являются потеря универсальности и значительное усложнение программы, а также то, что на специализированных ускорителях, как правило, хорошо работает далеко не каждый алгоритм.

Все ответы есть в интернете:
основы - likbez-net.ru/po-tu-storonu-brauzera.html
основы ajax - javascript.ru/ajax/intro
Откуда ответ, да, это AJAX.
А стоит ли переводить, зависит от отношения затраченных средств к прибыли, полученной от перевода.