Pull to refresh

Comments 298

UFO just landed and posted this here
UFO just landed and posted this here
Я думаю это часть моды. Делать инструменты — проще, а главное романтичнее, чем скучные аппликации для пользователей.
Я думаю, дело не в моде.
Толстые клиенты умирают, а толстые программисты нет. Не найдя на веб горизонте привычных классов, делают свой инструментарий. Добавьте хорошую документацию и вот вам фреймворк.
>Не найдя на веб горизонте привычных классов,

Ext.js — Привычные классы — свыше 300 штук.
UFO just landed and posted this here
АППЛИКАЦИЯ, -и; ж. [от лат. applicatio — прикладывание]. 1. Способ создания изображения посредством наклеивания или нашивания на что-л. разноцветных, разнофактурных кусочков ткани, бумаги и т.п. А. на шёлке, картоне. 2. Картина, украшение и т.п., изготовленные таким способом. Сделать аппликацию. Передник с аппликацией. 3. Физиотерапевтическая процедура: накладывание на какой-л. участок тела лечебной грязи, парафина и т.п. <Аппликационный, -ая, -ое (1 зн.). А-ые работы.


application сущ. комп. прикладная программа (program)
Поищите в том же словаре ещё такие слова, как дедлайн, митап и эджайл.
Некорректный аргумент: коротких устоявшихся аналогов, имеющих такой же смысл и коннотацию этим словам в русском языке нет, поэтому мы их заимствуем напрямую.

Слову application есть — это «приложение» или «прикладная программа», в то время как «аппликация» — это либо медицинский термин, либо вид картины, выполненной при помощи наклеивания.
Т.е. употребление слова «аппликация» вместо «приложение» в данном контесте — безграмотность и отсутствие чувства языка. В то время как употребление слова «дедлайн» — норма.

Точно так же как expertise — это «мастерство» или «опыт». А «мы продаем экспертизу» — нелепый набор слов, потому что «экспертиза» в русском языке имеет иной смысл, как во фразе «проведена криминалистическая экспертиза».
Жестокий и строгий ваш ответ то.

Товарищ хотел просто написать «апликухи» — но рука просто дрогнула у него.

Имхо, конечно, имхо. ;-)
Статья сильно натянута.
btw, что ещё за «Jash Kenas»? Его зовут Jeremy Ashkenas — автор coffeescript и underscore.
Сообщество JavaScript безумно, если оно думает, что кто-то может идти в ногу с этим.

Самое главное — что в ногу с этим не могут идти браузеры. Следовательно, и нам не стоит, чтобы не отрываться от реальности.

За чем конкретно из списка выше не успели браузеры?)

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

Эм, старые версии браузеров, в смысле?)

UFO just landed and posted this here

Вы понимаете, что edge лучше поддерживал ES6 какое-то время, а у нового safari вообще 100% поддержка, судя по ES compatibility table?

UFO just landed and posted this here

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

У edge очень своеобразное мнение на счёт того, как должен работать метод postMessage. Поэтому приходится для мелкомягких чертей отдельное поведение реализовывать (ага, и детектить их для этого).

Мелкомягкие черти в первую очередь. Из-за необходимости поддерживать всё что можно и что нельзя, языковые нововведения может быть появляются в рабочем коде года через два после их анонса. А может, не появляются. Мы, например, до сих пор тянем версию для IE8, где даже JS1.6 нативно не поддерживался.

Edge такое же ненужное гуано, как как и его предшественник, пока не запилят расширения
UFO just landed and posted this here

И тысячи их! (точнее, овер 200 000 человек)

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

Приложению на три таблицы не требуется поддержка? Почему бы не использовать чистый JS.

Если же приложение больше, то никакого такого ада там и нет. По мере необходимости из широкого ассортимента выбираются инструменты и им находится применение. И TypeScript будет в радость, и обилие npm пакетов и сборщики. Есть возможность собрать проект без webpack — замечательно, хотите использовать React с jQuery? Без проблем.

Но многим хочется готовых мануалов «Как стать модным фронтом 2016+», много лет назад они брали и писали же на чистом JS такой-то UI и все хорошо было то, а теперь надо же придумали! Хочется сразу использовать всю мощь, но что бы не разбираться. Но тогда и мощи не было бы, разрабатывали бы мощный фреймворк all-in-one, тратили бы годы на стандартизацию, имели бы мы приложение уровня 2005 года, зато было бы спокойно и понятно все.
UFO just landed and posted this here
Не может быть так, чтобы масса суперуниверсальных разработчиков не уменьшалась в таких условиях. Уменьшается масса, снова становятся востребованы разработчики с опытом решения реальных задач, а не мультистековые ребята, тратящие на поддержание своих знаний 90% рабочего времени.

В общем не понимаю, как эта ситуация хуже стала? Раньше разработчик разбирался в JS + jQuery и поверх писал свои велосипеды, а сегодня использует готовое, разбираясь в вещах уровнем выше, но не брезгуя смотреть открытый код? Получается проработав N лет, точно так же терял это время на специфичную для клиента систему, а сейчас только отрывается на несколько версий фреймворка, если совсем не смотрит по сторонам.
> Первая проблема в том, что работая в своем органичном стеке в течении двух лет,
> Вы выходите на рынок устаревшим, потому что всем нужен уже <Впишите имя> фреймворк.
ИМХО, это как бы и не проблема. Веб-разработчика «продаёт» его портфолио, а не знание фреймворков. А заказчик, в общем случае, говорит: «Мне нужен сайт с таким-то функционалом», и практически никогда не говорит «Мне нужен сайт на Angular».
У нас, к примеру, разработка сайтов направление непрофильное, но вполне активное. И мы давно уже не ввязываемся в эту гонку вооружений. Никакой выгоды с этого мы не получаем, т.к. затраты ресурсов на освоение и внедрение в проектах свежих новинок в мире JS нынче превышают преимущества от их использования.
Это если исходить из краткосрочных проектов под множественных заказчиков. А если ищешь работу, то в объявлениях достаточно часто указываются конкретные фреймворки. И, к сожалению, на собеседованиях порой любят гонять именно по специфичным для фреймворка вопросам. К счастью, однако у большинства работодателей (по крайней мере тут, в Чехии) существует прекрасное понимание того, что мир JS быстро эволюционировать, чтобы ждать мега-профи по какому-то конкретному фреймворку. А с учетом того, что по крайней мере в бекенде, часто JS используется для микросервисов, то больших познаний всего обилия, перечисленного в статье, и не требуется.
> если ищешь работу, то в объявлениях достаточно часто указываются конкретные фреймворки. И, к сожалению, на собеседованиях порой любят гонять именно по специфичным для фреймворка вопросам.

Речь о конкуренции. Если требуется JS программист, пришло трое, один знает ext.js, второй angular 2, третий react.js, а проект будет разрабатываться (допустим уже известно) на react.js — то кого возьмут?

Ответ обычно очевиден.

И не важно, что мир JS меняется стремительно. — Речь о конкуренции на рынке труда.
UFO just landed and posted this here
В текущем JS-хаосе это как раз нормальный вариант… Лучше через 5 лет изучить то, что будет тогда актуально, чем каждый месяц учить что-то, что через 5 лет никому нафиг не нужно будет :-)
> Это прекрасно ровно до того момента, когда дев с 5+ лет работы у вас, решит походить на собеседования.

Со стороны работодателя, это прекрасно и после.
UFO just landed and posted this here
Да не так уж и грустно, на самом деле. Вы думаете, разработчику JS будет полезно набивать свои мозги технологиями, которые будут неактуальны через пару-тройку лет? Если речь идет о своей полезности на рынке, то достаточно потратить несколько месяцев перед тем, как выходить на рынок труда, на изучение того, на что в настоящее время есть спрос. А не поддерживать себя во мнимой актуальности, затянув в свои мозги огромный зоопарк фреймворков и инструментов, 90% которого не пригодятся больше никогда.
UFO just landed and posted this here
Первая проблема в том, что работая в своем органичном стеке в течении двух лет, Вы выходите на рынок устаревшим, потому что всем нужен уже <Впишите имя> фреймворк.


tl;dr — вообще в вакансиях сейчас всего два фреймворка: AngularJS и React.

Если подробнее, то сильно преувеличено. Давайте разберем на
примере
image


Формально здесь видно четыре столбика из ExtJS, Backbone, AngularJS и React.
Здесь и далее имеется в виду сайт hh.ru и город Москва (поскольку я из Москвы), и Киев (из вашего профиля)

1) Начнём с ExtJS. В принципе этот старичок сегодня даже в статье упоминался, но в вакансиях бывает часто. Не забываем в запросе дописать «extjs not angularjs not angular not react». Число вакансий уменьшится на 1/3 (для Киева вообще вдвое) по сравнению с запросом только «extjs». В оставшихся вакансиях часто требуется не чистый «фронтендер», а всякие ASP.NET, Java, PHP и прочие бэкендеры от которых будут просить еще и фронтенд писать. Чистых вакансий на фронтенд, где требуется ExtJS и не подходит ангуляр или реакт, я нашел штук 5 в Москве и 0 в Киеве.
2) Далее Backbone. Он упоминается в 123 вакансиях для Москвы, но без AngularJS и React только 29. Для Киева цифры — 34 и 11 соответственно. Итого, если вы не знаете уже слегка подустаревший Backbone вы потеряете максимум треть от тех вакансий, где его просят.
3) AngularJS. Его первая версия — один из стандартов SPA разработки сегодня. В Москве на него аж 300 вакансий, отдельно от React — 234.
В Киеве — 72 и 58. Да ангуляр стоит учить.
4) React. Появился в 13, массовое распространение в 14. Всего вакансий в Москве и Киеве — 224 и 58 соответственно. Без ангуляра 178 и 30.
Реакт тоже стоит уже учить, если не выучили.

