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

Немного о frontend

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Мне очень нравится JavaScript как язык, он дался мне довольно легко в плане понимания (очень много было знакомо с Паскаля, на котором я писал свои первые лабораторные и небольшие программки), у него есть свои неповторимые фишки которые мне стали по душе, результат работы можно было сразу же отобразить с помощью HTML и CSS, и так далее.

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

Но вот последнее время я наблюдаю такие тенденции которые, откровенно говоря, немного бесят.

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

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

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

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

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

Но вот не задача, его по уму надо компилировать в ес5, а пол доки реакта не только джск юзает но и ес6.

Дальше вы начинаете гуглить о том как это все запустить. А тут нужна система сборки, а их 3, и чтобы их поднять нужна нода. Вы не разбираясь детально с процессом сборки пытаетесь сделать как нибудь, чтоб работало, но че то оно как то не запускается.

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

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

И да, дальше будет только хуже

Ну у того разработчика там другая проблема — не в зелености и не понимания что и зачем, а проблема выбора инструментов...
Ну веб развивается семимильными шагами... а как Вы хотели то? Потискать «веб» с нуля годик и уже все профит=? Да на это нужно много времени, много сил, выдержки ну или скажем честно- задротства. Радуйтесь хоть, что в такое время начали, когда знаете чем будете заниматься, а не учили все сразу начиная от мк, схемотехники, прикладного и системного программирования и заканчивая вебом- выучить один фронтенд — относительно недолго, но все ровно придется каждый день обновлять выученное и расширять свой стек...
Скорее всего большинство технологий, которые сейчас в виде фреймворков и библиотек отомрут, а лучший функционал будет включен в браузерные движки, как случилось с JQ.
Нормально реализуют поддержку модулей- отомрут requirejs и прочите загрузчики
Нормально реализуют спецификации ES015- babel здохнет, точнее будет следующий =)
Реализуют поддержку http2.0 — наверно отомрет webpack как таковой
Реализуют web components — отомрет reactjs, если в dom движок включат virtual dom деревья.
а еще могут включить sass в нативную поддержку и т.д
Вообщем, все так пока сложно, потому что платформа развивается прямо сейчас и много шума...

P.S Пока я это писал, где то злобный человек сидит и кодит очередной фреймворк, который завтра Вам придется учить=)

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Открываешь библиотеку — ищешь нужную вещь — читаешь код — профит

я б советовал разобраться в основах и просто писать код и понимание зачем оно надо придет само собой...

Отчасти согласен с автором этого поста, в мире фронтенд не хватает такого себе django с отличной документацией и тоннами примеров. Чтобы развернуть проект на джанго не нужен зоопарк инструментов, которые делают примерно тоже самое. Я все жду когда 85% этого джаваскрипт безумия сдохнет и останется 1-2 фреймворка и какой-нибудь gulp :)

Думаю, останутся веб-компоненты, когда все 4 спеки перейдут в Candidate Recommendation.
caniuse.com/#search=components

эм. роутинг на компонентах?
загрузка данных вместо контроллеров — через HTML Import? :)

понятное дело, что нет :)
я имел в виду общую тенденцию «асфальтирования тропинок» и постепенной стандартизации.

кстати роутинг на компонентах уже написан

чуть подробнее, пожалуйста
интрига-интрига!

Я все жду когда 85% этого джаваскрипт безумия
оно и так не живое :)

поэтому будет плодиться и дальше.

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

останется 1-2 фреймворка
для здоровой экосистемы этого мало. особенно такой где нужны фреймворки разной весовой категории. так что с 10ок основных будет.

и уже вобщем-то понятно кто живой в фронтенде минимум еще пару лет.

просто тусовка еще незрелая, поэтому всякий хайп воспринимает как мейнстримовский тренд.
наладится.

Я фронтенд видел только как bootstrap + jquery ибо мне больше нравится бэкенд, решил поизучать что есть лучше, но вот какой из фронтенд фреймворков проще в освоении для таких как я, до сих пор не понял

что есть лучше
чем
bootstrap + jquery
для — чего?

именно из-за разной сложности UI и будут существовать разной навороченности фреймворки.

