Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

JavaScript. Больше делать упор на нейтив или на библиотеки?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Если книжка НЕ про ES6/2015, не читайте. Все-равно, что в 2016 учить Perl. Потратьте день-два на официальном сайте TypeScript.
Тут Ваш вопрос выглядит как «что учить: C# или сразу начинать с EF?»
Конечно, Вы должны выучить ES6/TypeScript, чтобы минимально элементарно понимать, что означают примеры кода, но работать на чистом JS Вам не дадут. Тут вопрос не в Вас, а в тех лиде, который должен быть сумашедшим, чтобы загрузить команду изобретением велосипедов.
У Вас, по-хорошему, есть 4 варианта: Angular 2, React (со всем зверинцем), Ionic 2 или React native.
PS Из всего jQuery, что Вам ниже писали, нужны будут только селекторы и изменение стилей. Совсем без него глупо, но и роль его сейчас не выше, чем у какого-то moments
PSS Да, и gulp/Webpack — обязательно. С node до кучи (имеется в виду npm). Примите как данность и портфолио без них не заводите.

Тут вопрос не в Вас, а в тех лиде, который должен быть сумашедшим, чтобы загрузить команду изобретением велосипедов.
если проект не унылый ынтырпайз, или еще какоето шаблонное формошлепство то весьма велика вероятность того что может быть чтото другое. а иногда даже в формошлепстве есть смысл использовать свое — вариации миллион, но да, чисто исходя из вероятности, попасть на такой проект большая редкость
Только не пишите что нужно и то и то
Нужно и то и то.
На что больше делать упор?
только чистый скрипт? Или лучше плагины?
Зависит от вашей конечной цели. Какие именно работы хотите видеть в своем портфолио? Какие плагины использовать собрались? Куда устраиваться собрались?
заново перечитывать Крокфорда
Обычно лучше что-то написать, а потом только перечитывать. Так хоть будете лучше понимать на чем внимание заострять / в чем хуже разобрались.

Пока просто есть свой проект, реальный, который полностью хочу сам написать и запустить, ну кроме бэк энда тут нужна будет помощ. Плюс думал над тем чтоб создать не большую библиотеку плагинов, не для того чтоб их кто тоо использовал, других полно, а чтоб было видно что я могу. В верстке я не силен, с творчеством не очень, да и не вижу смысла выкладывать лендинги и визитки, какие то не большие сайты, этого море там и без меня.
А насчет работы, то сейчас готов браться за любую и не потому что мне деньги нужны(пока могу себе позволить об этом не думать), а только ради опыта.

Вы опять очень абстрактно все говорите. Как вам люди могут что-то конкретно подсказать? Мне понятно только:

не вижу смысла выкладывать лендинги и визитки

Хотя и это просто стереотип. Не все клевые сайты должны быть со сложной архитектурой и не все только за такие готовы платить, можете сюда заглянуть: www.awwwards.com/...h/?categories=programming
Верстка это далеко не 20 блоков с картинками в кружечках раскидать по странице. На деле нужен и JS (на более высоком уровне, чем просто знания фреймворка, который все особенности языка и браузеров скрывает), и соображалка, и креативность, даже в тех ситуациях, когда супер-сложная логика с переходами в 1000 разных состояний не нужна.

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

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

Буде черговий сіньор фреймворк кодер?

Пишучи на джс фреймворку є хоч можливість поменше бачити «особливості» джаваскрипту. Це як і з пхп — чим менше ти нативно пишеш, тим більш стабільна в тебе психіка.

Все работы нужны пока только для портфолио
Если хочешь похвастать перед бородатыми синьорами, которые еще Netscape Navigator видели, то всё на чистом JS. А если для заказчиков, чтобы потом за деньги работать — то пиши как удобнее и быстрее (очевидно это будет куча библиотек и плагинов), но чтобы выглядело нормально.