Другие фреймворки
5) Ember: без AngularJS и React нашел одну вакансию в Москве. В Киеве не искал.
6) Vue.js: без AngularJS и React в Москве не упоминается.

Другие технологии
1) ES6/ES2015 — суммарно около 80-ти вакансий в Москве, почти везде пишут, что знание рассматривается как преимущество.
2) TypeScript — 78 вакансий в Москве, как требование выдвигает примерно каждый третий.

Итого на рынке труда фреймворков сейчас два, массовое распространение их началось 4 и 2 года соответственно. Для трудоустройства будет достаточно любого из них. Через годик хорошо бы что-то прочитать про ES2015 и TypeScript (это опять же для рынка труда, нормальные разработчики и так про них в курсе).
UFO just landed and posted this here
> Даёшь JavaScript on Rails!

Уже дали и назвали CoffeeScript — Но НЕ ВЗЛЕТЕЛ.
UFO just landed and posted this here
Вы совершенно правы.

«Если копнуть немного истории, то с 2009-го года язык писался на Ruby, с 2010 — он пишется на самом же CoffeeScript.
И в Ruby on Rails, начиная с версии 3.1, он «заменил» JavaScript.»

В итоге:
— 3 дня потратил на настройку среды;
— 10 дней машинного времени на 1500 сборок;
— 2 часа писал уникальный код;
— 3 дня на обьяснение заказчику своей крутизны;
— 10 дней на споры с заказчиком о ньюансах архитектуры;
— за 2 часа рабочего времени получил оплату по тарифу 150 у.е./час (фактически по тарифу чернорабочего 10 у.е. /день за 30 календарных дней)

Все пошло на оплату интернета, комуналки и жрачку. Но теперь можно кичится, что за меньше чем за 150 у.е./час даже нефиг браться.
Зато на следующем заказчике можно нагреть руку. Да и вообще, получается, что ты учился, так тебе еще за это платили. Неплохо так.
UFO just landed and posted this here
>А потом оказывается что React умер. Angular 2 — не «пракатило!!!».
Все пишут на «WebAssabley». И вообще все хотят assembler в web!

Вряд ли мы можем СЕЙЧАС предугадать что будет через ПЯТЬ лет.
UFO just landed and posted this here
У меня дежавю, или я уже читал что-то в точности похожее на хабре? Даже повествование было таким же)
А я на ru.stackoverflow.com читал
Да, но раньше эта история была короче. Такой эволюционирующий баян.
Странно, похоже автор оригинала данной статьи не указал, что он дополнил другую.
пока читал статью написал фреймворк!
Пока читал комментарии этот фреймворк безвозвратно устарел.
UFO just landed and posted this here
Вы — счастливый человек, если не приходилось поддерживать код, который бы работал под 2.7 и 3.х одновременно :)
А не могли бы объяснить — зачем себя так мучить? Используйте python2 и не парьтесь.
я на данный момент занимаюсь разработкой в неком стартапе, у которого, кроме бизнес-пользователей, есть еще две категории разработчиков:
— математики/актуарии, которые привыкли к питону 2.
— современные разрабочики, интегрирующие нашу систему в целевые платформы, разрабатывающиеся сейчас, язык интеграции — питон 3

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

Ну так вот. Я это научное сообщество, которое привыкло к двойке и не привыкло меняться, хочу молотками по головам постучать. Они любят, например, jupyter, у которого ядро по умолчанию — питон 3. И любят они numpy/scipy etc, которые тоже сейчас по умолчанию под питон 3 разрабатываются. Но — они будут плакать и колоться, но жрать кактус, пытаясь установить jupyter + scipy + matplotlib + еще кучу всего, вместо двух команд в pip3.
Как молодая часть этого научного сообщества, я пытаюсь использовать и продвигать Python3. Но есть одна проблема: все расчёты обычно выполняются для кучи очень дорогих данных (как пример — коллайдерные коллаборации). И тут очень важно верифицировать инструменты, ведь один баг может привести к неправильным результатам для данных стоимостью в пару десятков-сотен миллионов доларов. Поэтому все по максимуму держатся за старые и проверенные временем инструменты.
Довольно редкая ситуация, как мне кажется.
Нет. Как раз абсолютно типичная. Стартапы могут позволить себе использовать python3, потому что им «нечего терять». И то не всегда, как видим.

В крупных же сообществах только сейчас потихоньку-полегоньку начинают задумываться о том, что они будут делать в 2020м году. Причём я не удивлюсь если будет принято решение выделить средства на то, чтобы поддерживать python2 — благо и делать-то там особо много не нужно будет.

В том же Android'е куча скриптов на python'е — и нет даже планов никаких по адаптации python3. Та же самая история — в Chromium'е. Обратите внимание на активность разработчиков в соответсвующем баге.
Я все-таки про общую картину со всеми разработчиками и проектами, в смысле что вообще со всеми.
А «вообще со всеми» — ситуация такая, как я и сказал: подавляющее большинство разработчиков — используют python2 и о переходе если и задумываются, то не очень сильно. Потому что для них python — это инструмент и переделывать всё-на-свете из-за того, что кому-то моча в голову ударила и нормального плана перехода так никто и не придумал — они не будут.

Люди, которые познакомились с python'ом после 2008го года, в основном используют python, но их пока — далеко не большинство. К тому же когда они приходят в компанию, где python начали использовать раньше они начинают «жрать кактус» вместе со всеми.

В результате после семи лет пения «всё хорошо, прекрасная маркиза» разработчики python3 начали задумываться над тем, как бы всё-таки убедить этих «ретроградов» перейти на новую версию.

Придумали много разных вещей, но не поняли главного: не будут люди в коммерческих компаниях переписывать свои скрипты. Не будут. Либо будут разработаны «транспайлеры», либо python2 заживёт отдельной жизнью рано или поздно.

P.S. На Хабре вы этого, впрочем, можете и не заметить, так как работает очень хороший отбор: людям, которые сделали что-то новое — важно об этом заявить на Хабре, людям, которые работают над проектом, которому лет 20-30 — это нафиг не нужно. Но правда заключается в том, что новых проекты — быстро возникают и быстро умирают, а проекты 30-летней давности остаются. Вместе с python2. Так что я, когда писал, что нужно писать на python2 и «не париться» не лукавил ни разу. Не бойтесь вы 2020го года — что-нибудь да придумают.
lamo4ok > Либо будут разработаны «транспайлеры», либо python2 заживёт отдельной жизнью рано или поздно.

Эка право. И тут Javascript обошёл всех, с идеей использования этих самых «транспайлеров».

:-0
Всё новое — это хорошо забытое старое. Транспайлеры JavaScript'а решают ту же задачу, которую решают модули TURBO3.TPU и GRAPH3.TPU, по сути.

Это как раз разработчики python3 предложили «уникальное решение»: скрипт, который превращает python2 в неработающий python3 — так что переход от python2 к python3 получается «по бразильской системе»: либо вам везёт и вы переходите успешно, либо вас увольняют нафиг, так как никакой возможности отката нет в принципе!

С тем же успехом можно переходить не с python2 на python3, а, скажем, с python'а на Go. Забавно впрочем, что и разработчики Perl'а и PHP наступили на те же грабли в 6й верcии языка… Только те оказались в состоянии понять — что произошло, а разработки python'а — пока нет…
UFO just landed and posted this here
Не вижу никаких проблем поддерживать код, который бы работал под 2.7 и 3.4+.
Вот поддерживать одновременно 2.7 и 3.0 — это да…
да офигенный, это просто хороший пример того, как можно делать версионность без 7 вариантов, которые нужно транспайлить из одного в другой.
Похоже, для персонажа из статьи, это не то, что ему нравится.
О как? А как по мне — так это отвратительный пример. Приведший к тому, что существует такое себе сферическое сообщество питонистов, объясняющих друг-другу как у них всё хорошо. И есть люди, которые реально используют питон — и им все эти чудеса по барабану. И которые просто используют python 2 — и всё. Ни о каком python 3 речь просто не идёт.

Если вы считаете, что это лучще, чем транспайлеры… ну это ваши проблемы.
Реально использую питон3. ЧЯДНТ? Правда, свежие версии андроида я не пишу, ну так им прекрасный мир программирования не ограничивается.
А вашими стартапами — ограничивается? Правда заключается в том, что переход от python2 к python3 — один из самых неудачных подходов к «версионности».

Не самый неудачный, впрочем. Попытка перехода от perl5 к perl6 или от php5 к php6 — ещё мрачнее (обе кончились тем, что никто никуда так и не перешёл — причём php6 в конечном итоге просто умер).

