21 жовтня – JS Conference 2017 у Києві. Які знання знадобляться JS розробнику у майбутньому та як їх здобути?
×Закрыть

Будущее за JS?

Всем доброго времени суток. Являюсь (не побоюсь этого слова) middle full-stack web разработчиком.

Считаю, (моё личное мнение, никому ничего не навязываю) что в проектах уровня выше чем блог/landing page между разработчиками должно быть чёткое разделение (кто будет заниматься back-end’ом, кто front-end’ом).

Имею относительно неплохой опыт работы на бэкенде (PHP, Yii, Symfony, WordPress, SQL), и так же опыт на фронте, в частности уже около года работаю с AngularJS 1.

Последнее время(где-то пол года) стал замечать невероятный приток вакансий на MEAN/Angular2/React dev и тому подобных, где основной язык js.
Так же судя по графикам некоторых источников, популярность и front-end/mean направления сильно возросла и продолжает расти.

Вопрос: по вашему мнению, стоит ли делать ставку на js и полностью «погружаться» в стек из ангуляров, ноды и прочего? Либо же взлёт js это некий хайп/временное явление, которое не имет стабильного будущего?

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

Да, будущее за JS. Ставку надо делать на фундамент, а не на ограждение.

Если будущее IT это JS, то я бросаю свою карьеру и иду работать водителем в убер.

не парься, будешь на WebAssembly педалить performance critical parts, он уже вышел

И будешь использовать аппы написанные на JS

в проектах уровня выше чем блог/landing page между разработчиками должно быть чёткое разделение (кто будет заниматься back-end’ом, кто front-end’ом).

Вы имеете ввиду, что джаваскриптовые программисты будут разделяться на back-end и front-end?
Хотелось бы узнать от JS-спецов — это вообще распространённая практика?

Либо же взлёт js это некий хайп/временное явление, которое не имет стабильного будущего?

JS клиенты будут в тренде.
Серверный JS — не уверен, мягко говоря.

зы:
комменты конечно зачотные, по-нашенски так затроллили тему.
ТС, всё правильно делаешь, есть вопросы — задавай, ищи ответы.

JS клиенты будут в тренде.

Кто знает...Кто знает...Сейчас такой перенадутый пузырь на JS, что чуйка мне подсказывает, что WASM таки стрельнет. Практически все языки будут портироваться в браузер. То есть все программисты смогут стать веб-разработчиками. И хайп на JS спадет.

Даже если с завтрашнего дня абсолютно все новые проекты перестанут использовать JS (чего конечно же ни завтра ни в ближайшие годы не случится), то поддержки уже написанного на JS кода хватит еще лет на 10.

Я так и думал ,что увижу подобный коммент))
Я пишу о перспективах, а вы о том, заберут ли ваш кусок колбасы.
Не волнуйтесь -колбасу не заберут. Просто будет возможность писать на удобном языке, а не только на JS.

Ну это еще вопрос, будет ли удобно писать на удобном языке под браузеры. Ну и насчет удобного языка: у JS конечно есть минусы, но все же большая часть поливания говном приходится на людей, которые привыкли писать на чем-то другом, а их заставляют JS педалить. И для таких людей WASM конечно же станет панацеей. Но уже выросло поколение программистов, для которых JS — первый, а часто и единственный язык, на нем они учились программировать и никаких неудобств не испытывают. Что для них изменит WASM?

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

Станет вторым языком который выучат.

WASM это не язык программирования. Это промежуточный байт-код

JS очень удобный язык, особенно в сравнении со всякими джавами

Если уже брать язык, как язык, а не инфраструктуру.
То есть и получше, чем JS. Руби более гибкий и чистый язык, Swift тоже..
Или кто-то может захочет фронтенд на Rust GO писать

То есть и получше, чем JS

Краще для чого? Яка задача або перелік задач? Давайте критерії оцінки.

Руби более гибкий и чистый язык, Swift тоже..

Для вирішення яких саме задач? Просто текстик в редакторі красивіше виглядає? Дик це суто персонально.

Багато з присутніх або забули або й не знали головного призначення JS, яке навіть закодоване в його назві (оце так несподіванка!). Це в першу чергу скриптова мова. Писати сценарії. По типу bash’а. Те, що до неї набігло іншомовців та почало з нього робити казнащо, не відміняє основного призначення JS.

Краще для чого?

Для того щоб усілякі дужки і коми з крапками за монітор не повилазили:)

Просто текстик в редакторі красивіше виглядає?

Нежахливо, а не красивіше.

Тю, естетство якесь...

Вам без разницы, какой синтаксис у языка?)

А яка суттєва різниця? o_O
Важкувато писати одразу в машинних кодах та на мовах, основна задача яких — ускладнити життя (brainfuck). Все інше якось пофігу.

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

Была статья на dou об этом на примере Angular 2 dou.ua/lenta/columns/angular-2

