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

Что происходит в JavaScript тусовке

А происходит много чего. На сегодня это самая популярная тусовка (ака коммьюнити) для программистов. Последний раз я видел такoe же движeние в мире Java лет 15 назад. В то время на JavaScript крутые джависты смотрели свысока. Считалось, что JavaScript полезен только чтобы подсветить менюшки и добавить идущие часы на веб-страничку. На мобильниках было по три буквы на каждой кнопке, и ни про какие апсторы речь не шла. Java тогда еще обещала «Write once run anywhere», а реально воплотил это обещание JavaScript.

Допустим, вы программируете на языке Х и за последние 15 лет написали кучу приложений. В течение этого времени выходили новые версии движков для Х, менялись операционные системы и железо. И вы такой решили взять вашу прогу, написанную, когда гривна была еще по пять, и запустить ее на новеником айфоне 6S. Или даже 6S плюс. Вуаля! Она работает без малейших изменений в коде! Я не знаю про язык Х, однако программы, написанные на JavaScript 15 лет назад, работают на айфонах.

При всем при этом, писать на JavaScript было всегда неудобно, и народ всё разрабатывал фреймворки. Десять лет назад их было более сотни. Проблема выбора стояла похлеще, чем в американском супермаркете. AJAX был в фаворе. И хотя для разных браузеров код слегка отличался, фреймворки сглаживали различия. Стандартом ECMAScript (JavaScript — это его имплементация) никто не занимался. HTML5 был еще в утробе. В общем, было как-то неуютно.

Эволюция технологии

В 2016 году картина существенно изменилась.

— Стандарт ECMAScript (ES) активно развивается и перешел на ежегодные релизы. В прошлом году вышел ES6 (aka ES2015), a в этом году выйдет ES7 (ES2016). Теперь в языке есть классы, лямбды (arrow functions), предсказуемый «this», block scope, генератор-функции, промисы, новые операторы. Некоторые хардкорные JavaScript программисты сразу затеяли дискуссии, насколько классы хуже функций, но эти дискуссии настолько же полезны, как споры, нужно ли писать фигурные скобки на отдельной строке или нет. Классы — это синтаксический сахар, который не меняет прототипного наследования, однако код писать и читать стало намного легче.

— Все основные браузеры уже поддерживают большую часть синтаксиса ES6.

— Новая группа тулзов (transpilers) легко генерят ES5 синтаксис из ES6 кода, чтобы можно было деплоиться в абсолютно всех браузерах.

— Появились десятки языков, на которых можно писать код с последующей конвертацией в JavaScript. Лучший из них — TypeScript, который придумал Anders Hejlsberg из Microsoft. Он также придумал C#, Delphi и Turbo Pascal.

— Тонны кода выложено в открытый доступ. Репозиторий npmjs содержит более 200 тысяч библиотек и тулзов. Кстати, пэкедж менеджер npm уже практически убил bower.

— Google сделал супер быстрый движок V8 для JavaScript. А благодаря фреймворку Node.js можно писать десктопные приложения, не требующие браузеров. Да и сервера можно писать. Причем, довольно мощные. Несмотря на однопоточную архитектуру коммуникаций с Node, асинхронная обработка позволяет обслуживать десятки тысяч одновременных клиентских запросов.

— Есть тулзы для build automation, которые минимизируют и оптимизируют JavaScript и пакуют отдельные файлы с кодом в бандлы, дабы браузеры не делали десятки запросов к серверу, чтобы открыть страницу.

— Появился стандарт WebComponents, который говорит о том, как писать кастомные HTML компоненты. Опубликованы принципы Material Design, объясняющие, как делать красивые страницы с современным луком. А все тот же (приравненный к СМИ) Google сделал классную библиотеку компонентов по имени Полимер. Мы уже опробовали ее на реальных проектах — работает!

Библиотеки и фреймворки

Сейчас ситуация устаканилась, и их количество стало почти адекватным.

Те, кто хочет получить все из коробки и не боится попасть в рабство к производителю софта, пока еще берут Ext JS. Этот фреймворк, наверное, единственный, за который просят денег. Выучить не просто, но есть все для создания приложений для использования внутри кровавого энтерпрайза. Наружу выставлять боязно, ибо Hello World весит около мегабайта. Однако внутри кровавого энтерпрайза Ext JS пока еще катит.

Те, кто хотят фрейморк поменьше, чтобы просто предложил стандартную структуру приложения с навигацией и привязкой данных, обычно берут Angular 1.x, Ember. Придется самому прикручивать сторонние библиотеки для графических компонентов и гридов и какой-нибудь Bootstrap, чтобы вашим приложением было не противно пользоваться на мобилках и планшетах, но это не очень страшно, если ты не джун. Некоторые предпочитают React, но и с ним придется использовать дополнительные библиотеки.

Те, кто хотят полный a la cart и думают, что сами знают, как строить приложения, подбирают себе набор библиотечек, каждая из которых умеет делать что-то одно, но хорошо. Придется самому прикручивать их друг другу и надо быть готовым, что нарезка резьбы на соединениях может не совпадать. Однако при помощи молотка, зубила и какой-то матери рукастые сеньоры соединяют несовместимое, за что просят денег не меньше, чем джависты.