Причём очень может быть что python окажется там же, где perl: просто в конечном итоге, потеряв несколько лет, разморозят развитие 2й ветки и всё.

Я лично знаю достаточно много людей, которые просто отказались от использования python3. Уже одно то, что в нём нельзя безопасно получить список файлов в каталоге — много говорит о том, какую траву курили разработчики.
Справедливости ради PHP6 не релизился, поскольку сами разработчики признали неудачной попытку реализовать эту версию, вместо чего продолжили эволюцию ветки 5.x. Perl6 же вышел, когда интерес к Perl5 как таковому уже угас, а сам язык в современных представлениях сильно устарел и его нишу постепенно занимает Python2.
Проблема в обоих случаях была одна и та же: вот этот вот самый «подход к версионности» в стиле перехода с NCP на TCP. Это неплохо работает, когда у чего-то пользователей — сотни, хуже — если их тысячи и совершенно не работает если их миллионы. Только в случае с PHP и Perl'ом это привело к тому, что переход на несовместимые версии так и не состоялся, а в случае с Pyhton'ом — к появлению костылей типа того же six. Ну а большая эклектичность мира JavaScript обозначает автоматом, что костылей нужно больше, вот и всё.
UFO just landed and posted this here
Если ваша единстуенная цель — заработать, то вам биржевыми спекуляциями заниматься надо, а не программированием.

А вот если вы хотите что-то сделать, чем будут пользоваться через 10-20 лет, то лучше выбирать популярные технологии, а не эффективные. Ибо на долгих дистанциях наличие разработчиков — важнее эффективности.

Как оно в действительности писать на Javascript в 2016 году.


Хэй, мне нужно создать страницу, которая показывает последнюю активность пользователей, так что мне надо получать данные с REST-сервиса и отображать в некой сортируемой и фильтруемой таблице, и обновлять её, если что-нибудь поменялось на сервере. Я думаю использовать jQuery для получения и отображения данных.

— Конечно, ты можешь по прежнему использовать jQuery. Но если ты планируешь сделать что-нибудь более сложное на фронтенде ты, вероятно, должен попробовать React. Это даст большие преимущества в дальнейшем.


— Звучит круто. Как мне лучше начать разработку с React?


— Самый простой путь: запустить npm install create-react-app -g в своем терминале и можешь начинать проект сразу после этого.


— Круто, ты так говоришь, будто не нужно никаких дополнительных настроек?


— Нет.


— Мне нужно установить специальные IDE, такие как Visual Studio, Android Studio, или XCode?


— Нет, просто создай свое приложение командой create-react-app my-cool-app и ты готов к пути.


— А что насчет дополнительных зависимостей? Может мне нужно установить Java на мою машину? Может мне также нужны Maven, Gradle, CocoaPods, или может быть мне нужно скачать дополнительно 20-гигабайтный SDK?


— Нет, просто выполни cd в папку со своим проектом и запусти npm start. Это всё.


— Мне нужно собирать своё приложение и ждать долгой пересборки после каждого изменения?


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


— Звучит очень полезно! Я думаю так я смогу немного увеличить скорость процесса разработки. Но подожди, что делать, если мне когда-нибудь понадобится развернуть production версию моего сайта? Потому-что никто в действительности не развертывает неминифицированные версии index.html, app.css, main.js в production, правильно?


— Да, ты прав. Если тебе нужно развернуть production сборку своего сайта просто запусти npm run build и всё что тебе нужно бедут в папке /build. Миниицированное, оптимизированное и готовое к развертыванию.


— Спасибо приятель, очень полезно.


https://medium.com/@kitze/how-it-actually-feels-to-write-javascript-in-2016-46b5dda17bb5#.wvne8zb17

Всё хорошо. За исключением того, что это неправда в любом случае кроме вывода hello world.

create-react-app предоставляет необходимый минимум для работоспособного приложения. Этого минимума достаточно для решения текущей задачи пользователя — вывести фильтруемую и сортируемую таблицу. Остальное, например, роутинг (react-router), централизованное хранение данных (redux), библиотеку с набором готовых компонент интерфейса — подключается по мере развития приложения и/или роста знаний разработчика.


Это отличный стартовый шаблон для изучения React или начала разработки нового приложения.


Посмотрите https://github.com/facebookincubator/create-react-app


Также есть простой способ сделать из вашего приложения Progressive Web App, с возможностью установки в смартфон, для работы без подключения к интернету https://github.com/jeffposnick/create-react-pwa/compare/starting-point...pwa

Только при этом в простейшем виде нужно использовать компонент для таблицы вроде https://www.npmjs.com/package/react-sortable-table — это уже приводит к знанию jsx. А данные для таблицы надо откуда-то брать, для этого делать серверную часть с апи, для этого использовать что-нибудь вроде express плюс модуль для работы с СУБД, а данные нынче модно хранить в redis… В общем, даже такая простейшая задача превращается в какое-то исследование и больше всего напоминает мне работу с C++.
знанию jsx

Звучит примерно как «знанию TXT».

В Реакт приложении все самое сложно как раз и начинается после подключения redux. Код начинает обрастать reselect, recycle, reduxThunk и код постепенно превращается в набор черных ящиков, которые гоняют данные между собой и что-то с ними делают.
В первый раз за 10 лет чтения хабра пожалел, что не могу поставить плюс комментарию
Сам сегодня совершенно случайно обнаружил в webstorm замечательный вариант React Starter Kit при создании проекта, с отличной документацией и работой всего стека из коробки. Как для реальной разработки, пока оценить не могу, но для ознакомления — волшебно!
— Мне нужно установить специальные IDE, такие как Visual Studio, Android Studio, или XCode?

— Нет, просто создай свое приложение командой create-react-app my-cool-app и ты готов к пути.

— Что, даже текстовый редактор не потребуется?


— Нет, реакт настолько крутой, тебе вообще не придется писать код.

>Нет, реакт настолько крутой, тебе вообще не придется писать код.

Сбылась мечта программиста. (С)
;-)
да но зачем мне nodejs и npm если я хочу сделать только SPA приложение которое общается с бэкэндом который не на nodejs работает? Т.е. чисто фронтэнд. В том вопрос.

А зачем вам текстовый редактор, если вы делаете фотогалерею? Но, я думаю, без него вы мало что наверстаете.


Вот и с nodejs и npm так же — это инструменты разработки, которые делают разработку удобнее. Не надо относиться к nodejs как к серверу — на самом деле, это всего лишь консольная запускалка скриптов.

А чем в качестве «консольной запускалки скриптов» плоха (извините) консоль?

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

>Могу я узнать причину минуса?

Вряд ли. Минусы тут ставят от балды.
В качестве предположения: слово «консоль» используется зачастую и для обозначения интерпретатора командной строки, запущенного в консоли («набери в консоли, запусти в консоли» и т.д.). Просто в силу того, что масса приложений ныне — GUIевые, и консоль прочно ассоциируется с и.к.с.Тот же .bat файл, интерпретируемый инт. командной строки, это скрипт.

Я и сам слово "консоль" в этом смысле часто использую. Но даже в этом случае скрипт на js не может быть запущен "в консоли" напрямую, вот ведь в чем дело...

UFO just landed and posted this here

Оу, спасибо, теперь до меня дошло что имелось в виду...

Если вы про консоль браузера — то она является неплохим инструментом для отладки клиентских скриптов. Но js-скрипты не делятся на клиентские и серверные, есть еще одна категория скриптов — системные скрипты. (Прилагательное "системный" в данном случае означает, что ими пользуется не конечный пользователь, а разработчик)


А именно, есть такие скрипты как


browserify — обычному веб-разработчику этот скрипт и правда не интересен. Но разработчику библиотеки этот скрипт позволяет просто писать код, а не думать про правильные обертки для модуля в разных окружениях;


babel — компилятор js, позволяет использовать при разработке самые свежие фичи, не дожидаясь пока они дойдут до браузера;


webpack — умеет минифицировать и склеивать скрипты и таблицы стилей.


Это — исключительно полезные скрипты, которые стоит попробовать любому веб-разработчику. Они ничего не усложняют и не замедляют — напротив, после начального изучения они нехило упрощают веб-разработку и ускоряют работу веб-приложения (webpack, за счет минификации). И каждый из них для своей работы должен читать файлы с диска и записывать их на диск, чего нельзя добиться в консоли браузера. Поэтому для их запуска нужна nodejs

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

Извиняюсь за грубость, но вы чем читаете? Какая вообще разница, какой у вас есть бэкэнд, и есть ли он вообще?


nodejs — это не сервер.

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

Какой ад?


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


Во-вторых, клиентские фреймворки к nodejs не имеют ни малейшего отношения.

Во-вторых, клиентские фреймворки к nodejs не имеют ни малейшего отношения.


Тогда для чего мне nodejs если у меня клиент в виде SPA как я написал?
UFO just landed and posted this here
А для чего нужен gcc в с++ проектах? Для сборки. На node.js написан софт, который собирает ваш SPA, все, больше он не нужен. Если переписать эти сборщики с node.js на питон или даже на плюсы, для SPA ничего не поменяется.

