Насколько резонно подключать библиотеки для таких вещей как модалка, маски и тд?

Question

[godsplan]

Иногда смотрю работы других людей и вижу что они в основном подключают библиотеки которые в теории можно написать самому (модалка, маски , валидация и тд), понятное дело что ты изобретешь велосипед, но для какой нибудь простой модалки, аля просто показать скрыть блок можно написать в 6 строчек кода, но с другой стороны ты тратишь на это достатчное кол-во времени.
С модалкой лишь пример.
Раньше меня учили что если можно обойтись без библиотеки и написать самому, то лучше так и сделать, но в последнее время я вижу, что люди пишут : "Не изобретай велосипед, за тебя уже все придумали","Не факт что ты напишешь без костылей, а в готовой либе уже все костыли прошли".
Так в итоге как быть?

Answer 1

[Дмитрий Кузнецов]

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

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

Лично я использую библиотеки для более-менее крупных проектов, которые со временем будут только расширяться. Для одностраничников 50/50. Всё зависит от требуемой скорости разработки.

Answer 2

[Игорь]

Все нужно плясать от того насколько процентов используется функционал этого готового решения. На примере той же модалки, если от нее использовать только показать блок, то можно обойтись и без него.
В любом случае чем меньше размер вашего js тем более лучшие показатели CWV от сайта можно получить

Answer 3

[mletov]

В большинстве случаев - резонно.

Для маленьких проектов - jquery + плагины.
Для средних - всякие UI фреймворки, типа DevExtreme.

Заметил, что разрабатывать типовые компоненты с нуля начинают на проектах, начиная с определенного уровня масштаба и крутости: Яндекс, Сбербанк, Skyeng. Когда проект очень популярен и разработчики, с одной стороны, хотят минимально зависеть от сторонних плагинов и либ. А с другой, будет весьма несолидно, если на Яндексе вдруг выскочит типовой fancybox или bx-slider ))

Comments

[godsplan]

но те же топовые компании как к примеру используют свайпер

[mletov]

godsplane,
Так-то да.
Если через Wappalyzer посмотреть на любой топовый сайт, там будет много чего знакомого, в т ч и родной jquery (на Яндексе точно) ))

Но именно мелкие рутинные вещи (модалки, маски и т д), упомянутые в топике, гораздо чаще будут самописными, чем в мелких проектах.

[mletov]

godsplane, кстати, глянул свайпер. Раз топы его используют, то, видимо, он и вправду хорош и достаточно универсален, не тянет хвостом избыточных зависимостей. Имеет реализацию как под различные фреймфорки, так и для чистого JS, даже без jquery.

Все-таки в большинстве своем, такие плагины завязаны на jquery или ui фреймворки, и топам их использовать не комильфо.

Answer 4

[Alexander3928]

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

Comments

[Роми]

вот я написал совет с точностью наоборот :-)

дело в том, что кодер пришел в проект, кодер ушел из проекта, а код надо поддерживать дальше, и если это будет популярный UI-фреймворк - преемнику не надо будет морочиться, разбираться в велосипедах предшественника.

[12rbah]

Роми,

если это будет популярный UI-фреймворк - преемнику не надо будет морочиться, разбираться в велосипедах предшественника.

Тут как повезет, условно в проекте может использоваться старая версия по каким-либо причинам или дополнительные костыли, вероятность конечно ниже, но такое тоже бывает.

Answer 5

[Роми]

Пока учишься - пиши сам.

Если работаешь в совместном проекте - используй UI-фреймворк.

Comments

[Alexander3928]

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

Answer 6

[12rbah]

"Не изобретай велосипед, за тебя уже все придумали"

Очень сильно зависит от задачи, если это функция/класс до 100-200 строчек, то обычно можно самому написать, но скорее всего решение будет покрывать только ваши потребности в проекте. Но если это что-то большое или что-то связанное с криптографией, то лучше использовать готовые и проверенные решения.

Раньше меня учили что если можно обойтись без библиотеки и написать самому, то лучше так и сделать, но в последнее время я вижу, что люди пишут : "Не изобретай велосипед, за тебя уже все придумали","Не факт что ты напишешь без костылей, а в готовой либе уже все костыли прошли".

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

Answer 7

[Uno]

Перефразирую для тебя твой вопрос с той самой точки зрения, о которой говорит второй по лайкам комментарий: сколько смысла использовать библиотечный отлаженный 100 раз проверенный механизм вместо написанного собственного с нуля?

Answer 8

[ZoomLS]

Если вспомнить случай с leftpad, недавний случай с node-ipc и другие - то использовать сторонние модули/библиотеки, нужно с осторожностью. Я лучше сам напишу, чем буду потом иметь кучу зависимостей со всеми вытекающими возможными проблемами.