Осваиваем тренды

В этом сезоне будет модным все, что как-то связано со словом «реактивный». Не то, чтобы это что-то новое (мы делали и месседжинг, и паб/саб, и обзервер/обзервабл 20 лет назад, если че), но это круто в сегодняшнем асинхронном мире. А для приложений, где есть UI, асинхронность — это маст хэв. Надо заметить, что придуманы реактивные библиотеки тоже во всеми нелюбимом Microsoft. В реактивном мире все компоненты и сервисы реализованы как потоки. Ты — поток, и я поток. Кнопку нажал — поток выплюнул событие как следующий элемент потока. Сделал запрос к серверу — получи ответ как элемент потока. И что интересно, подписчик потока сидит у краника, регулируя силу потока.

А год назад команда разработчиков Google решила переписать супер популярный Angular. Сначала они даже придумали свой язык AtScript, а потом договорились с Microsoft, чтобы те добавили фич в TypeScript. Опять же, RxJS туда вмонтировали для реактивности. Теперь код легко читать даже людям, пишущим на Java и C#.

А как это выучить? Что почитать? Где-то в июне на торрентах должна появиться книжка «Angular 2 Development with TypeScript», которую пишем я и мой коллега Антон Моисеев. Тем из вас, кто любит покупать книжки, советую ввести код faindz и купить книжку со скидкой в 39% (пока Manning выложил 300 страниц). Те, кто предпочитает 100% скидку, возможно смогут найти книжку сами знаете где. В любом случае, советую скачать.

Если вы хотите выучить Angular 2 в классе, то я буду проводить двухдневный воркшоп в Киеве 23-24 мая. Приглашаю.

В любом случае, JavaScript набирает обороты и спрос на рынке труда будет только расти. Be there.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

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

Схожі статті

  • Front-end Developer: хто він та скільки заробляє. Аналітика DOUFront-end Developer: хто він та скільки заробляє. Аналітика DOU

    Редакція DOU

    Хто такий фронтенд-розробник, на якій мові він пише, які фреймворки використовує, де мешкає та скільки заробляє. Проаналізували 1440 анкет фронтенд-розробників літнього зарплатного опитування та відповіли на всі ці питання.

  • Vue-типізація legacy Vuex Store: вирішення проблемиVue-типізація legacy Vuex Store: вирішення проблеми

    Коля Коваль

    Вітаю! Мене звати Микола Коваль, я Front-end Team Lead компанії SocialTech, і це моя коротка історія про те, як ми Vuex типізували. У статті я розповім, як просто й безболісно здружити типи компонентів з Vuex за допомогою кількох рядків коду. 1




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

Программирование переходит в web. А в web правит JavaScript. Развитие неизбежно.

193 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Яков, а что касательно реализации поддержки ES 7, в браузерах? Ну и всей этой истории с много поточностью, Worker и пр. На все это есть существующие ограничения, так что не вижу я особо пространства для маневра.

когда гривна была еще по пять
Может, доллар?

Oops :) Да, перепутал.

Только вливаюсь в тусовку современного JS программирования. До этого работал в компании, где мы просто делали и поддерживали сайты, верстали и использовали jQuery в основном. Перешел в новую компанию, где требуется разработка с использованием NodeJS, Angular2. У меня, как для человека, который всегда старался минимизировать кол-во подключаемых библиотек, не оставлять ничего лишнего в проектах и старался их максимально его оптимизиовать вызывает смущение количество папок и файлов в папке /node_modules при использовании NPM. Куча лишних файлов типа readme.md, папки с демками на мой взгляд захламляют диск. Но приходится все это использовать и ставить, ибо именно этого требует работа. Возможно я не прав в чем то. Хотелось бы обменяться опытом, мнениями с грамотными людьми на этом ресурсе. Спасибо.

Верно мыслите, но вот возьмем веб приложение в целом, как комплекс, самый минимум.
web server + web lang + cache + db ( например nginx + php + redis + mysql)
посчитайте количество модулей во всей системе, а теперь представьте что Node.js заменяет сразу web server + web lang + cache, если смотреть под таким углом, то даже 50 модулей кажутся мизером, по сравнению с тем сколько всего будет при трех отдельных приложениях. Более того, в идее самой ноды заложена поддержка большого количества модулей, так что все нормально. А вот демки и прочие мусорные файлы, можете их удалить, но ресурсов кроме винчестера они не требуют, а винты нынче недорогие.

Забейте на все хайповые жс-фреймворки с библиотеками. Они все приходят и уходят. Остается лишь plain js + dom + web components (webcomponents.org ). Иногда можно заюзать jquery ради rapid development. Все остальное либо слишком сложно, либо слишком тормозное, либо с ущербной архитектурой.

в Node.js нет DOM и jQuery там тоже нет.

а вы не смотрите в папку node_modules. какая вам разница до тех ридми файлов? вам жалко пару метров жесткого диска?