Не надо выдавать бредни воображаемого "специалиста" за состояние технологии...


JQuery? Да, можно. Но ты еще не устал?

— Что случилось с HTML?
— Ничего не случилось. Но для динамической разметки нужен свой язык.
— Типа шаблонизатора?
— Да, JSX — это шаблонизатор.

— Другая библиотека? Что за Babel?
— Компилятор. Позволяет пользоваться новыми фичами языка раньше, чем их поддержка появится в браузере.

— Слушай, я просто хочу загрузить кучу данных с сервера, просто подключить JQuery из CDN и просто получить данные с помощью AJAX. Почему я не могу сделать это?
— Ты можешь так и сделать, но ведь потом эти данные надо еще вывести на страницу.

— Давай придерживаться React, я уже узнал слишком много о нем. Так что, если мне нужно использовать React, я вытяну его из этого NPM, а затем использую Browserify?
— Да.
— Это кажется слишком сложным, чтобы просто взять кучу зависимостей и связать их вместе.
— Не сложнее чем скачивать каждую библиотеку вручную.

Фрагмент про менеджеры задач не нужен — потому что они не нужны для этой задачи. Как и про TypeScript, функциональное программирование и прочее.

— О, да. Fetch это имя нативной реализации для выполнения XMLHttpRequests.
— О, AJAX.
— Ну да, Fetch это новая реализация AJAX. Помнишь, XMLHttpRequest был настолько неудобен, что все использовали только jquery-обертку вокруг него? Теперь обертка не нужна.

— А методы AJAX JQuery не возвращают промисы?
— Да, возвращают.

— Это третий раз, когда ты говоришь о await, но я понятия не имею, что это такое.
— Синтаксический сахар для промисов.
— У… а можно его не использовать?
— Можно. Наверное, так будет даже лучше первое время — потом будет понятно что за магия внутри происходит.

Ну вот. А у меня другой опыт и последние пару месяцев депрессия и аллергия на js buzzwords.
— Другая библиотека? Что за Babel?
— Компилятор. Позволяет пользоваться новыми фичами языка раньше, чем их поддержка появится в браузере.

Причем каждую «фичу» типа того же Реакта нужно скачивать отдельно.

— Слушай, я просто хочу загрузить кучу данных с сервера, просто подключить JQuery из CDN и просто получить данные с помощью AJAX. Почему я не могу сделать это?
— Ты можешь так и сделать, но ведь потом эти данные надо еще вывести на страницу.

Ну, прямо там взял и вывел данные, даже не выходя из метода.

— Ну да, Fetch это новая реализация AJAX. Помнишь, XMLHttpRequest был настолько неудобен, что все использовали только jquery-обертку вокруг него? Теперь обертка не нужна.

Кроме случаев, когда нужно обрабатывать progress event.

ЗЫ. Заметил, что чем больше денег приносит приложение, тем меньше парятся что у него внутри.

Причем каждую «фичу» типа того же Реакта нужно скачивать отдельно.

Реакт — это не фича, Реакт — это библиотека.


Кроме случаев, когда нужно обрабатывать progress event.

Ни разу не было такой задачи за два года веб-программирования...

Поэтому в кавычках. Я не про сам Реакт, а его плагин для Babel.

А у меня все время прогресс загрузки хотят видеть поэтому приходится или XHR «вручную» использовать или сторонние типа axios который еще и в промисы умеет.

Загрузки чего? Вы грузите пару мегабайт в ajax-запросе, да еще и "все время"?

UFO just landed and posted this here
UFO just landed and posted this here

Не учтено, что он тяжеловес (серверная сторона) тот ещё.

UFO just landed and posted this here
Чорт, я как раз перестал иметь дело с фронтендом 6 лет назад, а сейчас мне надо получить немного данных по rest'у и вывести их на страничку… И тут такой ужос!..
Хинт: jQuery все еще развивается, новые версии выходят и т.д… Вы можете сделать все в стиле 2010, и оно будет прекрасно работать во всех современных браузерах включая сафари.
Обычные пользователи вашей странички скорее всего не будут заглядывать в код и никогда не догадаются о том, что он не модный.
А весь этот выше перечисленный зоопарк можно оставить тем, кто ведет действительно крупные проекты или гонится за модой.
Согласен, это все нужно для одностраничных сайтов с динамическим всем-всем, а для простейших задач jQuery и ее армии плагинов за глаза хватает.
> а для простейших задач jQuery и ее армии плагинов за глаза хватает.

Простейшие задачи не в тренде. ;-)
Ну да.
В тренде решать не задачи (самым простым возможным способом), а надуманные проблемы, которые сами создали при решении задач. :)
>В тренде решать не задачи (самым простым возможным способом), а надуманные проблемы, которые сами создали при решении задач. :)

Верно. Это как первая модель авто типа «Форд-Т» — прост и понятен.

Сейчас же, чтобы поехать, надо аж столько в авто всего запихнуть — что страшно становится… разработчику авто, но не водителю этого современного авто, жмущему на кнопку! ;-)
Больше половины из указанного точно не понадобится.
Я наверное странный человек, но неужели не хватит стека:

js +jQuery +backbone/angular/ember/react (на выбор что-то одно)? + grunt (если надо сборку делать).
Для описанной задачи хватит даже более простого стека:
js + jQuery + DataTables (jQuery плагин) + grunt (если надо сборку делать).

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

Если вам этого хватает, то вы — откатываетесь назад стремительным домкратом. :-)

Чтобы оставаться только(!) на месте, вам надо… бежать. (Как говорил известный персонаж).
Прямо все, что я думаю о фронтенде. Начал использовать angular, а он уже устарел оказалось, а angular 2, это какой-то ад. Вернусь на jQuery, мне всего-то данные с rest отобразить в таблице.
Именно потому я использую VanillaJS и jQuery. Максимум, могу добавить шаблонизатор на стороне сервера (вроде liquid, erb).
И ни слова о том как это «многообразие» потом надо поддерживать. Как будто «написал и забыл» работает.
Так в этом и суть.
Все это потом будет оплачивать заказчик. :)
Труъ.
Недавно решил попробовать запилить проект, но на NodeJS+express+React. До этого NodeJS тыкал давным-давно, когда он еще только появился. Иии…
WebPack, Babel и прочие страшные слова вызвали легкое недоумение, но в принципе понятно, для чего это надо и зачем. В ES6 действительно куча классных фич, и оно стоит того.
Потом тыкался с express. Вроде бы это самый популярный и простой фреймворк на данный момент? Но черт побери, почему в 2016 году в самом популярном и простом фреймворке нужно вручную подключать такие функции, как парсинг форм и cookie? Я как-то привык, что подобные вещи есть «из коробки». Может это сделано ради скорости — чтобы использовать только то, что тебе нужно? Но для скорости я предпочел бы Go, чем Javascript. А в express вообще какой-то middleware hell получается, честное слово.
В итоге почти неделю я потратил только на то, чтобы разобраться во всем этом и реализовать регистрацию и вход пользователей на сайт, с подтверждением по емейлу. Посмотрел на все это дело… Плюнул, снес все нафиг и ввел что-то типа: rails new myapp -B && cd myapp && echo "gem 'devise'" >> Gemfile && bundle install && rails g devise User && rake db:setup. Всего несколько команд дали мне функционал, на который я убил кучу времени.
Да, у меня нет опыта в написании проектов на NodeJS, express и прочим. Профессионалы этого дела запросто заткнут меня за пояс, да и вообще презрительно прочитают этот комментарий и гневно уничтожат одной тирадой. Но лично для меня все эти штуки до сих пор сыроваты и сложны в использовании, тем более когда под рукой уже есть наработанный и вполне готовый функционал.
Но черт побери, почему в 2016 году в самом популярном и простом фреймворке нужно вручную подключать такие функции, как парсинг форм и cookie?

А что если вам не нужен парсинг форм? Что, если вы не используете печеньки?


rails new myapp -B && cd myapp && echo "gem 'devise'" >> Gemfile && bundle install && rails g devise User && rake db:setup.

Ок, вы подключили библиотеку devise и она сделала то, что вам нужно. Почему вы в таком случае не догадались использовать passport?

Догадался. Но если использовать только стратегию local, без OAuth и прочего, эта библиотека становится практически бесполезной. Все манипуляции с базой (поиск и добавление пользователей, проверка пароля и т. п.) производятся вручную. И получается, что все, что выполняет данная библиотека, это хранение данных в сессии.
По факту эта библиотека более-менее полезна тем, кто использует различные стратегии в ней (вход через соцсети). Для local-only толку от нее практически нет.
Поправьте, пожалуйста, если я не прав.

Расскажите, как оно учить С++ в 2016 году, чтобы писать программы конкурентоспособные на мировом рынке? Мне реально интересно узнать в практических целях.

UFO just landed and posted this here
Развитый язык подразумевает, что стек раз в 2 года не переписывают.
Установить IDE + компилятор, читать книги, пробовать примеры.

А дальше уже в зависимости от цели. Если гуи то можно в Qt погрузится. Если сервера то многообразие разных возможностей, начиная от голых сокетов, boost.asio, libev ну или еще чего-нибудь. И отдельно читать книги про многопоточность. Если игры… ну опять же можно хоть на opengl а можно взять популярный фреймворк ( тот же cocox2dx ).