если не углубляться в теорию классификации фронтенд фреймворков, то в жизни оно как обычно, со старта с bootstrap + jquery:
(лисапеды опускаю)
более сложный UI требует много писанины, код разваливается... ищем, находим довеску к jquery
например JQuery Easy или PrimeUI. может еще какую микролибу для event driven jQuery
живем на них.

но задачи усложняются...
ищем, находим Can.js, Backbone, Knockout

еще усложнилась жизнь
усилили Backbone с помощью Marionette или Chaplin
зажилось веселее

еще усложнилась, опять грусть. находим
Angular, Ember, React + addons

если добавить в эти ступени создание приложений на js для смартов ... то появится 2ое измерение, придется рисовать таблицу. если добавить подходы — то 3е. поэтому пока не будем :)
важно что безумие творится преимущественно на первых уровнях. народ ваяет замены jQuery которые обычно ничего существенного не дают к названным.

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

можно конечно и сразу — проработать пару толковых книг по JS и за Ember сесть.
но в таком подходе есть неприятный момент — не понимая, не зная, не ощущая для какой сложности UI нужны тяжеловесы. особенно типа ExtJS(нам например постоянно нужны, живем и будем жить на нем, и ангуляры с реактами нас не беспокоят), Dojo, будет непонятно — а на кой они такие навороченные, сложные, в сравнении с тем же Backbone
и это будет тормозить изучение. и плодить непонимание — где их сложность оправдана, а где — недочеты разработчиков, следствие эволюционного наращивания функционала

Задача — получить SPA без великов на jquery, и т.к. это будет pet-project, хочется чтобы было простое в освоении. Много прошу?)
Backbone мне чем то реакт напомнил, нужно до кучи собрать тонны либ и заставить все это как-то работать...

Задача — получить SPA без великов на jquery,
ну так я дал уровни. там есть.
Backbone мне чем то реакт напомнил
и про это есть.
собрать тонны либ и заставить все это как-то работать...
ну тогда может забейте вообще? ;)

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

хотя, можно и не такого монстра. есть ушедший с хайпа qooxdoo
ему тоже jquery не нужен.

третьего пути нет:
— либо в фундаменте jQuery или аналог и либы с боку и сверху, по задаче
— либо «ExtJS»

особенно типа ExtJS
прекраснейший фреймворк.

единственное не пойму, как в ентерпрайзе сумел прижился убогий ангуляр, а не extjs...

Статистики у меня нет даже потолочной, но имхо ангуляр НЕ прижился в энтерпрайзе. Просто Ext JS не в хайпе уже. Как многое в энтерпрайзе

ну у меня контора пишущая энтерпрайз онли — и только ангулярю когда ходил по собеседованием только на одном энтерпрайз проекте был extjs все остальное ангуляр...

хотя интересно бы было увидеть реальную статистику, правда такую никто не собирает

как в ентерпрайзе сумел прижился убогий ангуляр, а не extjs...
так гугл же)

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

З.Ы. а так не удивлюсь, если ангуляр через какое-то время заглохнет, хотя наверное вряд ли...

Ну почему «наверное»?
Корпорация добра имеет нас всех за бесплатных тестеров любого бреда.
Ангулар 1 жив? GWT — где? Ангулар 2 почему-то пользует TypeScript, а не Дарт итд итд.

Параллели с паскалем наталкивают на мысль, что вы не открывали ниодной нормальной книги по js’у. При нормальном понимани азов проблем с фреймворками не может быть. Осилите хотя бы половину Фленегана — тогда возвращайтесь.
Или вы рассылаете резюме на mid/sen вакансии? Тогда заканчивайте это :)

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

Фленегана
соглашусь, что нужно осилить, и буду это делать)

Фленеган, Закас, Стефанов. И всё у вас будет хорошо ;)
И уделите особое внимание event loop, reflow/repaint и DOM-модели, а-то уже грустно становится от сегодняшних js senior’ов

А как часто вы встречаете js seniors?

Тех, которые себя позиционируют как senior — часто. Если же считать тех, кто соответсвует требованиям senior позиции — 1-2 человека в месяц, иногда — реже.

Фигасе, я ни одного за всю жизнь не видел кого можно назвать синьором. (Моя лычка не в счет)

У вас через чур пессимистичный взгляд — всё плохо, но не настолько :)

он бы не был таким, если бы был хоть один оптимистичный опыт