Конечно, нужно знать основы JS и уметь при необходимости найти нужную информацию на MDN. В то же время, нужно также уметь интегрировать готовые решения. Оба вида опыта одинаково важны, нельзя зацикливаться ни на нейтиве, ни на готовых плагинах. Мне кажется что разработчик, и особенно если речь о фронтенде, должен уметь определить где проще использовать готовое, а где написать своё, и от этого отталкиваться.

Треба прокачувати алгоритмику в першу чергу. Рішення задач починається не з того, що дупа саджається за комп та починають пустунчикові пальці по клаві щось там тицкати. Задачу треба спочатку прокрутити в голові та знайти ефективне рішення. А потім ще пару запасних. От тоді можна вже обирати інструмент: нейтів або бібліотеку.

«нейтив» принято называть pure js.
Для справки.

Был введен в заблуждение, цитирую:
«a fast, lightweight, cross-platform framework
for building».
Где тут чистый, незамутненный JS я не вижу.

потому что это такой стеб «большинство штук не требуют сторонних либ, а требуют прямых рук»

что значит «нейтив» в данном контексте?
язык прост синтаксисом, даже с оглядкой на ES6. концептуально сложные штуки типа промисов и генераторов не обязательно снаскоку штурмовать, а больше ничего запутанного там и нет, раз с замыканиями разобрался.

fullstack, frontend или какой-то phonegap?
в зависимости от направления, надо тянуть что-то смежное.
сам по себе «нейтив джаваскрипт» — как абстрактный конь в вакууме, разве что лабораторки делать по выводу в консоль корней квадратного уравнения да либы по вычислению/моделированию.

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

В первую очередь учи то, чем хочешь сам заниматься, а на оставшееся время — то, что спрашивают на собеседовании.

Нейтів, нейтів і ще раз нейтів.
А після уже можна jQuery, React/angular.

Сегодня 10.12.2016, зачем учить jQuery?

А тут можно поподробней? Разве это не самая используемая библиотека?

Да, самая популярная. Но прогноз негативный:
jQuery vs Angular vs React

Думаю этот прогноз несколько обманчив.

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

Массовостью же применения jQuery обязан серверному рендерингу страниц. И пока разработка дешевле с серверным рендерингом, чем SPA, jQuery и его аналоги остануться более массовыми чем ангуляр с реактом.

Другое дело — уровень зарплат. Собственно серверный рендеринг потому дешевле, что фронедщики на ангуляре дороже

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

ниже — слухи, глубоко не копал.

я вот не пойму как рестовые сайты индескируются гоглом ?
насколько знаю — никак.

да, читывал, гугл индексация стала наконец запускать сприпты на сайтах. но — запросы — игнорирует. говорят что иногда делает, но с ограничением ожидания по времени. или сама работа скриптов — ограничена по времени — еще такое говорят.

робот может увидеть только х1 или х2 какие нибудь
интересно что гугловцы ругаются на подсовывание сайтов для ботов. и требуют чтобы сайт был тем же что показывается пользователям. поэтому народ все же генерит первый показ на сервере.

как-то встретил даже такой подход, на Backbone — серверный рендеринг, на фронте запускается «декомпилер», который с присланного html нарезает шаблоны для Backbone. и дальше уже SPA поведение.

React в этом плане грамотней чем Angular — он из коробки, умеет генерить html что на сервере, на фронте.

но в целом да, ситуация с рестовыми сайтами мне тоже не понятна. как-то спросил одного докладчика на js-day в перерыве. на что он — а-а-а, это на наверное для электронных магазинов нужно? не занимаюсь сайтиками давно. ну и смотрите — кабинеты пользователей все равно не нужно индексировать. а остальное, для незалогиненных — ну пусть себе рендерится на сервере.

во-1, есть hash-bang, если система legacy.
во-2, есть server-side rendering и возможность задавать роутинг для JS без #: через pushState(вполне поддерживается современными браузерами). Этот подход называется «изоморфными приложениями». Удобно, если пишется с нуля.