зы. Читая книги, помните что те из них которые написаны до появления 11 стандарта не будут охватывать все то многообразие безумных возможностей которые у нас появились. Поэтому про них нужно будет читать отдельно.
Спасибо! Классная статья, которая отражает рельное положение дел в веб-разработке.
Куча библиотек, фреймворков и прочего соединённых костылями и дополнительными библиотеками. Всё это сдобрено всякими пакетными менеджерами и трансляторами.
С одной стороны хорошо, что есть выбор, с другой стороны появляется куча проблем:
— высокий порог входа в проект.
— то что ты выучил и использовал на одном проекте скорее всего не пригодится в другом. К тому же будет считаться устаревшим.

Можете считать меня отсталым, но меня связка ASP.Net MVC или WebAPI + JQuery + KnockoutJS вполне устраивает и пока менять не собираюсь. (Разве что может быть попробую ангуляр).

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

Мне кажется, что пока 80% браузеров не будут поддерживать TypeScript/ES2016 из коробки без необходимости перекомпиляции/преобразования — нет смысла использовать эти языки.

Мне кажется, что эта мешанина библиотек и фреймворков должна пройти лет через 5 и путём естественного отбора оставить только то, что действительно удобно (как тот же JQuery в своё время)

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


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

Мне кажется, что пока 80% браузеров не будут поддерживать TypeScript/ES2016 из коробки без необходимости перекомпиляции/преобразования — нет смысла использовать эти языки.

Почему вы смело используете C#, у которого довольно сложный процесс построения (build) — но отрицаете необходимость этапа построения для клиентских языков?

Потому что для того, чтобы собрать C# приложение мне не нужно устанавилвать и конфигурировать кучу инструментов. Всё происходит «само» по нажатию одной кнопки из среды разработки. А также потому, что в C# нет зоопарка стандартов и мне нет смысла писать на .Net 4.6, а потом конвертировать с помощью специальных инструментов в .Net 2.0, чтобы это заработало.

Как должно быть: поставил VS for JS, создал проект, пишешь на ES2016/TypeScript/что либо ещё. Нажал кнопку скомпилировать и оно открылось в браузере и заработало (хоть в IE10, хоть в хроме последнем).

Говорят, в ASP.NET Core так и сделано.

Я бы все-таки посоветовал обратить внимание на React, вместо Knockout. Ибо Knockout — довольно тормознутая штука (по крайней мере была, до введения deferred updates в 3.4.0).
Спасибо за совет. Я планирую перейти на реакт или ангуляр, но в первом меня отпугивает, что на каждый чих нужно ставить плагин, а второй — тем, что он всё же избыточен, т.к. заточен на SPA
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Во время прочтения вспомнился один «продажник» который в подобном изложении пытался объяснить заказчику (скорее запутать заказчика) почему он хочет много денег от него. Подобный текст можно написать о чём угодно, хоть о плюсах.

— Я хочу кодить игры на плюсах, и буду использовать <тут любой движок 90х годов>
— Ээ-э не чувак, давай я тебе сейчас расскажу как там всё развивалось и куда всё это привело…

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

Фронтенду явно не хватает некоторого универсального промежуточного представления, которое может целиком заменить js+html+css и которое будет достаточно стабильным и низкоуровневым чтобы во всех браузерах работать идентично.

UFO just landed and posted this here
UFO just landed and posted this here
Похоже теперь я осознал, почему Enterprise часто выбирают Sencha (ExtJS) и готовы за него платить $10К. -)
Для серьезных учетных систем и всяких RIA аналогов нет по-сути.

Сейчас пишу довольно крупный проект на нем, ни каких зоопарков, все из коробки. И сборщик тоже SenchaCmd.
Документация там просто шикарная.Вот реально сидишь и пишешь код, ни каких головняков не возникает. Это реально очень приятно, после всех зоопарков с разными либами и всяких тулз на Node.

Причем старые версии, 3я, 4я, были довольно багованными и тормозили прилично, текущая 6.2.0 просто песня.
Извините, не могли бы вы описать основные преимущества ExtJS, которые вас привлекли, за исключением уже описанного? Мне, как начинающему front-end разработчику, будет очень интересно почитать ваше мнение, как человека, который использовал ExtJS в своих текущих проектах.
Не менее интересно будет почитать, что же вы осознали, в плане «почему Enterprise часто выбирают Sencha (ExtJS)», более конкретно.
В этом и есть преимущество, что там все из коробки, и работа с данными и компоненты все и скины и графики, в 6.2.0 еще и адаптер для d3.js появился. Это не только фреймворк, но и большая экосистема. Сборщик, визуальный редактор, тестовое окружение, дебаг тулза и т.д. + к этому саппорт который оперативно чинит баги в фреймворке (если вы купили Premium есть доступ к night builds).
Стоит да, 10К долларов, но на большом проекте это сэкономит много человеко-часов времени разработчикам, поэтому это окупается. Ну и да, это актуально для долгоиграющих enterprise систем. Для каких-то стартапов или небольшой админки конечно он не нужен, как из пушки по воробьям и может не окупить себя просто.
Там немало вещей, за которые его можно любить. Это и богатая библиотека компонентов, и шикарный набор классов для работы с данными. Сам фреймворк написан в едином стиле, плюс он подталкивает к определённой структуре проекта, которую легко сопровождать и понимать другим программистам.
В Ext JS отлично реализованы те функции, которые очень часто требуются в enterprise. Если ещё не видели их демку, то вот она Ext JS Kitchen Sink.
… плюс он подталкивает к определённой структуре проекта...

Вообще-то фреймворк на то и фреймворк, чтобы проекты под него имели определённую структуру. Если этой структуры нету, то это не фреймворк, а библиотека.

Хм, никогда не придавал значения этим терминам, а сейчас погуглил и обнаружил, насколько забавно отличаются русская и английская Wiki по этому поводу :)
In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.

При этом, в тексте статьи нет ни одного слова «структура». Зато чуть ниже есть «архитектура».

Фре́ймворк (иногда фреймво́рк; англицизм, неологизм от framework — каркас, структура) — программная платформа, определяющая структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта.

А здесь сразу о структуре.

Теперь впору поговорить о разнице между структурой и архитектурой, но я, пожалуй воздержусь :))
UFO just landed and posted this here
Весьма символичное название статьи в преддверии 2017
Интересно, про другие языки или направления можно такое написать?
>Интересно, про другие языки или направления можно такое написать?

Про другие такого не замечено.

Например Java.

Java — это Cobol сегодня. — Новые версии переносятся непрерывно (Java 9 недавно передвинули на пол-года).

Java 2 EE похоже вообще уже «труп».
Такой хаос мало где есть… Разве что для Go можно нечто подобное написать, но JS по уровню энтропии явный лидер.
Напишите статью про Go. Будет интересно всем почитать.

Мне кажется была уже эта статья… А может я и ошибаюсь.

Это тоже перевод, написаный другим автором, в другое время. Похоже что автор оригинала данной статьи решил его дополнить.
Чем выше порог входа, тем выше заработные платы. Всё идёт по плану (по плану порабощения мира). Ну а если серьёзно, то как ещё можно писать на современной версии языка, так чтобы он отрабатывал везде? Я думаю, что этот эволюционный период пройдёт и всё будет хорошо.
> Я думаю, что этот эволюционный период пройдёт и всё будет хорошо.

Странно то, что этот СКАЧОК эволюции JS вообще возник, после 10-ти то лет «плавного обычного развития».

Ничего странного. СКАЧОК начался когда появился движок V8, ускоривший выполнение js в разы.

>СКАЧОК начался когда появился движок V8, ускоривший выполнение js в разы.

Хорошо. Тогда вопрос будет звучать так: Странно что движок V8 ускорил выполнение js в разы, а не на 5-10%, как это обычно происходит с НОВЫМ движком на рынке.

А что странного в скачке производительности при переходе от интерпретации к компиляции?

>А что странного в скачке производительности при переходе от интерпретации к компиляции?

Всё верно. В 2008-2009 году в JS движках произошло резкое увеличение (в разы, а не на %) производительности и JS… взлетел. ;-)

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

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

PS: Я понимаю, что простая манипуляция с DOM это еще не JS программирование!
UFO just landed and posted this here
Пишу на чистом JS, абсолютно никаких библиотек. Чувствую себя хорошо, все в порядке. И нет, я не из адептов pure JS, просто мои приоритеты в разработке — скорость работы, и никакая связка из 3 библиотек не будет работать быстрее чистого языка.
Описывает муки моего выбора на этой неделе. Вернулся к JavaScript спустя год для написания небольшой web-службы отображения данных из БД. Также рассуждал и в конце остановился на JQuery, Backbone, Marionette, lodash + coffee скрипты + бекэнд на Python.
Слишком быстро скачет JavaScript.
— Я бы сделал транспайл из TypeScript с помощью комбо Webpack + SystemJS + Babel.

Чем лучше SystemJS в сравнении с вебпаковским require.ensure?
Мне одному кажется, что такая статья уже была тут примерно 5 раз?
Была, тоже перевод, похожаяя статья. Похоже автор оригинала её «доработал»
https://habrahabr.ru/post/308148/