Из знаний паскаля в JS может помочь разве что понимание, что такое циклы и массивы.
В остальном — синтаксис из C, регулярки из Perl, функциональщина из Lisp.

Фленаган многих отпугивает. Лично я посоветую:
1. Стефанов — «Object Oriented JavaScript». Да, я в курсе, что книга 2008 года и по EcmaScript3. Читать в оригинале.
2. You Don’t Know JS — минимум первые 4 книги. Тоже в оригинале.
3. Крокфорд «JavaScript. Сильные стороны» — есть хороший перевод. Читать несколько раз, с перерывами. Там есть сложные моменты.

Эти книги имеют вменяемый для осиливания объем и дадут базу. Что останется неясным — читать у Кантора. По работе с DOM — там же.

Вот кстати все советуют серию книг You don’t know javascript. Я сам с js’ом начинал знакомиться по онлайн учебнику javascript.ru, где-то через полгода еще раз перечитал весь этот онлайн учебник, а потом наткнулся на серию книг You don’t know javascript, которую мне рекомендовали многие коллеги. И вот в чем беда: я прочитал всю серию этих книг и не нашел ни одного нового для себя факта о js’е. Все это и многое многое другое я уже прочитал в онлайн учебнике, причем намного более понятно, доступно, структурировано и с примерами. Поэтому не особо понимаю всеобщий восторг от You don’t know javascript.

Кайли Симпсон (автор YDKJS) как раз акцентирует внимание на тех нюансах, в которые обычно не вникают. Там всё это детально разжевывается. Плюс достаточно понятный английский.
Хотя, согласен, у Кантора всё важное тоже изложено.

По мне, так еще классная данная книга eloquentjavascript.net.

С реактом всё не так страшно. Я, когда разобрался с основами, написал статью — советую просмотреть.
А вот на днях с Polymer осваивался — понял, что реакт простой :)

Прекрасное выступление, думал посмотреть только начало (какая тема) и приходится смотреть до конца :)

Но вот последнее время я наблюдаю такие тенденции которые, откровенно говоря, немного бесят.

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

брать те фреймворки и библиотеки, которые:
1. нравятся,
2. более-менее востребованы (т.е. их используют в реальных проектах)
и
3. к которым можно найти нормальную документацию (и/или статьи-книжки).

А тыща упоминений о какой-то библиотеке, к которой нихрена вменяемого нет могут идти лесом) ибо если оно кривое, то ты ее все равно хрен освоишь)

Я изучаю его уже около года и за это время я примерно осознал тот стек технологий, которые необходимо изучить для дальнейшей работы.
А написали за год на JS что? Ничего? Тогда боюсь программирование — вообще не ваше.

Для первых шагов в изучении React вовсе не нужно понимать как устроен webpack. Есть пара десятков готовых boilerplate’ов, которые нужно просто склонить и вперед писать код. Настройку babel покрывают 99,99% таких boilerplate’ов.
Другое дело, что необходимо понимать какие подходы несет React (декларативность (ну или почти декларативность), one-way data binding, immutability), какие мотивы их появления, понимать что такое Flux (Redux в частности и их разницу) и как его готовить.

По React и экосистеме сейчас появилось настолько много статей, видео, курсов (большинство бесплатные) за очень короткий период времени, что становится страшно. Я разбирался с React в ноябре 2015 и нехватка хороших материалов ощущалась. Сейчас я готовлю доклад на KPI JSUG и у меня складывается впечатление, что доклад вовсе не нужен, ведь всё и все уже обсудили это в интернете.

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

яваскриптовое безумие
Это прекрасное определение того, что щас творится в мире JS, особенно в мире Node.js, там как будто каждый адепт считает своим долгом написать собственный велосипед. Хочешь выбрать библиотеку, идешь в npm, а он тебе, на!... вот... подавись... 100500 вариантов. Как метко заметил мой начальник: «Ну, и какая JS библиотека для нашей задачи самая лучшая?.. На этой неделе :)»

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

чем серверные вычисления особо помогут веб приложениям?
никто же не заставляет писать фронтенд на конструкторе «для самых маленьких», мобильные девайсы сейчас грубо говоря как средний pc 5-8 летней давности- нечего ныть, хотят писать говно код и чтоб оно летало везде.

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

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