я вот не пойму как рестовые сайты индескируются гоглом
Я вот не пойму, зачем делать и индексировать «рестовые сайты»? REST для приложений, там ничего индексировать не нужно.

ну я видел магазины на ресте, интерестно как они живут

Может используют какие-то техники из упомянутых в этой ветке (рендеринг на сервере). С инет-магазинами конечно не все однозначно. От REST там польза есть, но и индексировтаь нужно.

У гугла були рекомендації, як будувати такі сайти. Давно правда були, що зараз не можу сказати

SPA тоже может быть с jQuery. Ember например использует jQuery, хоть и фреймворк для SPA.

ну вы сами ж сказали

Ember
. подразумевался же голый jQuery.

а то что и на голом jQuery можно SPA — конечно.

только много чаще — не будут писать SPA, ни на jQuery ни на Ember.

потому что это — дороже чем писать с серверным рендерингом и немножко jQuery. ну и или множко, добавив — jQuery EasyUI или подобный.

Просто в ветке выше противопоставляют почему-то jquery фреймворкам для SPA, хотя вообще-то говоря одно другому не мешает и может дополнять.

А норм. заміна $.ajax() вже з’явилася? А якщо кожен кілобайт рахувати, то можна без фреймворків і без бібліотек писати. Довго, але такий цінний у 2016 трафік заощадимо.

„Fetch support is at a fairly early stage, but progress is being made. It is turned on by default in Firefox 39 and above, and Chrome 42 and above.

If you want to use it now, there is also a Fetch Polyfill available that recreates the functionality for non-supporting browsers. ”

От аби не жквері, бо не модно, так?

От аби не жквері, бо не модно, так?
Генадію, мені чхати взагалі на всі сторонні фреймворки, я або свої пишу або використовую необхідні бібліотеки під певні задачі. Мода — то для хайперів, хіпстерів та девелоперняшек.

За минуту на ES6 написал (я если что джавист).

function ajaxGet(url) {
return new Promise((resolve, reject) => {
let r = new XMLHttpRequest();
r.open("GET", url);
r.onload = () => {
if( r.status == 200 ) {
return resolve(r.response);
} else {
return reject(Error( r ));
}
}
r.onerror = (e) => reject(Error(`${e}`));
r.send();
});
}

ajaxGet("#1030501″)
.then((data) => {
console.log(data);
}).catch((error) => {
console.error(data);
});

И это уже удобнее использовать в 2016/2017 году, так как на промисах, а не на коллбеках как жиквери.
Можно даже вторым параметром передавать массив key-value хидеров.

p.s. тег code почему-то глючит.

И jQuery в 2016 году (да и в 2015 наверное тоже) поддерживает промисы. А ещё вы забываете про кучу параметров запроса. И в результате получится своя огромная функция-велосипед. Удобно, жуть. Но зачем, вы мне скажите? SPA-фреймворки весят побольше jquery. Тоже самоделки делать?
Кстати зря вы на ES6, там тоже с поддержкой не всё круто.

Тоже самоделки делать?
Хочеш бути про? Пиши фреймворки, бро.
:D

Під капотом промісів все ті ж колбеки :D В красивій обгортці тільки.

под капотом class в ES6 те же прототипы
под капотом динамической типизации структуры данных с флагом текущего типа
под капотом функции Math.sin ряды Тейлора
в красивой обёртке только

а потом ваш лисапед кому-то сопровождать.

Можно даже вторым параметром передавать массив key-value хидеров.
а потом еще, и еще.
и выйдет кривое подобие jQuery

и зачем оно когда уже есть — всем известный, простой и няшный jQuery?

54кб гімороя
Special builds can be created that exclude subsets of jQuery functionality. This allows for smaller custom builds when the builder is certain that those parts of jQuery are not being used.
github.com/jquery/jquery#modules

да, кстати, я еще чего не пойму «с ужасом от толстого» jQuery. остальные либы и фреймворки то крохотульные, да.

Думал даже спросить более знающих.

Если на странице указана загрузка с какого-то из топовых CDN то ведь с большой вероятностью jQuery будет в кеше браузера.
а мобильные браузеры не кешируют, раз постоянно речь о дико медленной загрузке толстенного jQuery?

Ну так quod licet Iovi non licet bovi. ))
Что можно ангулару2 того нельзя джейквери )