Трудно найти более дебильный ЯП нежели чем JS, но гуглофейсбуку этого показалось мало — они дополнили его перечисленными автором хакерскими примочками. Да ещё и TypeScript изобрели, который не имеет даже банальных мапов, зато требует ещё больше примочек. Казалось бы — пиши себе на НОРМАЛЬНОМ языке с адекватными инструментами (ClojureScript, Elm, F#, PureScript ), используй js/css/html в качестве целевой платформы покуда не придумали что-то лучше. Но не тут то было:


image


Палка в заднице у левого зайца как-бы символизирует webpack

>Трудно найти более дебильный ЯП нежели чем JS, но гуглофейсбуку этого показалось мало — они дополнили его перечисленными автором хакерскими примочками. Да ещё и TypeScript изобрели, который не имеет даже банальных мапов, зато требует ещё больше примочек.

TypeScript изобрёл Microsoft. — Так что надо писать вам НЕ «гуглофейсбуку этого показалось мало», а «гугло-фейсбук-майкрософту этого показалось мало».

Да, эта троица («гугло-фейсбук-майкрософт») вообще ЗАХВАТИЛА МИР! Похоже на то. ;-)

>Трудно найти более дебильный ЯП нежели чем JS

Почему же он дибильный?
Потому что на нём можно писать по разному — и «дебильный» и «дибильный» и он будет работать. ;-)
Или не будет. Или будет, но не так как надо и не долго. Билды ломаются — рандомно. И рандомно же чинятся со второго-третьего-четвертого запуска npm install и npm dedupe.
Так это ж норм.
Именно это — причина его успеха.
Таких языков куча.
С — тоже дибильный?
При желании можно сделать, чтобы работало только в одном случае, ну или управлять типизацией явно, проверяя переменные.
А переменные и функции в JS регистрозависимые.
Слабая типизация + полиморфизм операторов — довольно взрывоопасная смесь, которая мало кому нравится.
Вообще-то много кому :)
>Вообще-то много кому :)

Всем рисковым чувакам! ;-)
В вебе большинство таких :)
Большинство может вообще один/два языка только знать… А вопрос нравится/не нравится — это вопрос осознанного выбора. Попрограммируйте несколько лет на слаботипизированном языке, а потом несколько лет на сильнотизированном.
Я не видел пока ни одного человека, который после этого тяготел бы к слабой типизации.
>Я не видел пока ни одного человека, который после этого тяготел бы к слабой типизации.

Я есть он. (С)

Я удрал из мира Java в мир JavaScript. Удрал через GWT. Но удрал.

Мир JavaScript — это мир свободы! (С)
К Вам тогда вопрос такой, Вы пробовали языки с сильной динамической типизацией?
> пробовали языки с сильной динамической типизацией?

Странный вопрос у вас.

«Сильная / слабая типизация (также иногда говорят строгая / нестрогая). Сильная типизация выделяется тем, что язык не позволяет смешивать в выражениях различные типы и не выполняет автоматические неявные преобразования, например нельзя вычесть из строки множество. Языки со слабой типизацией выполняют множество неявных преобразований автоматически, даже если может произойти потеря точности или преобразование неоднозначно.

Примеры:
Сильная: Java, Python, Haskell, Lisp;
Слабая: C, JavaScript, Visual Basic, PHP.»

Сильная: Java!!!
А что странного? Это же отдельный вопрос. А типизация помимо деления на сильную/слабую делится ещё и на динамическую/статическую.
У JavaScript — слабая динамическая, у Java — сильная статическая. Отсюда и вопрос про другие языки.
Статическая / динамическая типизация.

Статическая: C, Java, C#;
Динамическая: Python, JavaScript, Ruby.

Сильная / слабая типизация

Сильная: Java, Python, Haskell, Lisp;
Слабая: C, JavaScript, Visual Basic, PHP.

То есть, программировал ли я на Python?

Ответ — нет.

То есть, программировал ли я на Python?
Ну необязательно именно Python, кроме него есть ещё Ruby, Lua, Smalltalk, Lisp, Erlang и ещё масса языков с сильной динамической типизацией. Пока непонятно какие языки кроме Java и JavaScript Вам знакомы?
Весьма вероятно, что Ваш восторг от смены Java на JavaScript связан с переходом от статической типизации без вывода типов к динамической типизации, а не со слабостью типизации.
>Ну необязательно именно Python, кроме него есть ещё Ruby, Lua, Smalltalk, Lisp, Erlang и ещё масса языков с сильной динамической типизацией. Пока непонятно какие языки кроме Java и JavaScript Вам знакомы?

Все языки начиная от «программировать в кодах» до времени появления Java. Исключая выше вами перечисленные.

Java в СВОЁ время произвёл восторг! Но его время ушло. Имхо.
Все языки начиная от «программировать в кодах» до времени появления Java. Исключая выше вами перечисленные.
Смешно )))
Ладно, — Все ШИРОКО ИЗВЕСТНЫЕ языки начиная от «программировать в кодах» до времени появления Java. Исключая выше вами перечисленные и «нишевые» (но включая ADA).

Проще было бы перечислить… Впрочем, ладно, понятно, что с сильной динамической типизацией Вы не сталкивались.
>Впрочем, ладно, понятно, что с сильной динамической типизацией Вы не сталкивались.

Вместе нет похоже. Только по раздельности:
Сильная: Java
Динамическая: JavaScript

Вот с этой парочкой в последнее время и живу. ;-)
Потому что https://www.reddit.com/r/programming/comments/4eh9qc/why_javascript_development_is_crazy/
Вкратце: примитивный язык, примитивный тулинг, примитивная рефлексия, смехотворно крошечная стандартная библиотека, поле невидимых граблей, хаков и шамантва и так далее. Унылый ЯП, который распространился благодаря монопольному положению в веб-стеке, реактивно набирающем популярность.
>Унылый ЯП, который распространился благодаря монопольному положению в веб-стеке,

СТОП. Веб-броузеры НЕ монопольны. Есть минимум НЕСКОЛЬКО разных ХОЗЯЕВ:
IE, FF, Хром, Опера.

Никто им НЕ мешает и никогда НЕ мешал ставить какие-угодно плагины(или встраивать прямо в броузер) для интерпретации (или компиляции на лету ) для каких угодно языков.

И эти языки были — Java (апплеты — удалены из-за постоянных дыр), Флеш (отказываются из-за прожорливости).

Так что дело именно в «примитивной» ПРОСТОТЕ JS, разогнавшегося в броузерах благодаря успехам в деле его изощрённой компиляции на лету.

Так что «МОНОПОЛИЯ» тут произошла путём КОНКУРЕНЦИИ, а не чей-то «сильной руки».

Да и попытки «сбросить» JS с пьедестала осуществляются постоянно. ;-)
ой, не смешите мои тапки. Плагины для браузеров писать — да в рот им ноги! «конкуренция» — что за блаженные глупости, где вы видели конкуренцию? :-) При малейшей возможности с js бы сбежали все, кроме геев и даунов, неспособных изучить второй ЯП из за умственной ограниченности. Хоть в джаву или С#.
>ой, не смешите мои тапки.

Не буду.

>Плагины для браузеров писать — да в рот им ноги!

Не поверите, но писали. Всякий НОВЫЙ язык пытался либо напрямую (как Java — прямо в поставке броузера пролезть) либо через плагин — но со временем все отваливались. По разным типа причинам, но отваливались. — Остался ОДИН — JavaScript — он и ОДЕРЖАЛ ПОБЕДУ! :-)

>«конкуренция» — что за блаженные глупости, где вы видели конкуренцию? :-)

В IT-мире она всюду. Стартап за стартапом так и валит так и валит. ;-)

>При малейшей возможности с js бы сбежали все, кроме геев и даунов, неспособных изучить второй ЯП из за умственной ограниченности. Хоть в джаву или С#.

Я удрал из мира Java в мир JavaScript.

Java — это Cobol сегодня (С)

Java — это перманентное отставание и перманентный перенос строков выхода новой версии (и новых фич).

А JavaEE — вообще при смерти.

Короче — Java — это болото. Это скучно. Это нетрендово. Это печально.

Я удрал из мира Java в мир JavaScript. Удрал через GWT. Но удрал.

Мир JavaScript — это мир свободы! (С)

;-)
Я удрал из мира Java в мир JavaScript.
А почему не в .NET?
>А почему не в .NET?

Когда я пришёл в мир Java — C# ещё не было и в помине. ;-)
Я не про «пришёл» спросил, а про «удрал»… Судя по упоминанию GWT касательно того периода, C# уже был и давно.
Хм, так C# — это же «сахарная Java» — Чего туда беч то?
Ну, когда Вы пишете про перманентное отставание Java, возникает вопрос отставание от кого… и ответ тут один — от C#. Потому что остальных сравнивать с Java тупо некорректно.

> Мир JavaScript — это мир свободы!

Это из серии «анархия — мать порядка» )))
Т.е. в теории вроде могло бы работать, а на практике люди не так уж способны к самоорганизации.
>Ну, когда Вы пишете про перманентное отставание Java, возникает вопрос отставание от кого… и ответ тут один — от C#. Потому что остальных сравнивать с Java тупо некорректно.