Конечно смотрю и конечно жалко. Во-первых все должно быть под моим контролем, во-вторых мне даже жалко, когда человек слушает одну и ту же песню всякий раз в ВК, перегоняя трафик, вместо того, что бы ее 1 раз скачать и слушать с жесткого диска. Планета Земля у нас одна :)

как вы живите, со знанием того что все идет в онлайн?

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

Если так жалко места, напишите скрипт postinstall, который будет удалять все файлы с расширением .md. Можете еще повозиться с настройками, чтобы все модули ставить 1 раз глобально, а в проектах были symlink-и. Некоторое количество места сэкономите.
А из продакшн-сборки всё лишнее убирать можно и нужно, тот же Webpack это умеет.

От Managing Director конечно сложно ожидать другого тона статьи про JavaScript, но вот как все может выглядеть со стороны разработчика:
medium.com/...-last-10-days-fb5c50917df

И то верно, менеджинг директора небось и if-statement в глаза не видели. А если и видели, то не знают на какой строке писать фигурные скобки. :)
А вот на приведенную статью реального пацана я ответил три недели назад: yakovfain.com/...frustrated-by-javascript

Я где-то упоминал что вы не умеете писать код?
В целом ответ ваш «реальному пацану» никак не отменяет всех тех вещей о которых он пишет. JavaScript есть везде и он очень популярен — ОК, с этим никто не спорит.
«You can run, you can hide, but you can’t escape JavaScript» и это тоже ОК.
Не ОК — это «tooling sucks». И тратить месяцы на изучение фреймворков/тулзов которые завтра уже неактуальны — тоже не ОК.

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

Кстати, в прошлом году я работал на Java проекте, где билд скрипт на Мавене занимал 3000 строк. Что-то не хочется мне такой стабильности.

Кстати, в прошлом году я работал на Java проекте, где билд скрипт на Мавене занимал 3000 строк. Что-то не хочется мне такой стабильности.
Попробуйте Go — там все просто, никаких xml конфигов, никаких jvm+jar+callback hell’ов, никаких сторонних серверов типа apache или nginx — все билдится в один бинарник, который просто заливаешь на сервер и рестартуешь. И в отличие от nodejs, в Go есть настоящая многопоточность на все имеющиеся ядра процессора.

Это был проект для крупной финансовой компании. Там мне не разрешали поставить даже последний релиз Java пока его не одобрят enterprise architects. Ни о каком Go и речи быть не могло. Пробовать можно на своих пет-проектах или в стартапе.

И правильно делают. Во всяком случае в Maven проект можно собрать, а пакетный менеджер Go втупую тянет с гитхаба последнюю версию независимо от того в каком оно состоянии билдится\небилдится и тут как уже луна сойдеться со сборкой проекта и обратной совместимостимостью.

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

Очень удобный подход, лет 10 назад java script девелоперы так и поступали.

Можно подумать на бекенде как то подругому

На бекенде с яваскриптом все в точности так же

Прт чем тут яваскрипт? Кстати с ним на бекенде все намного проще

Давайте-ка напишем бекенд:
Java:
— Play
— Spark
— Spring
— Hibernate
— JUnit
— Maven
— Ant
— Gradle
— Docker
DataBase:
— PostrgeSQL
— MySQL
— MariaDB
— MS SQL
— Oracle
— MongoDB
— Redis
— Cassandra
— HBase
— Hadoop
C# (ну тут по проще будет):
— ASP.NET MVC
— WebForms
— Entity Framework
PHP:
— Symfony
— Laravel
— Sylix
— Zend
— Yii
— Doctrine
— PHPUnit
— Composer
... тут еще много чего, токо я не помню
Ruby:
— Ruby on Rails
— Sinatra
— RSpec
Python:
— wiki.python.org/moin/WebFrameworks там большой список
Node.js:
— express
— meteor js
— jade
— mongoose
— meteor
— mocha
— chai
— npm
— gulp
— grunt

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

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

а теперь посмотрим на фронтенд:
— Ember
— ExtJs
— Angular
— React
— Flux
— Redux
— Handlebars
— jQuery
— jasmine
— karma
— protractor
— gulp
— grunt
— webpack
— npm
— bower
— jasmine
— mocha
— Old JS
— ES6
— TypeScript
— CoffeeScript
— CSS
— LESS
— SASS

если сопоставить эти списки то фронтенд будет поменьше бекенда.

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

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

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

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

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

все личные ощущения завязаны на том что взпападло учить фронт, все привыкли считать что там ничего сложного нет, что уже лет как 5-10 не правда

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

а кто вас заставляет обновлять их?
Например заказчик, который хочет фичу X, ставшую доступной в версии либы Y.

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

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

Например заказчик, который хочет фичу X, ставшую доступной в версии либы Y.
так такое и в бекенде бывает.
Я лет 5 занимался исключительно фронтендом, еще лет 5 — бекендом, с различными зоопарками технологий. Поэтому не вам мне рассказывать что кому было западло учить. Мои личные ощущения никак не связаны ни с фронтендом ни с бекендом.
и вы мне хотите сказать что не знаете/теряетесь когда какую фронтенд технологию используете?

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