речь о том что вооще не надо писать с помощью клиентских фреймворков.
И кто сказал что должно быть именно веб приложение? С точки зрения пользователей - это просто сайты . Так же как и в 90х.
Юзеров интересует информация и не понты вебразработчиков.
Именно поэтому и появился флетдизайн и гуглестайл.

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

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

пользаков больше раздражает тупящая страница с какой нибудь крутилкой чем привычная перезагрузка.
ага. поэтому это и не альтернатива.
альтернтива — это отправка в бекграунде. асинхронность.
которая полезна еще и в случае сбоя, например.
или по-вашему, если сообщение «извините, соединение с сервером отсутствует» сменится на «о, вот, только что отправлено» это хуже «уууп, адрес не обнаружен»? и сиди думай, что будет после F5.
Но пример не очень удачный — сколько процентов содержат чаты и другие решение с мгновенными сообщениями?
любая интерактивность. формы-фильтры, поиск, визуализация информации, валидация(давайте! скажите, что ради проверок на циферки в поле фреймворк не нужен и я приведу в пример асинхронные и комплексные валидации, которые без структуризирования приведут только к головной боли)

фреймворк — это про структурирование. даже если это будет самописные слои-абстракции. даже если не будет звучать слово «модель». если там логика сложнее «вывести алерт если данные отправлены», то структурирование нужно.

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

альтернтива — это отправка в бекграунде. асинхронность.
об это я и говорю — пользаку все равно ждать данные что он запросил. И асинхронность тут не поможет. Разве что на том конце Ванга сидит.
у, если сообщение «извините, соединение с сервером отсутствует»
отсутствие соединения приводит к неработоспособности приложения и обсуждать остальное не имеет смысла
что ради проверок на циферки в поле фреймворк не нужен и я приведу в пример асинхронные и комплексные валидации,
не надо приводить экзотические примеры. Давайте с точки зрения принципа Парето говорить о 80 процентаз обычных сайтов
если вы к тому, что на клиенте логики не должно быть вообще — оооок. тогда я умываю руки, признаю поражение, сдаюсь, заматываюсь в простыню и ползу на кладбище
в подавляющем количестве случаев логике на клиенте нечего делать. Разве что какая интерактивная игра в пределах браузера.
ОТкройте наугад 100 сайтов и покажите в более чем в пяти что там никак без клиентской логики. К примеру сайт на который вы шас смотрите — какая тут нужна особая логика да еще с применением фреймворка?
речь о том что вооще не надо писать с помощью клиентских фреймворков.
давайте связывайте его- я разожгу костер, а там уже народ подтянется=)

SPA вигалади не просто так, задля маркетингу. В певних задачах цей підхід є найкращим з точки зору зручності використання. Але ж варіацій архітектур SPA може бути маса: MVC на клієнті, всі дані ганяймо у вигляді JSON/XML, FRP на клієнті із передачею тільки даних, або класичний REST, коли з сервера приходять вже відрендерені HTML шматки. Вибирай — не хочу.

Не спорьте с Леонидом на эту тему, все равно бесполезно

разумеется бесполезно спорить с очевидными вещами

Фигня. Пользакам пофиг — им хоть статический HTML
а разработка таких страниц гораздо более сложная. Нет никакой вменяемой причины для 99 процентов сайтов гонять данные перепаковывая их туда сюда в различные форматы передачи.

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

речь о пользователях — то есть посетителях, которым пофиг, они за инфой приходят а не вашей распальцовкой.
читайте внимательно прежде чем расказывать мне прописные истины которые я знал когда вы еще в детский сад ходили.
А UI для програмистов это и есть клиентские фреймворки, асинхронка, API и прочее.
Так програмеры зарабатывают — усложняя то что нафиг не требует усложнения на ровном месте и впаривая заказчикам что это типа тренд и кто так не делает тот лох..

Правильно, користувачі ходять за інфою, і вони таки хочуть споживати цю інфу не аби як, а зручно. Відчуваєте різницю?
І не треба тут хизуватися своїм віком. Доросла людина не значить мудра або розумна. Може так статися, що саме професійний вік вашого опонента буде більший за ваш.
Ускладнення бувають різними. Інколи так, трапляється, що там де не треба городити город, його таки городять. А інколи це необхідна умова, бо саме так зручно користувачам.