Популярность языка определяет прежде всего набор библиотек/фреймворков, обучающих материалов и программ, инфраструктурная поддержка, в связи с чем временный взлет это не про языки программирования. JS будет развиваться и укреплять свои позиции.
P.s ну про полный фуллстек на JS — имхо это перегиб. Например, я в своем хобби проекте планирую использовать python в качестве «глубокого» бекенда для анализа данных и он отлично вписывается в архитектуру стека MEAN

Вообще динамическое модульное построение сайта на одних только json’ах — тоже хрень.
Клиент грузит 100500 файлов целую вечность не говоря о нагрузке на вычисления (читай батарею).

Короче JS таки должен вешать интерактивность поверх существующего DOM’а, а не строить вселенную своими фреймворками и эмулировать бекенд -_-

Есть такая штука как сервер сайд рендеринг на ноде и паттерн оркестрирование

Ну если получается построить на тех же hbs и рендерит сервер то ок, но у нас как-то на столько динамические сайты получаются что сервер рендерит в лучшем случае обертки и лейауты, а внутрь напихиваются модули на клиенте

Ну не обязательно ж SPA делать. node хорошо генерит странички на сервере и отдает готовых html контент. Тут уже все зависит от задач — нужна крутая и быстрая интерактивность в ущерб скорости загрузки (хотя если грамотно управлять кешем...) то SPA, иначе делайте MVC приложение на node.Есть и компромиссы — статическая часть генерится node, но есть небольшие динамические вставки (к примеру, комменты) которые подгружаются через api в виде json объекта.

В том и дело что у нас не SPA :)
Просто страницы содержат модули которые рендерятся динамически

Вообще динамическое модульное построение сайта на одних только json’ах

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

Клиент грузит 100500 файлов

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

Короче JS таки должен вешать интерактивность поверх существующего DOM’а

С JS и DOM в принципе все нормально, а вот обильное юзание фреймворков с высоким уровнем абстракции, в угоду широким массам и быстроте/дешевизне кодинга имеют ожидаемую обратную сторону. «Язык» тут не при чем, за все нужно платить.

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

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

так тут вопрос к кодеру, схера клиент грузит 100500 файлов?

а как ты хотел? AMD видите ли, получите/распишитесь
страница состоит из десятка модулей, каждый модуль из 3 файлов аля js + stache + less, помимо всего это запакованы во все возможные лейауты которые тоже stache + less и пошло-поехало.

обильное юзание фреймворков с высоким уровнем абстракции, в угоду широким массам

именно, между старым добрым «херачим код странички прямо в html» и текущим подходом с этим х5 уровнем наследования образовалась необъятная пропасть

страница состоит из десятка модулей

Це де такий жах?

именно, между старым добрым «херачим код странички прямо в html» и текущим подходом с этим х5 уровнем наследования образовалась необъятная пропасть

Оверінженірінг у всій красі

Це де такий жах?

на любом сайте, полагаю

меню + футер + херо-слайдер + основной контент + сайд-бар + какой-нить фид карточек + рекламный модуль, и это так навскидку минимальная главная страница

страница состоит из десятка модулей

Ну там явно можно не грузить прям все сразу, а то что в грузится вместе в bundle запихивать, да и священный вебпак же, помнится, так же делает...
Если бы был интерфейс к файловому кешу браузера, то можно было вообще прослойку заделать между тем же древним requirejs чтобы налету упаковывать в один запрос, а инициализацию вместе в html отдавать, хотя и так можно, но костылей придется по впихивать овердохера, а результат с кэшированием будет сомнителен. Где то в 2012 пытался это родить, в борьбе с неприличным числом запросов, но потом забил на радостях, что ES6 модули вот-вот выйдут, и http2 за ним и наши страдания почти окончены, все упрощается :) Уже 2017 год, а они только семантику определили... снова зоопарк загрузчиков и только все еще усложнилось.

Если бы был интерфейс к файловому кешу браузера,

Use service workers Luke!

Use service workers Luke!

Гм, кажется этот интерфейс не совсем для этого, к тому же Experimental или там есть нечто вроде банального :
cache.add(url, content);
cache.has(url); / cache.get(url);
cache.remove(url); ?
Иначе тогда он бесполезен для реализации кеширования мультиплексированных запросов.
Не исключено что его тоже постигнет участь AppCache, они появляются и исчезают быстрее, чем ты успеваешь разобраться и реально заюзать его где то :)

developer.mozilla.org/en-US/docs/Web/API/Cache
все там есть, а для чего вы его юзаете это up to you.

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

ну service worker я еще год назад юзал, правда не для кеширование

developer.mozilla.org/en-US/docs/Web/API/Cache
все там есть