Почему. Например функциональщина наступает во ВСЕ языки по ВСЕМ фронтам.
Теперь вопрос — когда Лямбда-выражения в Java? — Ответ — в Java 8

> Это из серии «анархия — мать порядка» )))

Это из серии — НЕТ ДИКТАТУРЕ! ;-)
Например функциональщина наступает во ВСЕ языки по ВСЕМ фронтам.
И что? По такому критерию любой императивный язык будет в вечных догоняющих, в том числе и C#(несмотря на то, что лямбды там лет 9 назад появились).
С какими ещё языками по-вашему уместно сравнивать Java и по каким критериям?
>С какими ещё языками по-вашему уместно сравнивать Java и по каким критериям?

По критерием ОБНОВЛЕНИЯ и ВНЕДРЕНИЯ новых фич, появление НОВЫХ фреймворков. — Гула! ;-)

Java в этом отношенни к JavaScript как… прыгающая лягушка к летающему стрижу. ;-)
По критерием ОБНОВЛЕНИЯ и ВНЕДРЕНИЯ новых фич, появление НОВЫХ фреймворков.
Фичи языка активно появляются на этапе стабилизации языка. А новые фреймворки — на этапе стабилизации экосистемы. В данном отношении, JavaScript можно охарактеризовать как пока ещё незрелый и нестабильный ЯП. Да, он существует очень давно, но по сути начиная с 2009 года пилят новую версию языка, которая до сих пор не устаканилась.
Сложно это записывать в плюс. Конечно, язык не должен скатываться в стагнацию аля Java, но очень бурное развитие адекватнее смотрится до версии 1.0. Самое фиговое, что, несмотря на новые версии ECMAScript, избавляться от bad parts никто не торопится.

image
>В данном отношении, JavaScript можно охарактеризовать как пока ещё незрелый и нестабильный ЯП.

Хм. Это язык 1995 года — ему 20 лет!

>но по сути начиная с 2009 года пилят новую версию языка, которая до сих пор не устаканилась.

Ну, до этого было аж 5 версий (4-я с полноценным ООП — НЕ покатила и была отвергнута).

>Самое фиговое, что, несмотря на новые версии ECMAScript, избавляться от bad parts никто не торопится.

bad parts — это фичи языка. Имхо. ;-)
Хм. Это язык 1995 года — ему 20 лет!
Я же пояснил… Тот язык, который развивался с 1995 года, навсегда остался в версиях 1.x, хотели сделать 2.0, но не договорились.
У ECMAScript своя нумерация версий, и это совсем не тоже самое, что версия JavaScript. Касаемо самого JavaScript, сейчас активно пилят версию 3.0, которая находится на уровне альфа-версий, и на каждую альфа-версию выпускают новую редакцию ECMAScript. Стабильная версия (1.8.x) тоже есть, но она не развивается уже лет 6 и ей никто не пользуется :-)
Место «ECMAScript 2015» в вашей системе версий?
Да, я ж написал «У ECMAScript своя нумерация версий», «на каждую альфа-версию выпускают новую редакцию ECMAScript».
ECMAScript в моём восприятии это документ, описывающий стандарт. Разве нет? Т.е. примерно такая фраза «JavaScript 3.0 удовлетворяет стандарту ECMAScript 2020» будет корректна по смыслу.
В любом случае, ECMAScript и JavaScript — это не одно и то же :-)
>В любом случае, ECMAScript и JavaScript — это не одно и то же :-)

Это то ясно, но обычно в реальном мире считают версии Javascript так:
Редакция 3
Редакция 4 (отброшена)
Редакция 5 (текущая для всех)
Редакция 6 (продвинутая)
Редакция 7 (вот вот будет принята).

Слово редакция обычно — отбрасывают.

Вообще нумерация версий что Javascript что Java — это смехотрон. Имхо. ;-)
Это то ясно, но обычно в реальном мире считают версии Javascript так
Но это ж не версии JavaScript, а редакции ECMA. Всё-таки не надо путать, у JavaScript есть свои собственные версии… Даже тут статейка была про текущую стабильную: JavaScript 1.8

А Java, да, забавна… она нумеруется в стиле Emacs (с отбрасыванием мажорной версии). Т.е. Java 8 значит Java 1.8
Чем проще язык, тем лучше.
Я манал в рот хитроумные загогулины.
Да и не настолько он примитивный, это примитивный взгляд. :)

ПО ссылке какая-то ерунда, не относящаяся к языку: DOM, jquery, html, Windows. Ну и оно на бусурманском. :)

Стандартная библиотека унылая из-за того, что он использовался только в браузерах. :)
Грабли, хаки, шаманство — это проблемы DOMа в IE как правило. :)
== Чем проще язык, тем лучше.

брэйнфаке и асм ещё проще

==. Да и не настолько он примитивный, это примитивный взгляд. :)

дв вы шо?? и что же там есть не примитивного? кроме хитрых граблей конечно

== ПО ссылке какая-то ерунда, не относящаяся к языку: DOM, jquery, html, Windows. Ну и оно на бусурманском. :)

это называется не читал но осуждаю :-)

== Стандартная библиотека унылая из-за того, что он использовался только в браузерах. :)

никакой логической связи

== Грабли, хаки, шаманство — это проблемы DOMа в IE как правило. :)

а new / this в js — это что?

>брэйнфаке и асм ещё проще

Зачем всегда вдаваться в крайности?
Так ли прост asm? Ага, щас.

>это называется не читал но осуждаю :-)

Всю ту ерунду не читал, пробежал по диагонали.

>а new / this в js — это что?

А что с ними не так? Это прям такая распространенная проблема? :)
Так ли прост asm? Ага, щас.

Так. Не надо путать «просто» и «легко».
> Так ли прост asm?

Разве нет?

Архитектура процессора — отдельная история.
Этому диалогу просто необходим сопутствующий пошаговый лог создания Hello world странички.
Не понимаю, в чем сложность проблемы, описываемой в статье. Взять первый попавшийся webpack boilerplate,
использовать первую попавшуюся библиотеку для отображения данных, хоть es6 template strings, и подключить для старых браузеров whatwg-fetch. Все.
актор, отвечающий на вопросы, это стопроцентный хипстер: все новое, фу это уже не можно.

Пишу на первом ангуляре + browserify и както вообще нет ощущения что это провал
А без разницы на чём писать Хелуволд. Но на чистом js проще чем на Ангуляре. React бесит навязыванием хакерских примочек, но сам по себе он не плох. А Ангуляр — это наихудший факиншэт из всех альтернатив.
Интересно, а чем этот вариант худший?
Впечатление, что дизайнили какие-то шизофреники — плотность дебильных eDSL, замаскированных хаков и неочевидного на квадратный сантиметр зашкаливает. Ну и пропертибиндинг — это в корне ущербная парадигма. Как и мутабельный VDOM.

(function () {
    angular
    .module('app.widgets')
    .directive('iconButton', iconButton);

    function iconButton() {
        return {
            restrict: 'E',
            templateUrl: 'app/widgets/buttons/icon-button.html',
            scope: {
                click: '&',
                icon: '@'
            },
            replace: true
        };
    }
})();


Особенно мне нравится часть про «click: '&', icon: '@'».

Для сравнения тоже самое на React+Typescript:

export function iconButton(icon: string, onClick: () => void) {
  return dom.div({ className: $"bo-icon-button fa fa-{icon}", onClick });
}



Особенно мне нравится часть про «click: '&', icon: '@'».

тут согласен, дикая штука.

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

Мне нравится в ангуляре то что оно более менее законченное решение из коробки: это именно фреймворк а не библиотечка, а-ля react. Чтобы реакт начал быть похож более менее на фреймворк то туда нужно воткнуть flux или redux, а еще немного плясок с бубном и оно должно будет заработать.

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

В общем я скорее склонен думать что это в большей степени разные технологии и сравнивать их лоб в лоб это скорее не правильно чем обратное и возглас «ангуляр хуже чем реакт» у меня вызывает легкое недоумение.
Решение из коробки в js в принципе нет, Реакт в этом ничуть не хуже Ангуляра. Если надо — берите Elm.

проблемное место Ангуляра — это любая чуть более чем тривиальная директива на нём. Это становится очевидно, если сравнить идентичный (именно идентичный, а не аналогичный) по функциональности код на Ангуляре и Реакте.

Чтобы реакт начал быть похож более менее на фреймворк то туда нужно воткнуть flux или redux


да ни фига.
В Реакте неизменяемый стэйт, что важно для многопоточных приложений.
Чтобы нормально писать jsx, достаточно знать html, а в Ангуляре надо учить очередной шаблонный движок и гей-синтаксис его шизофреничных директив + html. Все шаблонные движки сами по себе следствие ущербности языка. Собственно то, что есть jsx, в нормальных ЯП реализована на уровне языка в виде списковых включений.

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

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

И много багов вы лично нашли и устранили в jQuery?