Ту же ситуацию наблюдал в RoR, когда для любой задачи был gem

Мой тебе совет, не сиди столько без работы (именно из той сферы, куда ты хочешь). Иди по собеседованиям, если чего-то будет не хватать, тебе скажут. Иначе так можно долго сидеть в вакууме и «совершенствовать скилл».

По реакту рекомендую начать здесь — github.com/petehunt/react-howto
Все по полочкам, one thing at a time

ну я тоже в процессе изучения и меня тоже пугали некоторые вещи. Но, как ниже написано, это скорее из-за непонимания для чего и зачем все это нужно. Так автоматизация, например, для была пустым звуком, пока сам не попробовал и основательно не засел за грант. Просто тут главное понимать, что инструменты и фреймворки служат для облегчения жизни, а не наоборот. Кстати, еще не встречал (возможно из-за неопытности) откровенно «плохой» документации.

Если у вас нет опыта работы в индустрии, но вас в этой индустрии уже что-то бесит, рекомендую пересмотреть свое отношение к жизни

Ну как бы он не один такой. Мне нужно, чтобы написать простейшее приложение, изучить еще 3-4 технологии, причем если открыть этот код пару месяцев после этого, все устареет и придется все переписывать.

если открыть этот код пару месяцев после этого, все устареет и придется все переписывать

Это как? Код через пару месяцев просто возьмет и перестанет работать?

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

Ну у того разработчика там другая проблема — не в зелености и не понимания что и зачем, а проблема выбора инструментов...
Ну веб развивается семимильными шагами... а как Вы хотели то? Потискать «веб» с нуля годик и уже все профит=? Да на это нужно много времени, много сил, выдержки ну или скажем честно- задротства. Радуйтесь хоть, что в такое время начали, когда знаете чем будете заниматься, а не учили все сразу начиная от мк, схемотехники, прикладного и системного программирования и заканчивая вебом- выучить один фронтенд — относительно недолго, но все ровно придется каждый день обновлять выученное и расширять свой стек...
Скорее всего большинство технологий, которые сейчас в виде фреймворков и библиотек отомрут, а лучший функционал будет включен в браузерные движки, как случилось с JQ.
Нормально реализуют поддержку модулей- отомрут requirejs и прочите загрузчики
Нормально реализуют спецификации ES015- babel здохнет, точнее будет следующий =)
Реализуют поддержку http2.0 — наверно отомрет webpack как таковой
Реализуют web components — отомрет reactjs, если в dom движок включат virtual dom деревья.
а еще могут включить sass в нативную поддержку и т.д
Вообщем, все так пока сложно, потому что платформа развивается прямо сейчас и много шума...

P.S Пока я это писал, где то злобный человек сидит и кодит очередной фреймворк, который завтра Вам придется учить=)

Реализуют web assembly — отомрет javascript, node.js.

Это достаточно далекое будущее в контексте web=)
Как я понял, там никто не собираеться выбрасывать экосистему js, его семантику, скорее всего все ограничиться полной «перезагрузкой» виртуальной машины/компилятора и переход к «бинарному виду», что вполне логично с http2.0. Сам язык вряд ли кто вырубит под корень или сможет это сделать в обозримом будущем, по этому с точки зрения dev’a будет все тот же js, но компилируемый, и все та же nodejs.

А мне показалось, что они торопятся WebAssembly may go live in browsers this year
Не просто так понасоздавали статически-типизируемые, компилируемые в javascript языки: dart, typescript. Последний широко используется в продакшене. И еще куча транспайлеров с scala, clojure, java и многих других(не уверен используется ли в продакшене) возникли не от хорошей жизни. А вообще мне нравится javascript в той форме которую предоставляет ES6 с typescript вообще конфетка. Использовать вместо него для UI к примеру C#, Java, C++ здорово, но замедлит скорость разработки. Хотя я могу ошибаться, и в далеком будущем мы все будет наследоваться от к примеру UIViewController, UIViewSearchBox и кастомизировать все в 2 клика.