Ладно, thnx, он таки вполне толковый, даже жирный интерфейс, хотя для несвежих окружений и !(Chrome||FF) все ровно бы пришлось юзать костыли с sessionStorage/localStorage с их 5мб(2.5) лимитом, что вообщем то неплохо, и для кеширования кода вполне достаточно, да и, возможно, кому то уже пришло в голову написать хоть какой то отдаленный полифил для cache, надо по гуглить.

неплохой опыт работы на бэкенде
WordPress, SQL

Все ясно

С одной стороны, не слышал о нормальных проектах где обходились бы только JS, с другой, есть инфроструктура, которая невероятно развивается.
Какая разница между ангуляром первым и вторым? Да как небо и земля, безусловно есть что-то общее, но в целом почти два разных продукта.
Взять ноду, ей уже почти 8 лет, изначально был похож на какой-то сбор костылей, сейчас полноценный продукт, сколько было преблуд к нему, сейчас все идет с коробки, даже кажется до 4 версии нпм шел отдельно.
Сейчас вакансии для фул стек разрабов овер дофига и тренд будет развиваться. Учиывая как развивается нод и какой огромный скачок они сделали за последние пару лет, будущее у JS многообещающее однозначно.

В свете резкого взлета go ноджсом скоро будут пользоваться только в legacy проектах.

Сразу после того, как в go наконец запилят дженерики и исключения.

и получится еще одна java

Ну, это тоже неплохой вариант — Java с предкомпиляцией.

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

Да, будущее за JS.

— We’ve got romulans ahead! Full warp speed, mr. Sulu!
— Just a minute, sir, this awesome Angular200 is still in updating mode.
— Torpedoes, mr. Chekhov?!
— Sure! Well, def __init__(self, size), yep, right, now self.size = size...

JS рулит однозначно.

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

А в браузере JS (и все что в него транслируется) вне конкуренции.
как это? а как же gopherjs? а как выпустят webassembly сразу за пару дней запилят компилятор для Го чтобы пакеты webassembly можно на нем было делать

Черт, не пятница же сегодня, а столько пятничных топиков. Или у вас в Украине завтра выходной и сегодня уже пивом все с утра заправляться начали?

которое не имет стабильного будущего
 В сегодняшнем мире, ничто не имеет стабильного будущего. Привыкайте.
Либо же взлёт js это некий хайп/временное явление, которое не имет стабильного будущего?
Ну если ты считаешь что через пару лет никто не будет пользоваться браузерами и вообще сидеть в интернете — то да, «временное явление»

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

Будущее за контролем над источниками пресной воды.

Вообще главный плюс джс это function as first class object, а все остальное это рюшечки.

В go функции также являются first class citizen’ами, как и в js. При этом go лишен многочисленных недостатков js.

Ты че не в курсе??? Все на Го переходят, а джс умер когда родился Го

Я всегда отвечаю на это будущее не за js, я просто не люблю конкурентов ибо всем ясно за чем будущее))

Будущее за контролем над источниками пресной воды.

Для получения пресной воды нужны морская вода, солнечная энергия, извилистые мозги и прямые руки:
www.scientificamerican.com/...​desalination-era-is-here
хорошо умеющие в embedded engineering (HW/FW/SW) и фундаментальные знания:
dou.ua/...​ntal-knowledge-is-a-must
как и в связанной с этим (особенно в израильских реалиях) военной отрасли.
Но уже в другой связанной отрасли — финансовой — JS и прочий UX приобретают куда большее значение, если нужно кому-то что-то продать и насобирать денег на фундаментальные железные ништяки. Сначала PayPal, потом Tesla, SpaceX и прочие скучные компании. Увы или ура — на данный момент оно так работает, организация взаимодействия железа с человеком или людей между собой не менее значима (и вознаграждаема), чем решения чисто железных задач. Хотя в последнее время есть сдвиги в повышении доступности и привлекательности последних для разработчиков — появление хакерспейсов, хардверных акселераторов, онлайн-курсов по железу, доступных 3D-принтеров и китайских фабрик по запросу — возможно, туда будут все больше устремляться потенциальные формоделы и после быдлокодинга получит распространение «быдлоинжиниринг». Будущее же в долгосрочной перспективе за программируемой материей (в т. ч. и в технологиях опреснения и прочего управления ресурсами), в более краткосрочной за VR/AR-интерфейсами и в этом плане скриптовые языки тоже не стал бы сбрасывать со счетов.

Будущее же в долгосрочной перспективе за программируемой материей

Вы за автоботов или десептиконов?

Это сложно и дорого. Гораздо проще сделать всякие ракеты, чтобы они поубивали тех, у кого есть пресная вода. Иначе они сделают ракеты и поубивают тех, у кого есть солнечная энергия, извилистые мозги и прямые руки.

Нравится ли вам js?? Если да то вперед если нет то зачем время тратить?
Делать ставку... Да щас можно но дальше мб чет новое будет....

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