Robur

Я хотел бы отдать предпочтение языку java, я так понимаю движок моей соц.сети (а это сайт), будет на java, остальные языки будут отвечать за разметку, как он будет выглядеть, где он будет находиться (серверная часть) и так далее, верно?

Хотите - отдайте. Писать можно на чем угодно.

Хватит ли этих знаний или моё представление ошибочно ?

ошибочно, не хватит. после изучения этого всего вам еще лет 5 изучения других вещей (целыми днями) чтобы построить хоть что-то нормально работающее. И лет 15 чтобы суметь это хоть немного "раскрутить".

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

А если возьмутся и начнут развивать дальше - то ставьте на них крест - у них не хватит навыка создать такую систему.

Нет "правильно" и "неправильно". Лично я раньше тоже убирал await, потом наоборот стал добавлять.
Не советуют потому что с точки зрения логики это лишнее слово.

Но, как говорится, есть нюансы. Если копнуть глубже - V8 оптимизирует return с await лучше чем просто return.
А так же конструкция с await дает лучший стектрейс. Еще что-то было в пользу return await, но я не помню детали. В блогах самого V8 или девелоперов его пилящих где-то была целая большая статья на эту тему, с раскладкой по всем деталям.

Поэтому, если вы видите return await не спешите говорит что человек написавший эти строки не в курсе как работает async/await, возможно он знает лучше вашего ;)

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

words = await Promise.all(newArr.map( async e => {
                            let newE = new Object(); 
                            newE.entries = await makeDictionaryTree(getEntries(e));
                            return newE; 
                        }))

ну или вместо newArr.map for сделайте, чтобы по очереди вызывались а не параллельно

Но мне кажется что это костыль. Как правильно решить эту задачу ?

поставить loading = false при начале загрузки картинок, и после загрузки поставить его в true. Как именно - зависит от того как вы их грузите.
так как загружаются они видимо где-то еще, то loading вам придется хранить в стейте приложения, а не компонента.

ts ругаеться и таких моментов море, где я пишу код не совсем как я хочу, а как меня заставляет ts

99% что у вас какой-то косяк и возможные проблемы (даже если вы запускаете и "оно работает").

Но вот внутри функции есть еще скажем такая промежуточная типизация(NodeListOf) с которой я не совсем согласен

вы можете быть сколько угодно согласны или нет, реальные данные от этого не поменяются. И тут или типы совпадают - и тогда тайпскрипт вам помогает в разработке, или нет - и тогда у вас проблемы.
конкретно в этой строке никакой тип ставить не надо - тайпскрипт и так знает что у вас там. пишите просто const allLinksOnPage = document.querySelectorAll('img')

Как вы считаете стоит ли типизировать вообще все?

да, кроме мест где типы крайне сложно написать а профита от этого мало.

Как человек, который прошел это же самое годы назад скажу вам так:

- первое что может быть - физиологическое нарушение мозга. Опухоли, склероз, разные заболевания, депрессия (настоящая а не вот "жизь что-то не радует"), разные паталогические состояния и другие штуки которые объективно влияют на его работу. Тут, если вы серьезно настроены, нужно сходить и проверить то что можно и пообщаться с грамотным врачом (как его найти - другой вопрос).

- второе - банальное утомление. Да, теперь вы устаете быстрее и легче и под это надо адаптироваться. В 20-25 можно не спать пару суток подряд, пилить код 20 часов не вставая, питаться одной кока-колой с дошиком и раз в неделю спать до упора, просыпаясь как огурчик. После 30 такое уже не работает. Поэтому, в порядке важности:
1. качественный сон и его гигиена. 30 лет это время самого большого недооценивания этого фактора (раньше то спал как хотел и бодрячком)
2. нормальное питание и физическая активность. Не надо быть веганом или упарываться на стадионе - просто сбалансированная еда, не переедать, и тренажерка/что-то активное несколько раз в неделю
3. распорядок дня - уметь управлять нагрузкой и отдыхать. Это тоже то что нужно переосмыслить. "поднапрягусь и сделаю" или "ну я ж в потоке, поем вечером" "сегодня подольше посижу, завтра посплю больше" - это все во вред.

Эти три пункта - самые банальные, самые эффективные и самые сложные для выполнения в реальности.
"попить витаминки-ноотропы", "взять себя в руки" или "наладить внутренние энергии" - НЕ работает, но крайне популярно, потому что, во-первых, успокаивает (что тоже дает свой небольшой эффект), а во-вторых - делать на самом деле особо ничего не надо, все как мы любим :). Потом придете к "банальному" просто позже и в более худшем состоянии.

для json лучше всего подходит Mongo.
Но я бы подумал над тем что за данные у вас - если вы просто добавляете и добавляете +- одинаковые записи и по ним потом надо поиск например делать - то лучше подойдет elasticsearch. А если вы что-то еще делаете - то лучше подойдет что-то другое.
Главное не формат данных для хранения а операции над ними. Хранить то и в текстовом файле можно.

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

да, но этот объект вам недоступен и детали его реализации могут быть разными.
Можете для простоты считать что переменная "записывается" в блок в котором определена. Тот что "{}"
получить все переменные этого блока в виде объекта нельзя, да и не нужно.
от работы с переменными определенными в window тоже следует избавляться - это плохая практика.