Спасибо за статью. Вставлю свои 5 коп.
imho каждый язык имеет
— какие-то причины появления (т.е. зачем-почему он вообще, задумка какая была),
— какие-то цели, которые пытались решить, задачи его
— причины сохранения его популярности

На основе этого уже можно строить какие-то прогнозы. Мое мнение о JS такое:
— нужен был броузерный client-side язык для динамического html
— он должен был быть легко реализуем в разных броузерах, у него должен был быть простой синтаксис

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

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

А Java появилась для программирования кофемолок.так и тянет за собой все оттуда, как бы не развивалась.

Оценку ЯП нужно давать по тем возможностям которые есть в нём сейчас. И тем более нелепо из все мы родом из детства делать вывод — остались детьми.

Конечно-конечно, оценку надо давать по тому, что есть сейчас, историю учитывать не стоит.
И нелепый вывод про то, что все остались детьми сделали опять таки вы.

Эволюцию JS надо смотреть по эволюции стандартов ECMAScript. И я лишь говорю о том, что как правило все идет в сторону добавления нового, а не отмены того, что было заложено в самых первых стандартах («детство»). «strict mode» на мой взгляд одна из попыток исправить детские болезни.

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

Взрослые мальчики должны уметь сами себе попу подтирать :)

проблема отстрела собственной ноги обсосана в деталях еще со времен С.

В том-то и дело, что compilation error возник не на пустом месте. И не нужен он был понятное дело для простого client-side языка.
Но все ж полезло на server-side. А там кровавый enterprise.

Но все ж полезло на server-side. А там кровавый enterprise.
с каких пор server-side стал исключительно enterprise??? O_O
потом, node в enterprise вроде никто не сует, я слышал что некоторые возбухают, что мол как это так если впихнуть в ентрепрайз, оно же все сломает!
но, это должен быть исключительный случай чтобы node была оправдана в enterprise для бизнес логики, я себе даже такого представить немогу
проблема отстрела собственной ноги обсосана в деталях еще со времен С.
только так сильно вы себе в js не стрельнете при всем своем желании
В том-то и дело, что compilation error возник не на пустом месте.
статический анализ кода — тоже.
— Тонны кода выложено в открытый доступ. Репозиторий npmjs содержит более 200 тысяч библиотек и тулзов. Кстати, пэкедж менеджер npm уже практически убил bower.

Кстати, может мне кто-то объястин почему сейчас тот же jQuery или Bootstrap ставят из npm, а не из bower?

Потому что держать два установщика пакетов, если тоже самое можно делать при помощи одного — избыточность. Например, при сборке проекта на сервере вместо запуска одного менеджера пакетов — необходимо запускать два. А почему пакеты для фронта начали класть в npm — ответ browserify.

По поводу jquery не знаю, но node_modules чаще чем bower_components находится в пути поиска по-умолчанию . Конечно многое зависит от разработчика конкретной используемой тулзы, но как бы , костным мозгом, когда делаешь тот или иной import ’tool’ - понимаешь что он будет импортирован из node_modules. В пример наверное можно привести brocolly сборщик, browserify в связке с babel и тд и тп.
Что хотелось бы отметить, так это cdn для npm пакетов. Очень гибкая утилита, позволяющая подтягивать конкретную версию/таг пакета, что ярко отличает npm от bower, когда в последнем надо обязательно пп****ть положить готовую сборку. Хотя, возможно и это есть у bower’a , не знаю , пользуюсь npm )))

Очень гибкая утилита, позволяющая подтягивать конкретную версию/таг пакета, что ярко отличает npm от bower
щито?
это типа
«angular»: «1.3.4»?

а, затупил, смутили слова про тулзу.
CDN-сервис, ориентированный на зависимости, опубликованные под npm.
ясно, спасибо за инфо.

Главный плюс в том что он собирает сам (если надо по тагам и пр. фильтрам из репозитория) . В этом npm ушел дальше bower’a , у которого cdn (как мне всегда казалось) было единственным приемуществом.

Не подскажите, нельзя ли настроить package.json / browserify — чтобы вместо пакетов в папке node_modules/ был враппер для пакета с npmcdn или подобного сервиса... Спасибо за достаточно интересную наводку по npm.

Такой необходимости пока не было, странный кейс конечно. Но похоже что нет ничего невозможного:
docs.npmjs.com/...package.json#dependencies
docs.npmjs.com/...#git-urls-as-dependencies

Ну почему сразу странный кейс. У нас приложение где один скомпилированный файл может достигать размера пары мб (значимый код + npm зависимости вроде реакта). Конечно это все собирается при помощи browserify. И при каждом ре-билде клиентам приходится загружать обновленную версию файла. Если вынести зависимости в CDN, а npm сам нагенерит вставок SCRIPT SRC, то клиентам необходимо будет загружать только значимый код — все остальное будет уже лежать в кешах браузера.

Но что то мне подсказывает, что приведенные ссылки не о CDN, а о стягивании зависимостей с гита, если их нет в npmjs.com.

А-а-а, в этом плане. Да да, очень даже гуманно.