Сама идея это интересная, но опять же внесет столько неразберихи, что будет как обычно- мало кто будет использовать в реальных проектах, а чисто так для «тисканья». Как по мне, нужно хоть что то им до ума довести, все так медленно реализовывается, простые вещи типа Object.observe через 10 лет начали только в спецификацию добавлять, а полную поддержку на года растягивают, хотя всем еще в году 2009-2010 было ясно что это c разряда must have. И так куда не посмотри. В еще не реализованной модульной системе ES2015 нет хотя бы выгрузки этих самых модулей при асинхронной линковке.
Жесткая статическая типизация портит концепцию языка, но вот опционально указывать тип переменной для помощи компилятору в оптимизации было бы неплохо.

наследоваться от к примеру UIViewController, UIViewSearchBox
В этом направлении как бы и движемся- компонентная разработка вполне на это похоже. И опять же долго доходило до отцов основателей необходимость этого: всё есть модули, ui — компоненты. По сути надо скопировать лучшее с прикладного программирования UI и адаптировать под веб и парадигму js.
Производительность js меня лично мало волнует, а если начинает волновать — то потому что ее съедают полифилы и тяжелые фреймворки. native реализация основ их убрала бы необходимость в радикальных изменениях.

Солидарен, но с двумя нюансами

Производительность js
native реализация основ их убрала бы необходимость в радикальных изменениях
  • Да, убрала бы. Но для игрушек все равно не хватит.
  • Это только половина беды, а вторая (проблема загрузки/парсинга) осталась бы не решенной.
Web assembly ее тоже решает:
The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user experience.
Why create a new standard
(проблема загрузки/парсинга) осталась бы не решенной
Это решает предкомпиляция в бинарую форму, но это отношу не к развитию языка, а к оптимизации компилятору, в идеале это никак не должно отобразится на семантике языка или чем то еще. Так как у http2 все в бинарной форме да и с мультиплексированием запросов выглядит многообещающее.
JS игры в вебе, пожалуй, несколько другая тема чем сам web, наверное это единственное место где будет всегда не хватать производительности. Для взрослых игр вряд ли js годиться с любыми будущими компиляциями и оптимизациями, хотя если там можно будет подгружать модули на с++, скажем, а те модули игровые движки всякой там физики упругих тел и WebAssembly даст возможность взаимодействия, то саму игру может и будут писать на js. ...мечты-мечты=)
Это решает предкомпиляция в бинарую форму, но это отношу не к развитию языка
Что вы под этим подразумеваете ? компиляция js в нативный код ?
Так этого никогда не произойдет)

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

Передача на выполнение не исходного кода, а уже оптимизированного внутреннего кода под движок
уже было, asm.js и выгорело
avoiding the simultaneous asm.js constraints of AOT-compilability and good performance even on engines without specific asm.js optimizations
+ asm.js так и не решал проблему парсинга.
построение внутренних структур перед выполнением... вообщем работа над этим там как бы шла...
предполагаю что речь идет об Abstract Syntax Tree (AST)
Так вот WebAssembly и есть тот стандарт который описывает как любой язык, к примеру C++ должен преобразовываться в AST.

ну разумеется было=) Об этом уже говорили последние годы все кому не лень. Да, WebAssembly замахивается на гораздо большее. Штуки это все внушительные, но выйдет ли оно за рамки экспериментов, никто пока не скажет. Меня больше волнует что в это время, пока они играются с экспериментальной технологией, туча куда более простых вещей до сих пор остается не реализованы, которые бы дали реальный профит гораздо большему количеству разрабов в том числе с производительностью, чем профит от теоретического ускорения (но, кажется, весьма реального) в специфических клиентских приложениях от этого WebAssembly.

Дарт — рожденный мертвым.

ТайпСкрипт успешен изза близости к джс, он именно расширяет а не меняет все.

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

Вебассембли будет своего рода бекендом на фронтенде, и юзатся будет для игр да и всякими графическими онлайн редакторами

Куча транспайлеров с других языков — просто сравните скорость написания на джс и любом другом языке.
Именно это я в своем первом коментари и написал
Использовать вместо него для UI к примеру C#, Java, C++ здорово, но замедлит скорость разработки.
А по поводу,
Вебассембли будет своего рода бекендом на фронтенде, и юзатся будет для игр да и всякими графическими онлайн редакторами
поживем увидим, динамический язык хорош только на небольших — средних кодовых базах. А с учетом смещения бизнес логики с бек-енда на UI, размер кодовой базы на UI растет быстро.
И повторюсь, не от хорошей жизни понасоздавали кучу транспайлеров с других стат. типизировнных языков. Это нам говорит что количество людей готовых, желающих писать UI на своем любимом компилируемом языке больше чем программистов в гугле.