Как-то приходилось иметь дело с реактом. А там на слуху библиотечка redux, о которой везде пишут, доклады на конференциях делают, пропагандируют, вплоть до того что без нее реакт не реакт, 20k звездочек на github и все такое. Ее автор, Ден Абрамов, важный человек на front end конференциях, ездит по миру, выступает, блог о библиотеке ведет. Я себе думаю, видать нереально крутая библиотека раз такой хайп. Потом посмотрел исходники, а там… примерно 200 строк кода, финиш.
Там комментариев и документации больше чем кода. Убрать все лишнее и будет 200 строк.

Я не о том полезный код или нет. Я о том, что в джаваскрипт мире хайп делают из ничего, из того что можно свелосипедить за пол дня и забыть, вместо того чтобы тащить 101-ую зависимость в проект со всеми вытекающими, читать мануалы по ней, разбираться почему не работает, дебажить, и т.д…
Некоторые вещи концептуальны) Это как доказательство в математике :-D — его полезность измеряется не объемом, а тем, насколько полезные результаты дает применение результата и насколько долго не могли получить это доказательство. Redux — это концептуальная штука, как раз. Фреймворк, навязывающий некоторые стиль написания кода. Я не буду сейчас утверждать, что это ограничение спасет вас от всех проблем — но, anyway — не стоит недооценивать его значимость)
Он не только библиотечку написал, он в принципе топит за функциональный подход в разработке, написал кучу полезных штук кроме самого redux для этого, постоянно везде помогает и советует.
Аксиомы поля вещественных чисел вообще в 10 строчек помещаются.

Чем меньше кода в полезной полной сущности — тем лучше.
Redux это больше паттерн управления состоянием приложения (что-то вроде улучшения flux). И этот паттерн успешно применяется и без самой библиотеки и даже на других языках (re-frame для reagent — реализация Redux для ClojureScript).

Собственно, сама библиотека не ограничивается redux, для использования редакса с реактом нужно еще react-redux.

Ооочень эпичный текст. Спасибо за перевод, было интересно почитать)

Теперь понятно, почему у меня, на неслабом компьютере на котором летает новый DOOM, часто виснут сайты с джава-скриптами :(

Не по-этому. Сайты с js виснут потому что:


  • забыли поймать и обработать исключительную ситуацию;
  • подключили сразу две версии jquery (что привело к исключительной ситуцаии, которую никто не поймал и не обработал);
  • показан баннер на Flash;
  • показан анимированный баннер на HTML5, который подключил свой jquery (см. выше);
  • нестабильная связь с сервером (что привело к исключительной ситуации, которую никто не поймал и не обработал);
  • jquery-программист не умеет отменять таймеры.

Все эти ситуации я сам наблюдал на чужих сайтах (включая мой интернет-банк!). А вот чтобы сайт тормозил просто из-за обилия скриптов на современном компьютере — я не видел (хотя на старом железе — наблюдал не раз).

Не знаю, но когда открываешь какой-нибудь сайт нередко сразу начинается загрузка процессоров на 25%, и эта загрузка длится и длится, порой свыше получаса. И это ещё ДО того как окончательно завис сайт.
>показан баннер на Flash;

как он прорвался то этот баннер на Flash? В каком броузере такая оплошность ЕЩЁ допускается то?
UFO just landed and posted this here
Кто-то непременно должен поставить эту пьесу в театре :)
UFO just landed and posted this here
> Bower же — тоже для npm (никогда не понимал, зачем менеджеру пакетов нужен менеджер пакетов)

Пакеты разные.
UFO just landed and posted this here
Вот, с пылу с жару еще: http://yehudakatz.com/2016/10/11/im-excited-to-work-on-yarn-the-new-js-package-manager-2/

>Что там такое есть, чего нет в npm?

Уже отличий нет. Прогресс. ;-)
Bower и npm — это два разных подхода. Если второй тащит за собой кучу своего барахла и зависимостей и вообще является эдакой стартовой точкой для формирования проекта, со всеми инструментами, то первый позволяет просто закачать необходимые пакеты и потом использовать их там, где это нужно, при этом набор пакетов во втором больше заточен на фронтенд.

Другими словами, npm лучше подходит для бекенда, Bower — для фронтенда. А так да, если не обращать внимание на эту мелочь и на то, что по набору пакетов они не тождественны, в целом это одно и то же.
UFO just landed and posted this here
Забудьте оба. Вы же в мире JS, тут всё меняется, тут никто не стоит на месте. Все бегут. ;-)

Встречайте НОВУЮ звезду — НОВЫЙ пакетный менеджер: Yarn

https://code.facebook.com/posts/1840075619545360

«A new package manager for JavaScript»

UFO just landed and posted this here
UFO just landed and posted this here
>Скорее тут нужно бежать, чтобы стоять на месте.

Нет. — Тут многие остановились.

Смотрите сколько минусов я получил за то, что высказался как вы:
https://habrahabr.ru/post/312022/?reply_to=9855604#comment_9847766

Так что многие тут отстали. (С)
Проще будет ответить ссылкой. Если совсем просто, то я не имел ввиду, что Bower нужно или можно использовать отдельно от npm, имелось ввиду, что его нужно (и можно) использовать чисто для фронтенда.
А я только в этом году начал использовать SVG и работаю с jQuery…
Я видимо уже совсем безнадёжен =( Не успеваю следить за всем… Даже html5 боюсь в проектах использовать…
>Я видимо уже совсем безнадёжен

Да, отставание лет на 7 у вас. ;-)
Я что-то не понял, а что это за наезд на python в конце? Ну да, у нас в сообществе идет вялотекущий переход с версии 2 на 3. Но возникающие проблемы не идут ни в какое сравнение с бардаком творящимся на фронтенде.

И сколько бы фронтендщики ни пытались залезть на бек со своим Node.js, идите вжопу! Я скорее потрачу дополнительное время, добавив в проект поддержку обеих версий питона, чем соглашусь кодить на JS до конца жизни!
>Я скорее потрачу дополнительное время, добавив в проект поддержку обеих версий питона, чем соглашусь кодить на JS до конца жизни!

Да, ладно. Вскорости все везде будут писать на JS. ;-)

Остальные? — Остальные уйдут в свои ниши. Если… найдут их. ;-)
Никогда все везде не будут писать на JS) Вскорости его попытка вылезти на бекенд обломится и он вернется на фронтенд, где ему и место.
Да, захватил плацдарм и готов к расширению. ;-)
Я очень надеюсь, что когда-нибудь какой-нибудь транспайлер из списка https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS допилят, и, наконец-то, можно будет без респиратора открывать фронтовой код. Хотелось бы, конечно, чтобы победил http://luvv.ie/

:)
Лучше уж WebAssembly. Зачем оставлять лишнюю JS-прослойку?
В данном случае автор постарался художественно связно перечислить все современные наработки в мире JS. Но на самом деле не все так плохо. Имея в вебе опыта чуть более чем ноль, и полгода работая над своим проектом, освоил такую связку: Webpack + Vue.js для фронтенда, nodejs для бэкенда (чтобы не учить другой язык). Сервер сам собирает и отдает клиента. Дальше промисов в сторону (async/await) не пошел (хотя ознакомился и даже написал пару модулей). Мне не очень нравится, когда пихают в язык новые ключевые слова. По этой же причине до сих пор работаю с require() — очень уж пришелся по душе тот факт, что такую модульную систему можно реализовать средствами самого языка 5 версии. Но если честно, перейти на async/await и прочие прелести не проблема, т.к. под капотом Vue.js на стороне сервера все равно работает Babel.
Так что не стоит драматизировать.
>Мне не очень нравится, когда пихают в язык новые ключевые слова.

Вы уже, в самом начале, вступили на дорогу отстающего.
Помню время, когда плагины к jQuery хостились на plugins.jquery.com, и в один прекрасный день кто-то из разработчиков безвозвратно дропнул базу, романтика была, не то, что сейчас.
UFO just landed and posted this here
А что за история такая? Там сейчас вроде как есть некая «база» уже добавленных когда-либо плагинов.
https://www.opennet.ru/opennews/art.shtml?num=32519
Ну так в итоге сайт сделали и он и сейчас работает, в чем проблема?
Та нет проблемы, просто сам факт удаления базы веселит, сейчас npm если дропнуть, половина разработчиков поседеет.
Понятно. Просто выше вы пишете так, как будто они там больше не хостятся.
UFO just landed and posted this here

Вы это к чему сейчас написали?

Говоря про SystemJS, забыли упомянуть про JSPM, без которого этот самый SystemJS не настолько уж и удобен :)

Вот за это я и люблю, и ненавижу JS.
+ почему никому не нравится синтаксис coffeescript?

Потому что не нравится)
На самом деле потому, что coffee не делает ничего нового, он просто даёт синтаксис, ничего более.

А всё правда так плохо или есть какой-то способ «просто вытащить данные из базы в таблицу» используя js?
*пробовал ангуляр, но так и не понял, как к нему прирастить получение данных снаружи
Откуда взялась база и что вы с ней хотите делать? Обычно JavaScrpt-программа живёт в браузере и, уж конечно, ей просто не дадут так просто пойти в базу без авторизации и прочего.

Так что уточните вопрос, пожалуйста: в какой среде вы работаете?
UFO just landed and posted this here
Sign up to leave a comment.

Articles