Мы используем локальные файлы в node_modules и используем Webpack для построения бандлов. Все зависимости (например Angular и Bootstrap) идут в один бандл , который шарится другими бандлами (аппликационный код). При таком сетапе есть возможность конфигурировать http сервер, чтобы он отдавал только измененный бандл, а тот, который шарится будет браться из кэша браузера.

Да в общем то мне не обязательно грузить все npm модули асинхронно, мне достаточно вынести React и парочку других библиотек в CDN и грузить их синхронно, потому что это действительно имеет значение при первом открытии страницы после нового релиза (они у нас очень часто).
Webpack мне кажется достаточно громоздким с избыточной конфигурацией. В случае с npmcdn мне кажется достаточно browserify плагина для того чтобы вынести подключение определенных модулей в CDN. Тем более это решение можно будет использовать в уже существующих архитектурах использующих browserify особенно ничего не меняя в логике построения билда.
Частично проблему можно решить при помощи www.npmjs.com/package/browserify-shim, но в этом случае каждую внешнюю зависимость прийдется прописывать ручками, да и подключать в тело документа тоже ручками.

Холивары Java vs. JavaScript, как мило.

И вы такой решили взять вашу прогу, написанную, когда гривна была еще по пять, и запустить ее на новеником айфоне 6S. Или даже 6S плюс. Вуаля! Она работает без малейших изменений в коде!

Нюанс. На новеньком, так и быть, работают. А вот не такой новенький айпод, у которого потолок ОС=7.0, говорит что эта софтина будет работать исключительно с 8.х. Вот и весь сказ. Про зоопарк андроидов можно промолчать.

JavaScript приложения же, о которых шла речь работали бы и на старых айподах, и на новых айфонах, ДОУ, например, работает же :)

Я не знаю про язык Х, однако программы, написанные на JavaScript 15 лет назад, работают на айфонах.
Толсто. Я знаю очень древние игры, которые можно запустить через эмулятор доса на любом устройстве, включая айфон. Ну а про Unix утилиты на Си, которые можно сбилдить под разные архитектуры, где даже браузерами не пахнет.
А благодаря фреймворку Node.js можно писать десктопные приложения, не требующие браузеров.
Благодаря чему и что? Впервые слышу, что на ноде можно писать десктопный UI без применения определенных врапперов, а что Node теперь из биндингов к V8 перешел в разряд фреймверков — феномен.
Тема бэкэнда не раскрыта. Однобоко, попахивает глупым фанатизмом и рекламой.
что на ноде можно писать десктопный UI без применения определенных врапперов
Никто не говорил что без врапперов. Есть node-webkit с помощью которого написан например Slack.

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

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

по сравнению с Angular-ом даже React не особо то стрельнул. и по большому Angular 2 потерял главной преймущество первой версии

Да, Angular 1 мне показался каким-то php, только для JavaScript, в хорошем смысле конечно.
Он был также прост и удобен, хоть с датабилдингом у него бывали проблемы на крупных проектах, на малых он просто брал стабильный джекпот.

и по большому Angular 2 потерял главной преймущество первой версии
это какое преимущество-то? куча непривычных новичку концепций с тонкими нюансами(миллион статей о различии сервисов, фабрик и провайдеров или ж о «как правильно писать контроллеры»), глобально конфигурируемые сервисы(писал отдельный независимый компонент с поддержкой i18n: если брать angular-translate, то либо компонент будет нормально работать, либо родительское приложение — смотря, кто первым сервис сконфигурит), одностороннее связывание только к версии 1.3? что я там еще забыл? :D
не, серьезно, вот, без подколок, не вижу преимуществ, с нетерпением жду ответа

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

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

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

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

И безусловно когда приходилось использовать все эти

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

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

Если с Babel, то мы пользуем не только ES6/ES2015 даже ES2017 (async / await)

Используют и очень даже часто. Через Babel. Пора бы уже, пора. ES5 после покажется кашей.

А про ReactJS так аккуратно и вскользь ,), хотя в свете реактивного программирования и ухода от классической парадигмы MVC, стоило бы уже сразу рассмотреть всех игроков.
У себя мы успешно сидим на typescript уже 3-ий год, но есть и другие. Как же ES6/Babel? Dart? Coffeescript?

Dart?
он хоть где-то используется за пределами туториалов от гугл?

Возможно, что и нет. Ничего серьезно написанного на нем не встречал.

Мы в прошлом году сделали и задеплоили в продакшн один проект на Dart. Хорошая штука. Жаль, что Гугл не смог продать его в ентерпрайз. Если кому интересно, в прошлом году я делал презентацию по Dart в Нью Йорке: www.youtube.com/watch?v=1da_wG7MV1s

Вот и мне сразу показалось, что Dart явно писали джависты :)

Каким образом парадигма реактивного программирования мешает продолжать использовать MVC? Они взаимодополняют друг друга, а не являются противоречием

Все верно, но вот некоторые теоретики считают это уже новым паттерном — www.infoq.com/...es/no-more-mvc-frameworks

Здесь можно бесплатно скачать первую главу нашей книжки manning.com/...velopment-with-typescript. Там побольше про фреймворки.

