Что тут можно улучшить? Какие есть очевидные ошибки? Что плохо?

Question

[Andy Oker]

Доброго времени суток!
У меня есть вот такая верстка небольшого проекта.
Буду рад если укажете на мои ошибки, скажите, что тут можно было бы сделать лучше или правильней в контексте использующихся технологий, в общем буду благодарен за любую обратную связь!

Comments

[umid]

можно переписать на vanilla, так как многие уже считают его устаревшим

[Дмитрий]

Такие вещи лучше выкладывать на codesandbox, Кому интересно копаться в гитхабе, кроме работодателей?

[Andy Oker]

Дмитрий, оу, да, там удобней, спасибо, буду знать

[Александр Маджугин]

umid, ага, у меня как раз сейчас один проект там верстальщик все сделал на ванильном js, но со всеми этими вэбпаками и npm'ами.
2Мб бандл. Зато блин без jQuery, и минимизированный!!!
Пожалуйста - пусть лучше делают по старинке на jQuery. Все эти модные веяния призванные все сделать более компактным и быстрым ведут только к тому что все становится совершенно неподъемным и тормознутым, только теперь еще и неуправляемым.

[umid]

Александр Маджугин, сильно ошибаетесь сравнивая два разных проекта - это во первых, во вторых, он мог в вебпаке подключить слишком много плагинов, в третьих то что все это ведет к не подъемному и тормознутому коду - вот ответ
Так что, плохой какой то верстальщик

[Александр Маджугин]

umid, я сравниваю вообще не проекты, а подход - "не используй технологию Х, потому что это не модно, надо юзать технологию П"

он мог в вебпаке подключить слишком много плагинов

Не просто много плагинов, а много плагинов часто повторяющих некую функциональность, потому что они ванильные + каждый имеет 100500 зависимостей. Использование пакетных менеджеров которое должно было избавить нас от головной боли зависимостей привело к тому что зависимостей стало слишком много, так как заюзать очередной пакет внутри плагина становится мегасоблазнительно:

ansi-regex/   buffer-alloc/         camelcase/      decamelize/   get-caller-file/          locate-path/  pngjs/              require-main-filename/  which-module/  yargs-parser/
ansi-styles/  buffer-alloc-unsafe/  cliui/          dijkstrajs/   ieee754/                  path-exists/  p-try/              set-blocking/           wrap-ansi/
base64-js/    buffer-fill/          color-convert/  emoji-regex/  isarray/                  p-limit/      qrcode/             string-width/           y18n/
buffer/       buffer-from/          color-name/     find-up/      is-fullwidth-code-point/  p-locate/     require-directory/  strip-ansi/             yargs/

генератор qrcode...

вот ответ

Это вообще не ответ.
Когда ровно то же самое сделает рядовой верстальщик, зафигачив 10Мб плагинов, которые вытянуться в зависимостях, скорость работы может и останется более быстрой чем на плагине с jQ, но пользователь об этом не узнает, потому что закроет страницу не дождавшись ее загрузки.

[Павел Корнилов]

Александр Маджугин, каждый уважающий себя фронт-эндер, при попытке создать универсальное и кроссбраузерное решение на Vanilla, написал свою jQ =)

[Gimir]

Александр Маджугин, тоже работаю над таким проектом, но там уже бывший фронтендер постарался, бандл весил 2.5мб на девелопе (4мб на проде), после разбиения на чанки основной весит 1.4мб.

[umid]

Александр Маджугин, Ну, я ни разу не сказал ничего про вебпак, да я согласен с вами то что, он идет с зависимостями, но я говорил про скорость работы ванильного джс и джейкуерий

Все эти модные веяния призванные все сделать более компактным и быстрым ведут только к тому что все становится совершенно неподъемным и тормознутым, только теперь еще и неуправляемым.

А так да, в прод моде добавляется огромное количество зависимостей, но я не про это ..

[Александр Маджугин]

umid, а, ну так-то согласен. jQuery делает огромное количество лишних телодвижений и операций с DOM что делает его оч. тормознутым.
Хотя вроде бы его переписывали и 3 должна была стать быстрее (не знаю насколько стала) и в целом да - сегодня нет никакой необходимости в jQuery
Да и подходы изменились - сегодня время всяких Vue и прочих ангуляров.