розробка дишевше з бекенд рендером
звісно що дешевше.

якби дорокше — PHP давно вмер би.

ух інтересна аплікуха
думаю більш як 80% веб сайтів в інтернеті не мають, і не матимуть потреб в ніяких «аплікухах SPA» крім веб-браузер.
а шо мобайл трафік їсти будете ?
html. можна і p-ajax’ом. залежить від того — що користувач робить на тому сайті.

може так, тільки SPA треба. а мо` й тільки нативний клієнт.

Але:

бо тут таке спа легко перевести
навіщо замовнику витрачати гроши на розробку спа, коли йому не потрібне спа?
буде при стрестестінгу з 50 машин одним запитом
з 20ти
www.techempower.com/...data-r13&hw=ph&test=query

але цікавіше — який відсоток сайтів в інеті має тримати такє навантаження, щоб витрати на це ресурси?

Да, самая.

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

Да, самая, потому что самые популярные CMS основывают свои админки и фронтенд на jQuery

Пускай ее используют маркаперы и php девы в дешевых проектах, она вам не нужна.., она грамотно построена, но через ее призму изучать js — себе вредить.
Сейчас много вакансий «angular/react/angular2 dev», мне кажется это верный путь для начала.

Сейчас много вакансий «angular/react/angular2 dev», мне кажется это верный путь для начала.
И чем изучение js через призму TypeScript (или что там у 2 ангулара по дефолту) лучше?

А що її там вчити? Годинку-дві розібратись і все. Уже буде легше, якщо в майбутньому попадеться проект на jQuery.

Угу. Всі так говорять, наче jQuery рік треба вивчати.

1) jQuery — это очень удобно (хотя я слышал что уже можно без него обходиться, да)
2) jQuery — это много готовых UI-элементов. Всякие календари, таблички с сортировкой и всё такое

Готовые UI-элементы — это вы про jQuery UI, а это уже другая библиотека. И она морально устаревшая.

Нет, это я про множество других плагинов. Календари, typeahead, datatables

На jQuery писав останній раз рік тому.
Топікстартер хоче отримати позицію джуна. Думаю, йому все-таки варто розібратись із jQuery. Тим більше, що на це не потрібно багато часу.

Все работы нужны пока только для портфолио, так вот что важней, чтоб там был только чистый скрипт? Или лучше плагины?
если оно надо для портфолио, то ИМХО пофиг. Главное, что бы портфолио красиво выглядело и работало)
ну и это — если джаваскрипт нужен только для портфолио (как дополнительный инструмент), то можно не париться, а взять jquery с плагинами)
З.Ы. а если джавскрипт — первостепенное, то сперва хорошо учить сам язык, а потом (когда время появиться) пару популярных фремворков типа ангуляра и реакта.

ну вот вы сами и ответили:

портфолио
Всем ведь нужна скорость

а на собесдовании обычно спрашивают по нейтив ))

а на собесдовании обычно спрашивают по нейтив ))
зависит от собеседователя и соискателя.

если человек прямо говорит, мол, не знаю никаких фреймворков, только слышал про них, зато написал свой вариант jQuery — то вопросы будут по работе с DOM, прототипы, замыкания, setTimeout(object.someMethod, 500), вот это всё.
Но если другой говорит, шо на [подставить используемый фреймворк] накидал простенькое приложение, то почему бы не акцентироваться на этом?

по крайней мере, мне чаще попадалась такая вот гибкость.
а у вас как?

Кажется, что все считают нужным спросить про bind/apply/call вне зависимости от того, знаешь фреймфорки или нет.

не все.
Плюс, лично моё мнение: если человеку обрисовать задачу("вот код, метод объекта передается как хендлер события, но внутри this ссылается не на объект«), то на самом деле плевать, какой вариант человек предложит: =>, bind, $.proxy, _.bind, или вручную-влосипедно обернуть метод в анонимную функцию и var self=this;
Важнее, что сталкивался с проблемой и знает как решить. И про «bind» можно просто сказать: «а, ну, а это для тех же целей»
Впрочем, даже если не сталкивался, все равно это не рокет-сайнс.

Забавнее, когда чувак отличное демонстрирует знание «внутрянки», но дебажит с помощью alert’ов и console.log’ов(на самом деле, это не забавной, а жопа)

Чем плох дебаг с помощью console.log? И какие есть лучшие альтернативы?

breakpoint’ы же
пошаговая отладка, условные брейкпоинты, просмотр стектрейса и переменных.
тем более, шо использовать console.log напрямую — уже само по себе плохая идея(в случае с NodeJS пишет в поток, а не в файл — надо не забыть перенаправить, а то потеряешь; в случае с браузером, console.log(someObjectVariable) сделат дамп по ссылке, то если ниже по коду объект изменится, в консоли увидишь обновленную версию, а не ту, что была на момент console.log)

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

Вы мне говорите, как костыли костылями подпирать.
Ну, или про дебаг баги, которая воспроизводится исключительно в IE6/7.
Еще раз: брейкпоинты. пошаговое выполнение. доступ к стеку вызовов и всех переменных(и даже более того — вычисление любого выражения) на каждом уровне стека вызовов.

[UPD] но я с NodeJS не работаю напрямую. Неужели дебаг режим только в Inteliji IDEA есть, что об этом никто не слышал?

Сейчас дело улучшилось, уже поудобней, но зачастую хватает console.log, быстрее и удобнее, ну и привычнее)

Глупости — это мусор в коде, который капец как неудобен

Не быстрее и не удобнее. Нормальный дебаг для того и придумали, чтобы было удобнее.
Хотя, конечно, есть кейсы, где логами воспользоваться удобнее. Но таких процентов 5 от общего количества, наверное.

где логами воспользоваться удобнее
1. когда не знаешь условий возникновения баги + код выполняется слишком часто: тогда логи помогут предположить причину и выявить условия, ибо ставить брейкпоинт и стотыщ раз прокликивать одно и то же место в ожидании баги — слишком муторно(но обычно, если представляешь, что именно в логах будет подозрительным — можешь и брейкпоинт на это поставить).

2. когда дело в race conditions и сам факт остановки по брейкпоинту влияет на ситуацию и не дает дебажить(но и то, можно принудительно влиять на казалось бы параллельные асинхронные действия: например, с помощью указания задержки на обращения к серверу по определенному URL в Fiddles/Charles)

в случае с браузером, console.log(someObjectVariable) сделать дамп по ссылке
Для обхода этого обычно хватает JSON.stringify. А вот пошаговая отладка имхо дольше.
А вот пошаговая отладка имхо дольше.
дольше, чем «попытка угадать, в каком из значений загвоздка, добавить console.log, задеплоить, перезагрузить страницу в браузере, восстановить все предусловия для воспроизведения проблемы, открыть консоль и копаться среди её сообщений»? это шутка? а то я че-то иронию в интернете плохо чувтствую.
попытка угадать, в каком из значений загвоздка
Мне обычно известно в каком методе проблема
задеплоить
Зачем деплоить? Не надо деплоить, есть локальный веб-сервер. Как только Ctrl+S нажал — так сразу и билд и обновление страницы в браузере.

Но вы мне другое скажите. Я сейчас только с ember.js работаю. Там ты пишешь код во много-много разных файликов (контролееры, роуты и все такое прочее), а ember-cli это всё собирает в большой файл. И у меня вопрос, как поставить брекпоинт через IDE. Я никогда не пробовал, так как не чувствовал нужды, но кажется через IDE не выйдет (разве что если dev tools понимают какой-нибудь специальный комментарий, означающий брейкпоинт). А через dev tools искать нужную строчку — как-то console.log кажется быстрее.

developer.mozilla.org/...rence/Statements/debugger
А потом найти то место и уже поставить в Хроме.

Спасибо, тогда согласен, удобно

tools not rules

Надо по-всякому уметь, на дистанции больше времени сэкономит. Если надо посмотреть че происходит в массиве на каждой итерации — логирование. Если надо вывести много данных — можно отформатировать в console.table(). Если посмотреть откуда было вызвано — console.trace(). Если просто ошибку вылечить, то конечно лучше смотреть че там в source происходит. Я так вообще часто в timeline с галочкой js смотрю че происходит, а потом прыгаю в подозрительное место и там брейки ставлю.

tools not rules
я с этим не спорю, не догматик. Но это специфический случай, когда console.log проще.

У меня был кейс, когда создание-перезапуск таймаута было с багой, в итоге иногда отрабатывал таймер на уже устаревших данных. console.log помог вкупе с сортировкой лога в блокноте(выводил «+<timeoutid>» на запуск и «-timeoutId» на остановку — после сортировки всех строк регуляркой убрал парные и осталось одиночные строки).

Конкретно в этой ветке пока что вижу «мне влом разбираться с инструментами, но я не хочу признаваться, что это лень»

но я не хочу признаваться, что это лень
Та я вообще ленивая задница.

мне тоже лень. потому в 95% случаев и использую дебаггер. больше возможностей(меньше действий для достижения результата), меньше побочностей(типа, случайно закоммитить console.log, что станет потом валиться на этапе хуков билда или при запуске юнит тестов)

Зачем деплоить? Не надо деплоить, есть локальный веб-сервер
Эм. А баги на продакшене/CI-cервере вы как будете дебажить? стянете себе локально базу ради дебага баги? Серьезно?
всё собирает в большой файл
не вижу сложности, Ctrl+F(если один файл)/Ctrl+Shift+F(если дофига файлов)/Ctrl+O(если дофига файлов + знаете имя файла) в помощь.

брейкпоинты можно поставить на:

  • определенную строку кода
  • определенную строку кода с условием
  • возникший exception
  • удаление указанного элемента из DOM
  • изменение аттрибутов указанного элемента
  • изменение любых дочерних элементов у указанного элемента
  • любое системное событие — посмотреть все хендлеры клика по этой кнопке, например
  • AJAX запрос на URL, совпадающий с маской
  • можно сохранять стектрейс с учетом асинхронных вызовов("кто же вызвал эту функцию в setTimeout?")

как всё это можно заменить console.log? в каких случаях это можно дебажить через console.log за конечное время?

Эм. А баги на продакшене
Все баги, с которыми я сталкивался на продакшене, были с php почему-то, js особо отлаживать не приходилось. Да и те какие-то слишком легконаходимые были.

Но кстати как раз на продакшене

Ctrl+F(если один файл)/Ctrl+Shift+F(если дофига файлов)/Ctrl+O(если дофига файлов + знаете имя файла)
Не помогут — минификация же.
минификация же
source maps настроить — одна строчка в конфиге.

не говоря уже о том, чтоб с помощью fiddler’a подставлять не минифицированный вариант исключительно в свой локальный браузер.

были с php почему-то
надеюсь, там-то xdebug используется при отладке, а не var_dump?

Умение работать с девтулз достойно отдельного обсуждения на собеседовании, ИМХО

Підписатись на коментарі