Если уже говорить о фреймверке, как о чем то делящее твое приложение на слои, то тогда странно, что просто React — это ведь просто вью. Очень скептически отношусь к наколенной архитектуре поверх реакта — тогда уже и jQuery неплох.
Flux, Redux.

хорошая статья

Те, кто предпочитает 100% скидку, возможно смогут найти книжку сами знаете где
Лол. А вообще давно пора сделать книжный магазин вроде Steam со скидками и гринлайтом.
со скидками и гринлайтом.
с блэкджеком и шл скидками
Появились десятки языков, на которых можно писать код с последующей конвертацией в JavaScript. Лучший из них — TypeScript, который придумал Anders Hejlsberg из Microsoft. Он также придумал C#, Delphi и Turbo Pascal.

— это че за нафиг?

А все понятно, ставить тег #самопиар надобно

He was the original author of Turbo Pascal and the chief architect of Delphi. He currently works for Microsoft as the lead architect of C# and core developer on TypeScript.

Кстати крутой чувак, но все почему-то восторгаются клоуном Пайком

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

Монстр — це коли замість сторінки коду пишете 3.5 рядки? :-)

Монстр — это когда 3.5 строки кода тянут за собой огромное количество классов.

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

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

cdewaka.com/...3/06/wpid-acme-editor.png

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

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

Никогда не понимал что движет людьми в идолопоклонстве

Воу-воу, ущемили чувства верующих!

крантика — краника

Программирование переходит в web. А в web правит JavaScript. Развитие неизбежно.

Ну, ваш веб должен кто-то процессить на сервере, а nodejs (который кстати на С написан, просто синтаксис поддерживают) не всегда справляется как надо.

Кстати, пэкедж менеджер npm уже практически убил bower.

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

на полном серьезе люди предлагают выкинуть bower и использовать только npm для frontend-зависимостей.
или вы в курсе, просто про построение фразы непонятное?

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

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

Java тогда еще обещала «Write once run anywhere», а реально воплотил это обещание JavaScript.

по моему он его воплотил также как и Java

Только Java нет нигде по умолчанию, а JavaScript есть в любом браузере на любом устройстве.

и умеет он, как и 20 лет назад, подсветить кнопочку и ролловер.

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

os-level threads наверняка фича языка, правда? Читаешь Kernighan Ritchie, а там про них везде.

вообщем сказать вам нечего.

из вашего ответа неясно, умеет ли яваскрипт os-level threads или нет

из вашего ответа неясно, есть ли умение управлять os-level threads частью языка?

то есть ты ляпнул, не подумав, а признаться стыдно? :-)

Нет, ляпнули вы. Особенно если вы не в курсе, что JavaScript не только кнопочки светит. 15-летним капитанам хорошо бы про это знать.

И тем более сравнивать языки со static vs dynamic compilation и automatic vs manual memory management.

ок, все ясно, тут, пожалуй, можно и закончить. успехов!

зависит от рантайма, хотя смысла в этом нет — вся натура что браузерных, что node.js приложений — один поток (и тут куча плюшек, ведь локов уже нет!), все асинхронное.

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

интересно другое — чего вы за

умеет ли яваскрипт os-level threads или нет
так зацепились? это что, показатель успеха языка (или платформы)? :D
нужно скейлить на ядра/процессоры — нет проблем, сколько ядер, столько инстансов процесса. ну и лоад балансер (хттп ли, или очередь сообщений — это уже от задачи зависит). все просто и прозрачно.

существуют задачи, где shared memory между потоками существенно облегчает жизнь. но ваш посыл об области применения яваскрипта я понял :-)

так зацепились?

вообще это просто вопрос был, пока у того парня пукан не порвало

существуют задачи, где shared memory между потоками существенно облегчает жизнь
время доступа к memcached, redis не сильно больше (в абсолютном выражении, по крайней мере), чем к разделяемой памяти с локами (вы же не только читаете, еще пишете небось).

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

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

вы просто рассматриваете этот инструмент в области, для которой он не предназначен

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

и, в любом случае, если все еще помните, ветка развилась из-за обидного

и умеет он, как и 20 лет назад, подсветить кнопочку и ролловер.
которое, конечно же, содержит чересчур много сарказма и не соответствует действительности

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

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

Однако верная мысль все же,

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

Node, Angular, React, Ember ? Не, не слышали?

ага и вот так берешь и запускаешь любой js на любом браузере?)

где например сейчас можно сейчас запустить код с E4X?

“This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.”

developer.mozilla.org/...n-US/docs/Archive/Web/E4X

Где вы вообще это нашли?

Это прекрасно. Но deprecated есть deprecated. Вопросы к Demandware.

вопрос ведь не в deprecated или не deprecated, а в совместимости js между движками и о легкости запуска. E4X это лишь пример и задеприкейтили его совсем недавно.

Да нет, вопрос как раз в этом. ES5 100% поддерживается всеми современными браузерми. ES2015/ES2016 также, через Babel.

А deprecated specs, на то и deprecated, что их поддержку никто не гарантирует.

language extension that adds native XML support to JavaScript
language extension!

И вообще да, апихи могут меняться. Но это апихи, это не сам язык. Синтаксис оставался неизменным уже много лет.