ТайпСкрипт или более зрелые фреймворки на джс вполне позволяют писать огромные приложения на фронтенде

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

Ну а что вы хотели х**к-х**к и в продакшн?

Пример тому документация по react: для его изучения, для начала нужно понять что такое ...
Вот тут у вас ошибочка. Первое что нужно понять это нафига козе баян. Если быть точнее — это зачем вообще какие-то люди понапридумывали эти всякие фреймворки. Не можете — не начинайте со сложных фреймворков, поверьте говнокодить получится одинаково хорошо, как на реактах, так и на vanillajs.

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

Вот вам простой рецепт:
1) Верстаете сотню-другую страничек с разным содержанием, но с общими хедером/футером без всяких айфреймов
2) Добавляете на каждую страницу аякс-запросы на получение данных откуда-то
3) Объединяете их все в SPA с использованием новомодного HTML5 history API
4) Делаете так, чтобы загрузка всего «сайта» с удаленного хоста была меньше 1с и размер его не превышал пары мегабайт.
Далее итеративно проходите все пункты, используя сначала просто какой-нибудь jquery, потом пробуйте то же самое с шаблонизаторами, потом с другими либами, потом с фреймворками.

Успех гарантирован. Вы начнете понимать фреймворки без копаний в доках и галп станет вашим верным другом. Помните, ваша главная цель — боль и страдание, познаете их и вам дадуться любые фреймворки.

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

Есть такая фигня: «если в техническом тексте встречается непонятное слово, пропустите — текст отлично читается без него». С новыми технологиями отлично работает: мысленно подставляете вместо чего-то непонятного переменную, и со временем понимаете свойства объекта, который в этой переменной хранится. Ну то есть как раз для чего например нужен webpack, для чего нужен babel итп.

Про React: долго не мог понять чего от него торчат фронтенды. Открываешь статьи: какой-то нудный разбор того как написать компонент. Ну ок, написали, за каким-то чертом впихнули в JS кусок HTML, или генератор HTML на их местном наречии. Удовольствие мягко говоря сомнительное. Все стало на места после просмотра собсно презентации flux и React от авторов. Правда, они чуваки специфичные, у всего что делают фейсбукчане есть паттерн: «мы даем идею, открываем код, а дальше нормальный инженер разберется», поэтому если привык шо все разжевывают по винтикам — может быть необычно/сложно.

ага теперь прочитал
ну если вам это все не нравиться — вон из профессии. Вильна касса кричать или мобилками торговать на серьезных щах

хорошему программеру нужно гдето 60-80 часов что бы войти в какуюто технологию и начать писать код. Если технология новая вообще то может понадобиться и 100 часов, если, какая то близкая то может быть и 20 часов бедет достаточно. Не ожидайте что у вас это займет 2-3 часа, расчитывайте что потратите около 2х недель и тогда не будет разочарования почему так все запутанно и непонятно

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

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

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

Но вот не задача, его по уму надо компилировать в ес5, а пол доки реакта не только джск юзает но и ес6.

Дальше вы начинаете гуглить о том как это все запустить. А тут нужна система сборки, а их 3, и чтобы их поднять нужна нода. Вы не разбираясь детально с процессом сборки пытаетесь сделать как нибудь, чтоб работало, но че то оно как то не запускается.

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

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

И да, дальше будет только хуже

С Ember сейчас легко в этом плане. Есть ember-cli, который умеет все собирать и не надо по отдельности разбираться с разными утилитами. Ну и документация для новичков по-моему очень понятная, уровня «для установки введите такую команду»

Но и там есть нюансы + еще переходные процессы во 2й серии ... Но вообще, да, мне он больше всего нравится — это действительно инструмент который покрывает все необходимые аспекты

стена текста прям
я только уловил что он хабрераст и фронтендщик на паскале

Как-то разбил, статья на Хабре по идее эта:
habrahabr.ru/post/277323

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