Никита Геннадич

Тут можно шрифт загрузить и посмотреть все символы внутри https://fontdrop.info/

В одну строку и без зависимостей это делается так:

<input type="text" onkeydown="this.style.width = ((this.value.length + 1) * 8) + 'px';">

На Ваш вопрос нет однозначного ответа. Аналогично вопросу: что быстрее, поезд или автомобиль? Кто то будет сравнивать советский поезд с бугатти, другой будет сравнивать японские скоростные поезда с жигуленком.

Базы с поддержкой SQL бывают разные: MySQL, MsSQL, Oracle и т.д. У каждой из них своя методика работы с кэшем, индексами, памятью. Очень многое зависит от размеров базы, размеров таблиц, построения индексов, самого запроса, настроек сервера БД и операционки. Если база нормально сконфигурирована, таблицы с нормальной архитектурой, правильно построены индексы, сервер обладает достаточным количеством памяти, то запрос будет быстрее большинства самопальных решений для работы с файлами.

Если же файлы проектировала группа высококлассных специалистов, обвязка спроектирована именно под такие запросы, то выигрыш по скорости может быть значительным в этом варианте. Но такой "путь самурая" предполагает перенос объема вычислений в более быструю область сервера: память-процессор. У тебя будет меньше работа с дисковой системой, но вся логика работы приложения должна быть перелопачена под такой вид данных. Без фундаментальных знаний алгоритмов программирования и математики-информатики в целом, такие велосипеды лучше не городить. Теория графов, матрицы, хеши, алгоритмы сортировки должны быть у тебя на уровне выше институтского. Про удобные таблицы на 5-10 полей можешь забыть. У тебя будет куча небольших упорядоченных файлов со списками ключ-значение. Индексы, хеши, хеши по хешам, индексы по хешам и т.д. - это на долгое время будет твой кошмар, который ты должен будешь представлять у себя в голове. Работа с файлами напрямую не имеет смысла, если ты не планируешь создавать высоконагруженное приложение с большими объемами данных. В этом случае у тебя проработка архитектуры хранения данных займет на порядок больше времени, чем проработка архитектуры базы. Предварительный поиск по одному символу, по двум, трем, ссылка на файлы, которые содержат следующую часть, по которой уже идет поиск. Не забудь блокировки файлов, обработку ошибок доступа, обработку оборванных транзакций, уникальность значений, индексов или ключей и т.д. Отсутствие удобных select-ов с join-ами и блэкджеком потребует от тебя проработки возможных видов запросов, чтобы сам вид хранения данных оптимизировать под кастрированные возможности. А из запросов будут только аналоги простейших "SELECT xxx FROM file_yyy WHERE Id=zzz", "UPDATE file_xxx SET yyy WHERE Id=zzz", "INSERT INTO file_xxx yyy=zzz", "DELETE xxx FROM file_yyy WHERE Id=zzz". Этими 4-мя операциями тебе придется обходиться.

Сейчас есть уже готовые "велосипеды" noSQL, но это не "путь джедая". Типовой сайтик, с десятком или сотней уников в час не стоит такого геморроя.

У меня рабочая схема, без form выглядит, не вдаваясь в детали, вот так:
HTML:

<div>
@csrf{{--эта конструкция преобразуется в input c именем _token, пример: <input type="hidden" name="_token" value="tyiV5lsNJy9aA245dke7979aW1otyutV5D">--}}
<input class='text' type='text'>
<input type='submit'>
</div>

JQuery:

let someV = $('.text').val();
let token = $("input[name='_token']").val();
                $.ajax({
                    type: 'POST',
                    url: '/someurl',
                    data: {
                       '_token': token,
                        "someV" : someV
                    },
                    success:function (res){
                        console.log('F**k yeah');
                    }

                })

Надеюсь кому-нибудь поможет)

как вариант добавить в схему диод и электролит, диод в разрыв цепи между блютуз и аккумулятором, электролит поле диода параллельно блютузу, диод не даст усилителю вытянуть электролит, электролит даст питание блютузу на время просадки аккумулятора

Теоретически запараллеливать нельзя, на практике - в вашем конкретном случае можно.
Почему в теории нельзя? Потому что теоретически может случиться такой стереосигнал, когда по каналам будут выданы на выход строго противофазные сигналы. А это хуже чем КЗ, поскольку оба выходных каскада УЗЧ будут работать друг против друга.
Почему на практике можно? Да потому, то выходная мощность на наушнике - несколько милливатт, от такой мощности ничего не выгорит даже в наихудших условиях. Есть и вторая причина: вероятность появления вышеописанного опасного противофазного стереосигнала исчезающе мала. Чтобы он появился, это какой-то недоброжелатель должен совершить специальную диверсию против вашего усилителя - раздобыть стереогенератор, подключить, да ещё устроить всё это во время вашего отсуствия.

Пользуйся этим

css-loader - преобразовывает CSS - в модуль JavaScript.
(Входные данные: CSS, Выходные данные: JavaScript)
style-loader - внедряет CSS, экспортируемый модулем JavaScript, в тег