у меня вот SwaggerUI не на любом работал. Вот те и ран евривер. На IE шнике гадском не работал.

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

Примеры? Про Babel слышали и библиотеки, поддерживающие даже IE 8, который даже MS хочет давно убить?

Так я и не говорил, что нет инструментов, которые эту проблему решают. Но это не означает что её в корне нет.

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

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

Для Java все равно нужна JVM. Считайте, что Chrome или Node.js это ваша JVM. В чем тогда различие?

Вот именно, чем тогда джаваскрипт в этом плане лучше?)

Я лишь скажу, чем JVM лучше: один и тот же javascript-код далеко не всегда запустится и в хроме, и в ноде.

Тем, что браузеры есть везде, а Java (уже) нет нигде (по умолчанию). Уже писал об этом.

Почему нет?

Куча библиотек на npm и на Node.js и на front end одновременно: Bluebird, lodash, async, moment и т.д.

А у Java аплетов есть доступ к харду?

вас же аргумент, это проблема языка Java или устройства?)

Вы, как разработчкик можете влиять на библиотеки, которые используете. Если вы думаете, что имеете такое же влияние на пользовательскией устройства, то можете попробовать заставить всех в мире установить Java (как сейчас есть с JavaScript).

Так что в случае Java, это проблема платформы. И да, язык сам кривоват. Каждый раз видя callbacks в Java руки опускаются. Язык, где functions not first class citizens

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

Кстати, браузер на устройство тоже нужно устанавливать. Как и джаву, впрочем.

Не аргумент, потому, что это не проблема JavaScript, а недостаток всех языков с dynamic vs static typing.

А вот с функциями — конкретно проблема Java, которая превращает UI код в рахитизм (Android) и не дает использовать функциональную парадигму программирования.

Подскажите на какие устройства вы последний раз ставили браузер, потому что его там нет?

То же можно сказать и про functions as first class citizens vs что-то там без этого — Java ведь далеко не единственная такая.

Ну так а кто вам сказал, что разрабатывать UI на джаве — хорошо? Наверняка этот язык был выбран для андроида не из побуждений удобства написания UI, а скорее как что-то наиболее близкое к JVM. Кстати, поэтому сейчас и появился Kotlin, который вроде как отлично решает эту проблему.

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

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

Нет на Windows, нет нигде на мобильных. А броузеры есть. И мобильные устройства давно уже превысили ПК и ноутбуки.

Никто не сказал, но это грустный факт на Android.

Java — недоделанная. Она навязывает вам парадигму программирования и не дает выбора.

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

Ну а на ваше заявление о том, что джава — недоделанная, я даже отвечать не буду — это просто смешно. :)

Я вам привел пример её недоделанности. Я не про платформу JVM, а про язык.

Второй пример такой недоделанности — остутствие нормального type inference. Даже в C# это пофиксили частично var’ом в версии 3. В Java версии 8 все еще нет.

Уже два серьезных недостатка.

С такой точки зрения, например, С# тоже недоделанный, т.к. запускается только на винде. Но я не собираюсь обсуждать это сравнение, т.к. 1) не много знаю о С#, 2) тема не о нём. Скажу только, что в любом языке можно найти фичи, которых не хватает. Разработчики языков наверняка расставляют приоритеты не от балды, а у них есть на то веские причины, в коих ваши комментарии и мысли — лишь капля в море пользователей языка.

твои сведения про шарп устарели лет на 8...

Ну я действительно мало знаю о шарпе, с этим не спорю. Но я в курсе про моно и последние события с опенсорсингом С#. Только уточните, можно ли взять написанный 3 (читай 5, 8 и т.д.) года назад код в visual studio и запустить его на линуксе?

При чем тут visual studio? Опять тема уходит в сторону. Мы обсуждаем язык, а не платформы и IDE.

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

но а вообще на шарпе под линукс писать это то еще извращение

1) Вы опять путаете платформу и язык 2) С# запускается много где, узнайте что такое Mono 3) разработчки языка бывают разные. Когда делали Java, уже были Scheme, ML, Haskell. Уже тогда можно было оттуда подтянуть type inference, first order functions и functional programming. Но нет. Единственные новшества Java были в JVM и automatic memory management и этого хватило для того, чтобы стать популярным языком. Но это был 20 лет назад. Сейчас это просто багаж и куча legacy code. И относительно низкая популярность Java в стартапах тому подтверждение.

Посмотрите, что Apple влепил в Swift на замену Objective-C и еще раз убедитесь в моей правоте относительно неадекватности Java на сегодняшний день. Я очень надеюсь у Google хватит воли заменить Java на Android. Тогда ее уделом останутся банки и другой брутальный legacy enterprise.

А на що міняти буде? Там ж ніби просто хочуть свою реалізацію JVM зробити.

Тож мова не про JVM (в Google давно свій VM / runtime), а саме про Java. Проблема в Java.

Здається проблема не стільки в Java, а скільки в тому, хто патентами на неї володіє.

З патентами проблема у Google не в Java, а в proprietary Java APIs from Oracle

Трохи помилився, так.

Подивимось що вони в результаті запропонують.

