Comments 7
Вам не нужно знать ES6 или понимать особенности внутренних механизмов фреймворка для того, чтобы начать работу с ним.
Пожалуйста, не надо так говорить никогда и никому.
Я честно говоря, не очень понимаю, почему так сильно все переходят на фреймворки, забывая про обычный язык? Как же писать как тебе нужно, почему так насильно навязывают чужое видение? Да, в проектах где много людей работает, и нужно что общее и стандартное, то фреймворки, это то что доктор прописал. Но в личных проектах хотелось бы свои костыли писать...xD
Фреймворки скрывают под собой не самую удобную часть DOM-API браузера (без поддержки дата-биндинга, модуляризации интерфейса), а сам язык никуда не пропадает.
Случай из практики. Была поставлена задача — написать быстрое дерево для каталога. Я думал что библиотеки имеют очень много лишнего и я напишу следовательно что-то реактивное. При больших объемах мое дерево просто вставало колом и не хотело работать. Начал искать пути решения. После прочтения хорошего такого объема информации, переписованного кода и так далее, я написал почти что я скоро напишу тот же jstree. Когда я на все плюнул и поставил jstree, все «взлетело».
Я был настолько расстроен и сделал для себя вывод, что люди, которые пишут подобные вещи не просто так это написали и квалификация в том вопросе, который они решают, несколько больше.
И фреймворки на самом деле решают очень много рутинных вопросов. Да на самом деле очень сильно упрощают разработку. Да приходится придерживаться их правил, но если опуститься на уровень чистого js, то там тоже очень много правил, которые нужно соблюдать.
Я был настолько расстроен и сделал для себя вывод, что люди, которые пишут подобные вещи не просто так это написали и квалификация в том вопросе, который они решают, несколько больше.
И фреймворки на самом деле решают очень много рутинных вопросов. Да на самом деле очень сильно упрощают разработку. Да приходится придерживаться их правил, но если опуститься на уровень чистого js, то там тоже очень много правил, которые нужно соблюдать.
Если ваш личный проект достаточно велик, то писать без каких-либо удобств — это всё равно что катить квадратное колесо в гору. Нужно оптимизировать. В итоге вы либо берёте готовый фреймворк, либо… внезапно, вы пишете свой. Итог один.
За что минус напихали Джокеру? Ну хорошо, есть ещё третий путь: не писать свой фреймворк. Тогда вы получаете лапшу вместо своего приложения. Вы садитесь и всё это рефакторите, у вас получается… специализированный фреймворк специально для вашего приложения. Т.е. второй путь. Естественно, что выбор между первым и вторым путём никем не регламентирован и зависит от множества вводных.
есть вот такая публикация — О главнейшей причине существования современных JS-фреймворков
я склонен считать, что она близка к правде. Да, простую обвязку для сайта можно и на ванильном JS делать. Но чем больше сайт похож на интерактивное приложение — тем больше в нем потребность в шаблонных решениях для связи логики и представления.
Другими словами, на фреймворки переходят, потому что сайты все больше и больше обвешиваются интерактивными функциями, перестают быть просто статичными страницами. Не помню точно, но вроде Gmail изначально писали на Angular — и мне трудно представить, сколько бы лишней работы им пришлось сделать, если бы они старались сделать все на чистом JS
Писать самому стандартные велосипеды — хорошо во время обучения, но в работе это может быть оправдано, только если стандарный велосипед становится проблемой из-за критических багов или низкой производительности
я склонен считать, что она близка к правде. Да, простую обвязку для сайта можно и на ванильном JS делать. Но чем больше сайт похож на интерактивное приложение — тем больше в нем потребность в шаблонных решениях для связи логики и представления.
Другими словами, на фреймворки переходят, потому что сайты все больше и больше обвешиваются интерактивными функциями, перестают быть просто статичными страницами. Не помню точно, но вроде Gmail изначально писали на Angular — и мне трудно представить, сколько бы лишней работы им пришлось сделать, если бы они старались сделать все на чистом JS
Писать самому стандартные велосипеды — хорошо во время обучения, но в работе это может быть оправдано, только если стандарный велосипед становится проблемой из-за критических багов или низкой производительности
Sign up to leave a comment.
Перенос веб-приложения с чистого JavaScript на Vue.js