Круто хлопці взяли. Ну поглянемо що вийде.

И если вы не в курсе, то да, на Android нет JVM. Он не поймет даже class файл с Hello World.

Все компилируется в Dalvik bytecode и .dex (Dalvik EXecutable), а не .class files.

Во-первых, уже не Dalvik, а ART. Во-вторых, это тот же JVM, только оптимизированный для мобильных устройств. И если уже вы не в курсе, то .class файлы прекрасно компилируются в .dex (иначе нельзя было бы использовать существующий джава-код). То есть да, исполняются не они, но первоисточник в данном случае как раз .class файлы.

Т.е. мы с вами согласились, что самую простую Java программу в виде class файлов или jar не запустить даже на Android без дополнительных танцев?

Я не писал про Dalvik (VM). Только про Dalvik bytecode и .dex (Dalvik EXecutable). Они как были так и остались в ART.

Во-первых, уже не Dalvik, а ART.

Далеко не везде. На руках просто масса устройств, где никаким ART и не пахнет.

О да, это проблема... конечно проще ныть, чем сесть раз написать декоратор для функции, который будет проверять типы перед вызовом =)

Да я и не пишу на джс, чтобы ныть. Просто говорю, что везде свои нюансы.

А вы разве не проверяете, работает ли та или иная фича в браузере Х?

Нет, потому что есть Babel. Все пишем на ES2015 и async await хотя ни один браузер не поддерживает.

Не согласен. Хотя Java мой любимый язык программирования, для собственных небольших проектов его как раз всегда хотелось использовать из-за возможности портирования логики на разные устройства. 9 лет назад это казалось логичным выбором, т.к. в тренде был Java ME, который тогда поддерживался на большинстве устройств и конкуренцию ему составлял разве что Symbian. Даже с появлением Windows Mobile была поддержка Java ME, и программирование на Java привлекало именно этим. В то время JavaScript был исключительно скриптовым языком для веб страниц.

На сегодняшний день ситуация коренным образом изменилась. JavaScript сейчас можно использовать для фронтенда ( Angular, Knockout, CanJS, Ember, React и десятки других фреймвоков), для серверов (NodeJS, Express, Koa, Hapi, Restify, и др.), для десктопных приложений (здесь конечно все базируется на NodeJS так же как и в серверных приложениях) и для мобильных приложений iOS, Android, Windows Phone (Cordova, Inonic framework, NativeScript, React Native). В том числе можно разрабатывать на нем и приложения для SmartTV, Roku и ряда других платформ.

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

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

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

Его используют, конечно не так часто, как нативную разработку, но все же используют.

showcase.ionicframework.com — зайдите в archive и увидите порядка 500+ приложений. Пусть не много, но для фреймворка, который появился в мае 2015го не плохо.

Есть еще вариант React Native, продвигаемый Facebook. Он не использует движок браузера, а конвертирует JS код в нативный судя по описанию. Он пока еще только развивается, но примеры есть facebook.github.io/...eact-native/showcase.html

Про SmartTV и Tizen — на этих платформах есть JS SDK, который я уверен используется.

И на счет Java. На Java есть ряд очень многофункциональных приложений, которыми пользуются многие. Примером тому является JIRA компании Atlassian. Так вот даже они предлагают делать addonы к JIRA/Confluence на nodejs.

developer.atlassian.com/...ct-activity-tutorial.html

npm install -g atlas-connect

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

Примеров приводить можно много. Конечно Angry Birds не стоит писать на JS — очевидно, что с графикой и производительностью будет явный проигрыш перед нативными приложениями. Но у JavaScript есть своя ниша на рынке и он я думаю еe займет.

Ну вы меня немного перефразировали, я сказал «везде не используют» :)

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

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

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

Статическая типизация и есть главная причина, по которой мы пересели на TypeScript.Там продуктивность программирования выше, чем на JavaScript. В блогосфере можно наблюдать некое сопротивление (WTF?) со стороны хардкорных JavaScript программистов, которые чувствуют, что посягают на их свободу программировать без типов и меняют функции на классы. Однако количество софта, которое будут разрабатывать обычные программисты (не звезды) огромно и мэнеджеры проектов быстро оценят преимущества использования типов и синтаксического сахара, предлагаемого ES6.

Я не в курсе, в ES6 предлагают ввести типизацию? Или вы о классах?

Типизация в TypeScript, а классы и в ES6 и в TypeScript

Ох как в точку сказали. Хардкорным пуристам всегда можно предложить «any» вместе с optional-сами. ))) Только затем они сами всё заменят на строгую типизацию и интерфейсы, когда замучаются ставить проверки.

Java або .NET хіба нативно? Вони ж також мають певний рівень віртуалізації.
Справді нативно це коли є доступ до інструкцій процесора певної архітектури.

Ходите по тонкому льду, нужно понимать что JS в браузере — это исключительно и почти всегда UI. Если на сервере NodeJS — нишевая штука, опять таки — некоторые «нодовые» либы тянут код на C++ (потому что банально быстрее) — то есть ошибочно считать, что полноценное приложение — это только JavaScript — на самом деле это всегда сборная солянка из кучи технологий / языков.

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