Comments 76
Тренды JS на 2015 год — стать Action Script 3.0!
C новым годом! :)
C новым годом! :)
Ага, 2006 год — Adobe отдает в Mozilla Foundation исходники Tamarin для адаптации ES4.
Ну AS, как и JS всё есть реализации ES, так что не удивительно. Лично мне удивительно почему так восхваляют JS. Вот честно, без придирок и не учитывая некоторые тонкости, в целом — JS в нынешнем его проявлении — это прям копия PHP версии ~4, если убрать из пыха доллары, разве нет?
Хей, ребят, выж профессиональные программисты, обоснуйте мнение пожалуйста, вместо минусов. Я, например не вижу разницы, ну так тыкните носом — я переменю свой мнение, ёпрст.
В чем копия-то? Синтаксис что ли похож (хотя даже в нем есть куча отличий помимо бакса) и динамическая типизация?
Как насчет того, что JS является прототипированным языком и на этом основаны механизмы наследования (ну это если не смотреть в ES6), а PHP реализовано классическое ООП. Те же замыкания, анонимные функции доступны в PHP только с 5.3 версии.
Скорее всего приведение типов работает иначе.
Например, внезапно, php не обрабатывается браузерами.
Думаю таких особенностей много найдется.
Как насчет того, что JS является прототипированным языком и на этом основаны механизмы наследования (ну это если не смотреть в ES6), а PHP реализовано классическое ООП. Те же замыкания, анонимные функции доступны в PHP только с 5.3 версии.
Скорее всего приведение типов работает иначе.
Например, внезапно, php не обрабатывается браузерами.
Думаю таких особенностей много найдется.
Ну это всё вполне очевидные вещи и совершенно верные, но мысль у меня немного иная. Все гуру JS пропагандируют, как один — функциональный подход, т.е. прототипы остаются как бы не у дел немного. Давайте взглянем на исходники популярных библиотек, много ли вы там видели прототипов и более-менее человеческого подхода к разработке фреймворка? Всё, что рекомендуют при разработке на JS — это функции и функции, хотя php-ньюблам за это буквально руки отрывают, хотя в то же время JS позволяет выстроить вполне вменяемый и читаемый класс с нормальным наследованием, протектными, публичными, статическими свойствами, методами инстанса и статик методами класса. Именно этого я не понимаю.
Неймспейсы? Зачем нам неймспейсы, говорит JS, давайте сделаем костыль в виде AMD и проч. (а это ведь реальный костыль, т.к. сам язык не имеет подобного).
Передача по ссылке? Зачем нам она, давайте сделаем obseve и будем обходиться без new, просто Object.observe.
Вместо уже готовых идей из рубей, питона и того же пыха, в виде __get\__set будем использовать Object.defineGetter, а вместо __call\method_missing — создадим Proxy, говорят разработчики языка.
А потом удивляются, каким образом любое более-менее сложное приложение превращается в лапшу из подобных строчек, но нет, отвечают, это не JS-way. А какой же тогда js-way, если появляются и стремительно развиваются трансляторы и вполне себе полноценные языки, как CoffeeScript, TypeScript, Dart, что-там-ещё?
Неймспейсы? Зачем нам неймспейсы, говорит JS, давайте сделаем костыль в виде AMD и проч. (а это ведь реальный костыль, т.к. сам язык не имеет подобного).
Передача по ссылке? Зачем нам она, давайте сделаем obseve и будем обходиться без new, просто Object.observe.
Вместо уже готовых идей из рубей, питона и того же пыха, в виде __get\__set будем использовать Object.defineGetter, а вместо __call\method_missing — создадим Proxy, говорят разработчики языка.
А потом удивляются, каким образом любое более-менее сложное приложение превращается в лапшу из подобных строчек, но нет, отвечают, это не JS-way. А какой же тогда js-way, если появляются и стремительно развиваются трансляторы и вполне себе полноценные языки, как CoffeeScript, TypeScript, Dart, что-там-ещё?
Ну есть функцииональный подход, есть ооп подход при разработке, хочешь используй то, хочешь это. Кому надо говнокодит, кому надо выстраивают хорошую архитектуру приложения. Хотя в JS эти подходы прекрасно переплетаются.
Да есть куча фреймворков, где используются ооп подход, тот же dojo, backbone, kineticJS, jQuery, в любом более менее нормальном фреймворке где нужен ооп подход он есть.
Велкам ту неймеспейс на js:
var ns1 = {};
var ns2 = {};
AMD — это технология позволяющая разбивать приложения на модули и загружать их асинхронно, а не костыль и замена неймпейсам. А, например, requireJS ее реализация вне стандарта языка, так как сам по себе JS достаточно долго развивается, а технология нужна сейчас, в стандарте ES6 модульность таки заложена.
Что значит нет передачи по ссылке если только так и передаются объекты.
Обходиться без оператора new, ну я бы поглядел на это.
Причем тут Object.observe мне вообще не ясно и что в нем плохого. Отличная функция для чека изменения объекта. Может вы хотели использовать вместо нее сеттеры, эт конечно можно, но в некоторых ситуациях обсерв всего объекта куда удобнее, да и позволит сократить код.
Ну нет в JS особого синтаксиса неявных сеттеров\геттеров, во многих нормальных языках программирования их вообще нету. Хочешь сделать сеттер\геттер сделай их. Тут просто вопрос удобства. Тем более что язык предоставляет возможность реализации и неявного механизма. Так что не понимаю в чем проблема.
Специально глянул, что за __call\method_missing и приржал (оф документация МАГИЧЕСКИЕ МЕТОДЫ), в который раз убеждился, что ООП в PHP — это недоразумение не для людей как и сам язык, и славлю богов, что в свое время перешел с него на богоподобную в этом плане JAVA.
>В контексте объекта при вызове недоступных методов вызывается метод __call().
Я, конечно, понимаю зачем это, но это просто полная ахинея. За все мои 8 лет программирования (как для серверных, так и для клиентских приложений), я ни разу не сталкивался с выше описанной надобностью. Но опять же, js позволяет реализовать это недоразумение при необходимости.
Пишу приложения (сложные и простые) на JS 5й год, использую модульный подход и ооп, лапши не больше не меньше чем в других языках. Что я делаю не так?
Очевидно, что coffeescript популярен благодаря синтаксису (мне лично не нравится, я олдфаг) и сахару. Typescript вообще ни разу не популярен (само собой он есть в этой статье ибо язык то мсовский) (хотя тайп чекинг хорошая штука, жаль что в es6 нету), как и Dart (вообще недоразумение мертворожденное). Приржал, когда аутсорсил в одной крупной зеленой компании и типы с соседнего проекта сказали, что прототипрование это очень сложно и не понятно, давайте будем использовать Dart.
Да и вообще зачем вы мне описываете какие-то тонкости языка, если хотели узнать чем PHP отличается от JS. Вы мне предлагаете разрабатывать интерфейсы на PHP или тупо ради холивара (если так то php — ведро с говном, самый плохой язык, на котором я что то делал).
Да есть куча фреймворков, где используются ооп подход, тот же dojo, backbone, kineticJS, jQuery, в любом более менее нормальном фреймворке где нужен ооп подход он есть.
Велкам ту неймеспейс на js:
var ns1 = {};
var ns2 = {};
AMD — это технология позволяющая разбивать приложения на модули и загружать их асинхронно, а не костыль и замена неймпейсам. А, например, requireJS ее реализация вне стандарта языка, так как сам по себе JS достаточно долго развивается, а технология нужна сейчас, в стандарте ES6 модульность таки заложена.
Что значит нет передачи по ссылке если только так и передаются объекты.
Обходиться без оператора new, ну я бы поглядел на это.
Причем тут Object.observe мне вообще не ясно и что в нем плохого. Отличная функция для чека изменения объекта. Может вы хотели использовать вместо нее сеттеры, эт конечно можно, но в некоторых ситуациях обсерв всего объекта куда удобнее, да и позволит сократить код.
Ну нет в JS особого синтаксиса неявных сеттеров\геттеров, во многих нормальных языках программирования их вообще нету. Хочешь сделать сеттер\геттер сделай их. Тут просто вопрос удобства. Тем более что язык предоставляет возможность реализации и неявного механизма. Так что не понимаю в чем проблема.
Специально глянул, что за __call\method_missing и приржал (оф документация МАГИЧЕСКИЕ МЕТОДЫ), в который раз убеждился, что ООП в PHP — это недоразумение не для людей как и сам язык, и славлю богов, что в свое время перешел с него на богоподобную в этом плане JAVA.
>В контексте объекта при вызове недоступных методов вызывается метод __call().
Я, конечно, понимаю зачем это, но это просто полная ахинея. За все мои 8 лет программирования (как для серверных, так и для клиентских приложений), я ни разу не сталкивался с выше описанной надобностью. Но опять же, js позволяет реализовать это недоразумение при необходимости.
Пишу приложения (сложные и простые) на JS 5й год, использую модульный подход и ооп, лапши не больше не меньше чем в других языках. Что я делаю не так?
Очевидно, что coffeescript популярен благодаря синтаксису (мне лично не нравится, я олдфаг) и сахару. Typescript вообще ни разу не популярен (само собой он есть в этой статье ибо язык то мсовский) (хотя тайп чекинг хорошая штука, жаль что в es6 нету), как и Dart (вообще недоразумение мертворожденное). Приржал, когда аутсорсил в одной крупной зеленой компании и типы с соседнего проекта сказали, что прототипрование это очень сложно и не понятно, давайте будем использовать Dart.
Да и вообще зачем вы мне описываете какие-то тонкости языка, если хотели узнать чем PHP отличается от JS. Вы мне предлагаете разрабатывать интерфейсы на PHP или тупо ради холивара (если так то php — ведро с говном, самый плохой язык, на котором я что то делал).
Мог бы очень много возразить по поводу того что хорошо или плохо, но в целом, если пишется на JS прекрасно, то странно почему с PHP такие сложности, всё же в нём несогласованность распространяется только на именование функций, а в JS вообще на всю архитектуру языка, которую, надо отдать должное — последнее время почти успешно выправляют.
Отвечая на некоторые вопросы:
1) Передача по ссылке означает возможность когда угодно и что угодно передать по ссылке или по значению. Observe как раз и является таким костылём, который позволяет передавать значение переменной из одного места в другое, используя события подписки.
2) В питоне это __getattr__, в рубях — method_missing. При чём тут PHP и конкретно его аналог, называемый «магическим методом»? Эта практика применяется не только в этом языке. Очень удобно. Странно, что не приходилось сталкиваться, т.к. например простой ActiveRecord (в частности генерацию AR модели с динамическими свойствами) я просто не представляю как реализовать без мета программирования.
3) Лично мне Coffee приятен тем, что он (в т.ч. с помощью него) можно исправить многие косяки JS. Уже давно отказался от нативного JS в пользу оного.
В любом случае, не хотелось бы разводить холиваров, это да. Всю мысль я довольно чётко описал уже выше, в предыдущем посте. В пыхе тоже можно написать
JS — это феерический набор маркетинга и рекламы, основывающийся на действительно большом количестве разработчиков (за неимением веб клиент-сайд альтернатив), на существующей, действительно крутой кодовой базе (V8 гениален), но как самостоятельный язык — не способный на реализацию мощных и элегантных программ без плевков каждые пять минут… Хотя постойте, может просто я слишком близко познакомился с PHP, Ruby, Python (можно с чем угодно сравнивать, имхо) и уже не могу нормально воспринимать js-way и по этому стараюсь писать не так, как говорят, а так, как считаю будет понятным всем, ну например: pastebin.com/0GYRkVAm =)
Отвечая на некоторые вопросы:
1) Передача по ссылке означает возможность когда угодно и что угодно передать по ссылке или по значению. Observe как раз и является таким костылём, который позволяет передавать значение переменной из одного места в другое, используя события подписки.
2) В питоне это __getattr__, в рубях — method_missing. При чём тут PHP и конкретно его аналог, называемый «магическим методом»? Эта практика применяется не только в этом языке. Очень удобно. Странно, что не приходилось сталкиваться, т.к. например простой ActiveRecord (в частности генерацию AR модели с динамическими свойствами) я просто не представляю как реализовать без мета программирования.
3) Лично мне Coffee приятен тем, что он (в т.ч. с помощью него) можно исправить многие косяки JS. Уже давно отказался от нативного JS в пользу оного.
В любом случае, не хотелось бы разводить холиваров, это да. Всю мысль я довольно чётко описал уже выше, в предыдущем посте. В пыхе тоже можно написать
$ns1 = (object)[];, но это не будет неймспейсом — это будет просто пустым объектом. В пыхе так же можно динамически добавить свойство в этот объект, но это не будет элементом неймспейса — это будет просто полем этого объекта. Это костыль, который выдают в JS за «хороший подход» за неимением вменяемого. При разработке приложения, объёмом чуть более чем 20к строк кода у меня сложилось более чем чёткое впечатление: JS — это феерический набор маркетинга и рекламы, основывающийся на действительно большом количестве разработчиков (за неимением веб клиент-сайд альтернатив), на существующей, действительно крутой кодовой базе (V8 гениален), но как самостоятельный язык — не способный на реализацию мощных и элегантных программ без плевков каждые пять минут… Хотя постойте, может просто я слишком близко познакомился с PHP, Ruby, Python (можно с чем угодно сравнивать, имхо) и уже не могу нормально воспринимать js-way и по этому стараюсь писать не так, как говорят, а так, как считаю будет понятным всем, ну например: pastebin.com/0GYRkVAm =)
» простой ActiveRecord (в частности генерацию AR модели с
» динамическими свойствами) я просто не представляю
» как реализовать без мета программирования.
Не ради холивара, просто в качестве уточнения. Конкретно для ActiveRecord как раз достаточно механизма типа Java reflection. При инициализации (которая, как известно, и так не самое сильное место руби в плане скорости) заглянуть в таблицы и вызвать define_method на все, что нужно. Я не использую рельсы и давно в код не смотрел, но могу сказать, что если бы я пилил ActiveRecord я бы давно это сделал: вызовы method_missing довольно накладны.
Ну а товарищу, который не понимает, зачем нужно метапрограммирование, хочется ответить словами Паули: «Это не вопрос, это утверждение».
» динамическими свойствами) я просто не представляю
» как реализовать без мета программирования.
Не ради холивара, просто в качестве уточнения. Конкретно для ActiveRecord как раз достаточно механизма типа Java reflection. При инициализации (которая, как известно, и так не самое сильное место руби в плане скорости) заглянуть в таблицы и вызвать define_method на все, что нужно. Я не использую рельсы и давно в код не смотрел, но могу сказать, что если бы я пилил ActiveRecord я бы давно это сделал: вызовы method_missing довольно накладны.
Ну а товарищу, который не понимает, зачем нужно метапрограммирование, хочется ответить словами Паули: «Это не вопрос, это утверждение».
JS — язык динамический там в принципе не нужен механизм рефлекшена, потому что методы можно изменять, добавлять удалять в рантайме. Собственно так реализовывал AR на JS.
В 7 утра просто не гуглил все варианты того, что можно реализовать с помощью этого волшебного метода, опять же человек выше пишет о каких-то тоннах костылей в JS, и восхваляется этим недоразумением, которое используются как костыль вместо нормально рефлекшена. Не понимаю как можно сравнивать его с рефлекшеном в JAVA.
А в ES6 еще и будут славные аннотации.
В 7 утра просто не гуглил все варианты того, что можно реализовать с помощью этого волшебного метода, опять же человек выше пишет о каких-то тоннах костылей в JS, и восхваляется этим недоразумением, которое используются как костыль вместо нормально рефлекшена. Не понимаю как можно сравнивать его с рефлекшеном в JAVA.
А в ES6 еще и будут славные аннотации.
А reflection — это и есть рантайм вообще-то.
Кроме того, если вы не понимаете, зачем нужен тот, или иной метод — это не значит, что метод лишний. У меня почти не было проектов, в которых я бы не использовал method_missing. Например, для DSL. Это можно сделать и рефлекшеном, и на JS, и на баше. Но method_missing, очевидно, удобнее.
Кроме того, если вы не понимаете, зачем нужен тот, или иной метод — это не значит, что метод лишний. У меня почти не было проектов, в которых я бы не использовал method_missing. Например, для DSL. Это можно сделать и рефлекшеном, и на JS, и на баше. Но method_missing, очевидно, удобнее.
Да, с рефлекшеном я затупил (да и в php вполне нормальный рефлекшен как оказалось).
Само собой если он существует в языке, то скорее всего зачем-то нужен, другой вопрос в том насколько целесообразно использовать подобные магические методы, просто для упрощения себе жизни (зато вполне может вылезти в неприятную неожиданность для другого). Сама концепция вызова несуществующего в классе метода, кажется предельно странной, даже, например, с целью проксирвания вызова в другой объект. Собственно от того у меня и вызвал этот метод подобную реакцию.
Само собой если он существует в языке, то скорее всего зачем-то нужен, другой вопрос в том насколько целесообразно использовать подобные магические методы, просто для упрощения себе жизни (зато вполне может вылезти в неприятную неожиданность для другого). Сама концепция вызова несуществующего в классе метода, кажется предельно странной, даже, например, с целью проксирвания вызова в другой объект. Собственно от того у меня и вызвал этот метод подобную реакцию.
>всё же в нём несогласованность распространяется только на именование функций
PHP — это изначально скриптовый язык, в котором никакого ооп не было и в помине. Нормальное ооп было добавлено в 5й версии (и то что-то слабо мне верится, что в нем сейчас нет проблем). От этого очевидно, что пхп программисты стали использовать нормальные практики построения серверных приложений, использовать шаблоны программирования и т.п. относительно недавно. Собственно это видно даже по исходникам старых движков. На php я работал лет 6-7 назад, после чего я пересел на Java и с удовольствием кидаю какашками в этот язык (да, мб за последние 2-3 года он стал лучше, но почему меня это должно волновать, когда есть божественные Java/python/nodeJs). Лично мое мнение, если знаешь те же JAVA/Scala/Python/JS(NodeJS), то единственной причиной использовать этот недоязык — тебе за это платят, или твои знания в другом языке никому не нужны.
>JS вообще на всю архитектуру языка
Это ж какая такая несогласованность в архитектуре языка, расскажите пожалуйста? На JS как и на любом другом языке можно писать красивый код, использовать хорошую архитектуру приложений, а можно говнокодить.
1) Передача по ссылке означает передачу по ссылке и ничего больше, в js все объекты передаются по ссылке. Object.observe нужен для чека и обработки изменений в объекте, например, в angular реализован свой дерти чек для scope (благодаря этому там не нужны сеттеры и геттеры), и он является основой этого фреймворка. Причем тут передачи по ссылке или значению я не могу понять, developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/observe
2) В спеке языка ясно говорится для чего нужен метод __call, все остальное является реализацией костылей из-за отсутствия нормального механизма рефлекшена на основе нестандартного использования этого метода.(http://habrahabr.ru/company/microsoft/blog/247229/#comment_8208127) тут я описал свое мнение по этому поводу.
Неймспейсы — это неймспейсы, а модульность — это модульность. В JS некая отдельная реализация разделения пространства имен в принципе не нужна, так как с этим вполне справляются стандартные механизмы. И да — не засорять глобальный скоуп это действительно хороший тон (best practice) программирования на js, а не костыль.
Так как в стандарте ES5< попросту не был заложен механизм модульности (просто потому что реальная необходимость разработки больших сложных приложений на js возникла буквально лет 5 назад), он был реализован извне, назвать это костылем, все равно что называть костылем hibernate или реализацию любой другой технологии (тех же шаблонизаторов). (опять же в ES6 все это есть frontender.info/es6-modules/ ).
($ns1 = (object)[], блин тайп кастинг из массива в объект — феерия чудовищности. (я даже специально проверил, такой синтаксис объявления массива работает с версии 5.4 только, это ж просто пипец 20 лет языку и до осознания, того что нужен краткий синтаксис создания массива, только пару лет назад додумались).
Ваш js-way — это какой-то ваш манямирок, основанный на каких-то шаблонах разработки фронтенда из прошлого 10летия и попытки перетащить багаж знаний полученных при разработке на великолепном php во вселенную с другими физическими законами. Стеки технологий и архитектур js приложений сейчас шагают семимильными шагами, так что стандартизация языка просто не поспевает за ними. JS это не PHP в который понапихают быстренько непонятно что лишь бы хоть как-то работало.
Мне кажется, вы просто не хотите понять что js это не ооп язык, но его архитектура настолько универсальна, что уже 20 лет без особых изменений позволяет реализовывать стек современных технологий, в том числе позволяет использовать и ООП подход при разработке (да, нет полной поддержки инкапсуляции). И что сравнивать его с oop ориентированными языками — это глупое занятие. И думать при разработке js приложений через ооп тоже не совсем верно, а уж тем более через php (динамическое создание методов класса с помощью __call? зачем в js __call если методы\поля можно и так динамически создавать). Но опять же, ES6 — хочешь классический ооп — получай.
Не можете\не хотите в язык -> используйте другой или диалект (ничего не имею против coffeescript (единственное у меня сомнения в скорости трансляции в js больших проектов), лично мне он просто не нужен).
Тоже самое реализовывается и на js pastebin.com/6xYe8hF5, само собой что бы код понять, нужно попытаться хотя бы понять, как работает js, точно так же как и человеку, которому синтаксис кофи не знаком, надо в нем разобраться.
PHP — это изначально скриптовый язык, в котором никакого ооп не было и в помине. Нормальное ооп было добавлено в 5й версии (и то что-то слабо мне верится, что в нем сейчас нет проблем). От этого очевидно, что пхп программисты стали использовать нормальные практики построения серверных приложений, использовать шаблоны программирования и т.п. относительно недавно. Собственно это видно даже по исходникам старых движков. На php я работал лет 6-7 назад, после чего я пересел на Java и с удовольствием кидаю какашками в этот язык (да, мб за последние 2-3 года он стал лучше, но почему меня это должно волновать, когда есть божественные Java/python/nodeJs). Лично мое мнение, если знаешь те же JAVA/Scala/Python/JS(NodeJS), то единственной причиной использовать этот недоязык — тебе за это платят, или твои знания в другом языке никому не нужны.
>JS вообще на всю архитектуру языка
Это ж какая такая несогласованность в архитектуре языка, расскажите пожалуйста? На JS как и на любом другом языке можно писать красивый код, использовать хорошую архитектуру приложений, а можно говнокодить.
1) Передача по ссылке означает передачу по ссылке и ничего больше, в js все объекты передаются по ссылке. Object.observe нужен для чека и обработки изменений в объекте, например, в angular реализован свой дерти чек для scope (благодаря этому там не нужны сеттеры и геттеры), и он является основой этого фреймворка. Причем тут передачи по ссылке или значению я не могу понять, developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/observe
2) В спеке языка ясно говорится для чего нужен метод __call, все остальное является реализацией костылей из-за отсутствия нормального механизма рефлекшена на основе нестандартного использования этого метода.(http://habrahabr.ru/company/microsoft/blog/247229/#comment_8208127) тут я описал свое мнение по этому поводу.
Неймспейсы — это неймспейсы, а модульность — это модульность. В JS некая отдельная реализация разделения пространства имен в принципе не нужна, так как с этим вполне справляются стандартные механизмы. И да — не засорять глобальный скоуп это действительно хороший тон (best practice) программирования на js, а не костыль.
Так как в стандарте ES5< попросту не был заложен механизм модульности (просто потому что реальная необходимость разработки больших сложных приложений на js возникла буквально лет 5 назад), он был реализован извне, назвать это костылем, все равно что называть костылем hibernate или реализацию любой другой технологии (тех же шаблонизаторов). (опять же в ES6 все это есть frontender.info/es6-modules/ ).
($ns1 = (object)[], блин тайп кастинг из массива в объект — феерия чудовищности. (я даже специально проверил, такой синтаксис объявления массива работает с версии 5.4 только, это ж просто пипец 20 лет языку и до осознания, того что нужен краткий синтаксис создания массива, только пару лет назад додумались).
Ваш js-way — это какой-то ваш манямирок, основанный на каких-то шаблонах разработки фронтенда из прошлого 10летия и попытки перетащить багаж знаний полученных при разработке на великолепном php во вселенную с другими физическими законами. Стеки технологий и архитектур js приложений сейчас шагают семимильными шагами, так что стандартизация языка просто не поспевает за ними. JS это не PHP в который понапихают быстренько непонятно что лишь бы хоть как-то работало.
Мне кажется, вы просто не хотите понять что js это не ооп язык, но его архитектура настолько универсальна, что уже 20 лет без особых изменений позволяет реализовывать стек современных технологий, в том числе позволяет использовать и ООП подход при разработке (да, нет полной поддержки инкапсуляции). И что сравнивать его с oop ориентированными языками — это глупое занятие. И думать при разработке js приложений через ооп тоже не совсем верно, а уж тем более через php (динамическое создание методов класса с помощью __call? зачем в js __call если методы\поля можно и так динамически создавать). Но опять же, ES6 — хочешь классический ооп — получай.
Не можете\не хотите в язык -> используйте другой или диалект (ничего не имею против coffeescript (единственное у меня сомнения в скорости трансляции в js больших проектов), лично мне он просто не нужен).
Тоже самое реализовывается и на js pastebin.com/6xYe8hF5, само собой что бы код понять, нужно попытаться хотя бы понять, как работает js, точно так же как и человеку, которому синтаксис кофи не знаком, надо в нем разобраться.
Всё, что рекомендуют при разработке на JS — это функции и функции, хотя php-ньюблам за это буквально руки отрывают
Есть обычные функции, типа как в php4 или С, и есть функции высшего порядка, как в js. Так вот не поверите, но с помощью последних можно писать очень лаконичный код. Собственно все функциональные языки программирования используют функции как основной способ абстракции.
Даже в посте про JS, кто-то умудрился наехать на PHP. А так комментарий несколько не корректен. Никто не восхваляет JS. Есть ряд вполне объективных причин, почему он популярен.
Ну прям php4? Это ничего что у js из коробки и объекная модель и функции высшего порядка.
Да, в AS3 очень удачно встроена типизация. Но все же AS3 уже прошлый век, нет новых модных штук, нерешенная (вроде бы) проблема с утечкой памяти при использовании. Есть отличный новый язык Dart, но в нем мне не хватает простых объектов из AS3 и JS.
Есть отличный, новый стандарт ES6. Зачем нужен этот мертворожденный Dart мне не ясно до сих пор. Хотя, очевидно, что он не нужен и не взлетит, как тот же GWT, особенно с учетом скорого ES6.
Ларс Бак крупнейший спец по имплементации виртуальных машин и jit-компиляторов, исходя из своих познаний в этой области он хотел сделать идеальный язык, который сразу учитывает JIT и VM тонкости ещё на уровне дизайна языка. То есть в первую очередь скорость работы кода, эффективность сборщика мусора, скорость DOM manipulation.
Мне кажется тут имеет место быть не только желание просто выпустить новый язык, а еще и исследовательская работа. Даже если язык не взлетит — это опыт, который потом будет и дальше транслироваться в продукт.
Новый стандарт ES6 хорош всем, кроме того, что он пока не реализован в браузерах. Без реализации ES6 и внедрения DartVM в Chrome оба языка — хромоножки, портирующиеся в старый js.
В самом дарте и его потенциалах ничего плохого я не вижу. Почему он мертворожденный? Он начинает куда как лучше, чем самый первый js. Всего лишь дело времени и будет много проектов на нем, так же как сейчас есть куча проектов на coffee и typescript.
В самом дарте и его потенциалах ничего плохого я не вижу. Почему он мертворожденный? Он начинает куда как лучше, чем самый первый js. Всего лишь дело времени и будет много проектов на нем, так же как сейчас есть куча проектов на coffee и typescript.
> Удивительно, но одним из направлений роста нативной разработки на JavaScript неожиданно становятся умные телевизоры (например, LG с Open webOS), а также игровые консоли (например, Xbox One). Здесь просто нет альтернативы…
ну это не совсем так. в смарт ТВ разработка на js относится в сфере 3rd party приложений, но есть ещё NDK для действительно native.
ну это не совсем так. в смарт ТВ разработка на js относится в сфере 3rd party приложений, но есть ещё NDK для действительно native.
Ну понятно, что и под консоли есть возможность разработки и на «действительно» native. Я скорее про то, что классическая прослойка в виде ограниченного webview постепенно расстворяется.
А вы думаете в смарт ТВ не веб-вью? Фактически там просто браузер во весь экран. Более того, если предыдущие платформы, вроде LG Netcast и Samsung SmartHub довольно сильно расширяли доступный функционал браузера, то современные, такие как LG WebOS и Samsung Tizen по функционалу не далеко ушли от стандартного HTML5. И при этом это все дико тормозит, хуже чем на мобилках в WebView.
UFO just landed and posted this here
Про TypeScript более-менее ближайшая перспектива понятна: перейти в надмножейство ES6. Есть мнение, что подобные надстройки должны собственно стать локомотивом развития языка, или, как минимум, площадкой для экспериментов.
Сильнейшие диктуют условия и с этим приходиться как-то жить и подстраиваться. Сейчас все начали болеть статической типизацией и es6, количество языков и их генераторов растет каждый день, все хотят привнести что-то новое в js и это здорово. Тот же Typescript стал популярен из-за своей легковесности и прозрачной кодогенерации, все соскучились по типам, Хейлсберг и его команда делает правильные вещи. Но все же есть сакральные проблемы: язык отделяется от платформы, время трансформации в «обычный» js растет, отладка кода кастрированная (привет source maps), количество подходов и норм увеличивается и с этим надо считаться. Все забыли что комфорт не только в языке, но и в скорости, и в тулчейне, и в отладке.
Я вспоминаю свои первые дни в вебе с GWT. Уж до чего тяжелая и сложная платформа, которая работала на ура, с нормальной отладкой и ide, быстрой подменой кода кроссбраузерностью. Сейчас, на мой взгляд, этим требованиям удовлетворяют только Clojurescript и Elm.
Проблема большого выбора и разроненности сильно бьёт по удобству и комфортности разработки. Я ставлю на монолитные решения поверх js, за ними сила.
Я вспоминаю свои первые дни в вебе с GWT. Уж до чего тяжелая и сложная платформа, которая работала на ура, с нормальной отладкой и ide, быстрой подменой кода кроссбраузерностью. Сейчас, на мой взгляд, этим требованиям удовлетворяют только Clojurescript и Elm.
Проблема большого выбора и разроненности сильно бьёт по удобству и комфортности разработки. Я ставлю на монолитные решения поверх js, за ними сила.
Передайте разработчикам Cordova, что вон та затея их была весьма остроумною: складывать компоненты приложения Cordova в папку «cordova_components» (подобно тому, как Bower складывает в «bower_components», а npm складывает в «node_modules») — это важный шаг к логичности и обозримости структуры подкаталогов, а значит, и к простым файлам «.gitignore» также.
Жаль, что затея та не окончилася ничем существенным.
Жаль, что затея та не окончилася ничем существенным.
Одним словом, тренды в 2015 будут такие же, как в 2012.
Кстати, последний релиз Prototype вышел в апреле этого года, т.е. умирать он не спешит :)
Который год пытаются сделать из js нормальный язык, в то время как давно пора любой нормальный язык засунуть в браузер. Хотя бы по типу NaCl.
Объясните мне, пожалуйста. Почему в браузере не сделать возможность выполнять какой-то байт-код и не дать возможность писать на любом языке который в него умеет компилироваться? А джаваскрипт оставить как скриптовый язык для вызовов на странице. Ведь сейчас уже все понимают, что джаваскрипт не подходит для современных нужд разработки и пытаются делать более подходящие языки, которые компилируются в js.
Native client же об этом.
Вероятно из за того что язык сам по себе это еще не гарантия того, что новые приложения будут разрабатываться быстрее, будут надежнее и т.д. Есть еще экосистема, где много библиотек на все вкусы, есть устоявшиеся паттерны. Так что просто взять и выбрость годы наработок не получиться. А вот сделать нормальный интероп между языками — это задание не из легких.
Кроме того js не такой уж и страшный зверь как его все выставляют, жить можно, немножко подправить и все будет ок (ES6).
Кроме того js не такой уж и страшный зверь как его все выставляют, жить можно, немножко подправить и все будет ок (ES6).
Так что просто взять и выбрость годы наработок не получиться.
Я не писал и даже не подразумевал, что надо что-то выбрасывать. Я говорил лишь о том, что вместо того, чтобы компилировать в джаваскрипт, как это сейчас делают очень многие языки, не лучше ли сделать для этого байткод выполняющийся в браузере и компилировать в него. В том числе и джаваскрипт — хоть я и не считаю джаваскрипт действительно хорошим инструментом для создания приложений, я отлично отдаю себе отчет, что это мнение разделяют не все и многим он нравится, многие его знают и умеют в него, тем более, что новый стандарт действительно сделает язык сильно лучше во многих аспектах. Так что нет никого смысла умея выполнять байткод, не сделать возможность компилировать в него джаваскрипт, на котором уже написаны тонны кода для браузера.
Вероятно из за того что язык сам по себе это еще не гарантия того, что новые приложения будут разрабатываться быстрее, будут надежнее и т.д.
Конечно не гарантия. Только я ничего не писал ни о гарантиях, ни о зависимости языков от скорости и надежности приложений.
А вот сделать нормальный интероп между языками — это задание не из легких.
В такой ситуации минимальная интероперабельность всё равно будет, потому что в итоге все они будут компилироваться в одни и те же сущности платформы, а если у них еще будут общие средства для работы с браузером, то этого уже будет достаточно, чтобы использовать наработки друг друга.
Не статья, а сплошной Windiws. Это не тренды, это технологии, используемые в ОС Окошки. Да, хаб очевиден, но слишком пафосный заголовок. Учитывая, что в трендах и линуксы (андроидов десятки миллионов) наверно стоит обратить внимание на веб, как самобытное целое, а не часть виндовс.
Так же интересны планы по внедрению и реализации asm.js?)
Почему упущен второй общедоступный движок Unreal Engine, который имеет меньше игр по количеству, но качество игр великолепно покрывает количественную составляющую?) Поддержка webgl и портирования в браузер была выведена в рабочий релиз раньше юнити.
Говоря о TypeScript упущен его брат CoffeeScript, это потому что он не спонсирован ГК Мелкомягкий?
Говоря о геймпадах умышленно были опущены замечания, что этому стандарту предстоит эволюционировать?
Говоря о кроссплатформенности имеется ли в виду так же абстрагирование от операционной системы в целом и поддержка, влияние и развитие интерфейсов взаимодействия с ОС?)
Так же интересны планы по внедрению и реализации asm.js?)
Почему упущен второй общедоступный движок Unreal Engine, который имеет меньше игр по количеству, но качество игр великолепно покрывает количественную составляющую?) Поддержка webgl и портирования в браузер была выведена в рабочий релиз раньше юнити.
Говоря о TypeScript упущен его брат CoffeeScript, это потому что он не спонсирован ГК Мелкомягкий?
Говоря о геймпадах умышленно были опущены замечания, что этому стандарту предстоит эволюционировать?
Говоря о кроссплатформенности имеется ли в виду так же абстрагирование от операционной системы в целом и поддержка, влияние и развитие интерфейсов взаимодействия с ОС?)
«CoffeeScript» стоит упомянуть, что я пока видел ровно 1 его апологета, а вот на TypeScript переходит уже третья моя команда.
«Говоря о геймпадах умышленно были опущены замечания, что этому стандарту предстоит эволюционировать?» а какому web стандарту не предстоит?
«Говоря о геймпадах умышленно были опущены замечания, что этому стандарту предстоит эволюционировать?» а какому web стандарту не предстоит?
опа, а че веб это не часть виндовс???? %)
Про WebPack забыли.
Спасибо за статью — это как раз то, о чем я думал последние 2 года, причем независимо от трендов, просто так совпали мысли и выбор перспективных технологий.
В разделе про API можно было бы еще упомянуть WebRTC, понятно, что Microsoft тут пока похвастаться нечем, но тем не менее :)
Microsoft и Apple не будут внедрять WebRTC по тем же причинам, что и WebP и WebM :)
Например, Microsoft решили вместо WebRTC имплементировать ORTC.
Например, Microsoft решили вместо WebRTC имплементировать ORTC.
У меня вопрос к kichik
Поясните пожалуйста почему в перечисляемых вами решениях ни разу не встречается Dart? Ваши тезисы стали бы полнее с его упоминанием:
1) Новый стандарт ECMAScript 6. Утверждение, реализация в браузерах, адаптация в сообществе и фремворках. — Dart поддерживает все то что ожидается в ECMAScript 6 уже сейчас(из самого вкусного поддержка классов и модулей).
2) Рост использования TypeScript в реальных проектах, развитие альтернативных проектов и их взаимное обогащение. — Да, рост наверное может получиться, а может не получиться. Как и у всех альтернативных проектов. Рост использования сильно зависит от богатства стандартной библиотеки, активности сообщества разрабатывающего сторонние библиотеки и возможностей простого использования уже существующих JS библиотек.
3) Развитие инструментов для кросс-платформенной разработки на JS, продолжение стирания границ между сайтами и приложениями. — Да, писать приложения на Dart для Apache Cordova и веб-сайтов тоже можно уже сегодня!
4) Рост умных телевизоров и консолей с разработкой на JavaScript, нативная разработка на JS на многих современных платформах (но не всех). — Dart транслируется в JS, а отладка на нем намного удобнее
6) Новые переработанные версии популярных библиотек, повышение входного порога для создания комплексных фреймворков, нишевые решения на базе ES6. — За счет стандартизованных требований к публикуемым модулям в Dart создание новых модулей и фреймворков упрощается, а их качество выше.
7) Адаптацию веб-компонент браузерами, принятие новых технологий разработчиками элементов управления и различных фреймворков. Polymer.dart — все работает уже сейчас в любом современном браузере
8) Принятие менеджеров пакетов и систем сборки для JavaScript в корпоративной и учебной среде, интеграция в популярные инструменты веб-разработки. — Darteditor содержит менеджер пакетов и систему сборки из коробки
11) Адаптация Node.js в корпоративной среде, адаптация нового ES6 в самом Node.js. Запасаемся попкорном и смотрим историю с форком io.js.- Dart позволяет писать серверную часть и отладка ее намного проще чем борьба с коллбэк хеллом в Node.js. Можете поискать как создатель Node.js отзывается о Dart.
12) Облачные решения для IoT на базе Node.js, новые экспериментальные проекты на клиентской стороне. — На Dart вы можете писать облачные решения для Google Cloud Platform. Т.е. на одном языке вы можете писать для Клиента, Сервера, Облака
Поясните пожалуйста почему в перечисляемых вами решениях ни разу не встречается Dart? Ваши тезисы стали бы полнее с его упоминанием:
1) Новый стандарт ECMAScript 6. Утверждение, реализация в браузерах, адаптация в сообществе и фремворках. — Dart поддерживает все то что ожидается в ECMAScript 6 уже сейчас(из самого вкусного поддержка классов и модулей).
2) Рост использования TypeScript в реальных проектах, развитие альтернативных проектов и их взаимное обогащение. — Да, рост наверное может получиться, а может не получиться. Как и у всех альтернативных проектов. Рост использования сильно зависит от богатства стандартной библиотеки, активности сообщества разрабатывающего сторонние библиотеки и возможностей простого использования уже существующих JS библиотек.
3) Развитие инструментов для кросс-платформенной разработки на JS, продолжение стирания границ между сайтами и приложениями. — Да, писать приложения на Dart для Apache Cordova и веб-сайтов тоже можно уже сегодня!
4) Рост умных телевизоров и консолей с разработкой на JavaScript, нативная разработка на JS на многих современных платформах (но не всех). — Dart транслируется в JS, а отладка на нем намного удобнее
6) Новые переработанные версии популярных библиотек, повышение входного порога для создания комплексных фреймворков, нишевые решения на базе ES6. — За счет стандартизованных требований к публикуемым модулям в Dart создание новых модулей и фреймворков упрощается, а их качество выше.
7) Адаптацию веб-компонент браузерами, принятие новых технологий разработчиками элементов управления и различных фреймворков. Polymer.dart — все работает уже сейчас в любом современном браузере
8) Принятие менеджеров пакетов и систем сборки для JavaScript в корпоративной и учебной среде, интеграция в популярные инструменты веб-разработки. — Darteditor содержит менеджер пакетов и систему сборки из коробки
11) Адаптация Node.js в корпоративной среде, адаптация нового ES6 в самом Node.js. Запасаемся попкорном и смотрим историю с форком io.js.- Dart позволяет писать серверную часть и отладка ее намного проще чем борьба с коллбэк хеллом в Node.js. Можете поискать как создатель Node.js отзывается о Dart.
12) Облачные решения для IoT на базе Node.js, новые экспериментальные проекты на клиентской стороне. — На Dart вы можете писать облачные решения для Google Cloud Platform. Т.е. на одном языке вы можете писать для Клиента, Сервера, Облака
Я думаю, если вы напишите статью «X трендов Dart в 2015г.», многим будет интересно почитать.
Всем комментариям в стиле «Dart крут! смерть js» хочется задать один вопрос: а есть ли вообще хотя бы один крупный проект на Dart? Кто его действительно использует? Если даже официальная страница дарта написана на классическом js и обфусцирована (либо дарт наконец научился генерировать простой js, а не 40 000 строк для хело ворлд).
Речь не идет о том, что язык программирования X — крут! смерть js
Суть комментария: смотрите, большинство того, что рассматривается как тренды 2015 года было доступно уже в 2014. Доступно для тех кто не увлекается религиозными войнам, страхами непрогнозируемого будущего и подбирает инструменты для разработки по принципу достаточности их функционала для решения реальных текущих задач.
Кто использует? — www.dartlang.org/community/who-uses-dart.html
Ну и реальные выгоды от использования Dart будут от командной работы над проектами несколько отличающимися по сложности от хело ворлд. И если на таких проектах у вас будут проблемы со скоростью загрузки приложения на современных каналах связи — в рамках языка есть функционал отложенной загрузки www.dartlang.org/docs/dart-up-and-running/ch02.html#deferred-loading
Суть комментария: смотрите, большинство того, что рассматривается как тренды 2015 года было доступно уже в 2014. Доступно для тех кто не увлекается религиозными войнам, страхами непрогнозируемого будущего и подбирает инструменты для разработки по принципу достаточности их функционала для решения реальных текущих задач.
Кто использует? — www.dartlang.org/community/who-uses-dart.html
Ну и реальные выгоды от использования Dart будут от командной работы над проектами несколько отличающимися по сложности от хело ворлд. И если на таких проектах у вас будут проблемы со скоростью загрузки приложения на современных каналах связи — в рамках языка есть функционал отложенной загрузки www.dartlang.org/docs/dart-up-and-running/ch02.html#deferred-loading
Практически все из этих трендов было доступно еще и до дарт, даже еще в прошлом тысячилетии. Взять тот же питон. Разве что он не очень распространен для веб-страниц (впрочем, есть транслятор).
В данном случае показаны тренды конкретно js. И очень приятно, что язык в последнее время бурно развивается и становится только лучше.
В данном случае показаны тренды конкретно js. И очень приятно, что язык в последнее время бурно развивается и становится только лучше.
«Рост использования сильно зависит от богатства стандартной библиотеки, активности сообщества разрабатывающего сторонние библиотеки и возможностей простого использования уже существующих JS библиотек.»
— эм, вы вообще представляете себе, что такое TypeScript? Все, что вы описали, это как раз проблемы Dart с его пропихиванием своей виртуальной машины поверх JS. TypeScript это и есть JS — BCL у него нет, сторонних библиотек тоже, потому что он сам JS и работает с либами JS как таковой.
«Dart транслируется в JS, а отладка на нем намного удобнее»
— а вы смотрели на пезультат транслитерации? А теперь сравните это с тем, что в TS результат транспиляции зачастую МЕНЬШЕ по объему, чем исходный код (еще до любых минификаций).
— эм, вы вообще представляете себе, что такое TypeScript? Все, что вы описали, это как раз проблемы Dart с его пропихиванием своей виртуальной машины поверх JS. TypeScript это и есть JS — BCL у него нет, сторонних библиотек тоже, потому что он сам JS и работает с либами JS как таковой.
«Dart транслируется в JS, а отладка на нем намного удобнее»
— а вы смотрели на пезультат транслитерации? А теперь сравните это с тем, что в TS результат транспиляции зачастую МЕНЬШЕ по объему, чем исходный код (еще до любых минификаций).
Про "… пропихивание виртуальной машины поверх JS" — все несколько не так. Происходит трансляция dart кода в js код после отладки и перед выкладыванием в продакшн. Чтобы этот JS мог работать в любом браузере. И в случае появления Dart VM в браузере трансляция уже не нужна, нативно можно выполнять dart скрипт. И он будет выполнятся примерно на треть быстрее чем транслированный JS. www.dartlang.org/performance/
> Поясните пожалуйста почему в перечисляемых вами решениях ни разу не встречается Dart?
Вероятно, потому что Dart мертворожденный проект, который никому не нужен даже в Гугле.
Вероятно, потому что Dart мертворожденный проект, который никому не нужен даже в Гугле.
Unity 5 с рендерингом в WebGL, развитие 3d и игровых библиотек, потенциальный прорыв через социальные сети.
На сегодня Unity3D до WebGL как надувной бабе до живой. Говорю не как противник юньки, а как человек, который видел другие движки, умеющие этот самый WebGL и, собственно — этот самый юнити со своим wgl. Прекратите, наконец, делать из юньки икону моды. Средство разработки хорошее, но не лучшее.
Маркетиниг у них хороший. В своей области не хуже, чем у Apple в своей. Наступает быстрее, чем успевают авторы средства разработки. Но есть и мнение, что никакого прорыва не будет. Кроме как канализационной трубы, по которой идет поток в мозг от маркетологов.
Если речь идет о плагине — производительность зависит от плагина.
Если речь о жизни «без плагинов» — чего вам накосячят в браузере авторы браузера, то там так и останется, какой бы крутой средой разработки не являлся «без плагиновый» движок.
У меня, например, хороший десктоп (i7 4770, Nvidia GTX 650 ti). В FireFox этот самый WebGL выдает ровно в 2 раза меньший FPS, чем в том же Chrome. А ведь есть еще и другие браузеры, которые имеют большую долю рынка. На мониторе 2560х1440 плагины рубят 3D в разы производительнее, чем этот преславутый WebGL. Кому такой WebGL нужен? Ну донатерам уж точно он не придется по душе.
Игры в социальных сетях: здесь все еще очень большое засилие Flash, но, возможно, если игры в Facebook и VK станут доступными в их мобильных приложениях, то это откроет второе дыхание для игр на HTML/JS.
Если компания делает Flash приложение для соц. сети — она не плюнет на годы разработки, чтоб сделать JS мобильное приложение из своей Flash или Unity игры — убожество на JS, которое упрется в Canvas. Они либо на нативе напишут его, чтоб получить производительность, либо портанут тот же браузерный Flash на мобильный Flash через Adobe AIR, чтоб сохранить максимальное количество кода.
Общался с заграничными компаниями, которые делают игры для соц. сетей. У них нет планов переходить на WebGL в ближайшие 2-3 года, если не случится революции в этом плане. А её не случится. Скорее новый формат взаимодействия появится.
Развитие инструментов для создания графики и анимации в рамках веб-стека. Традиционно (в смысле наследия от Flash) тут большое внимание стоит уделить продукции Adobe (Edge-семейство) и библиотекам, близким по духу к Flash и ActionScript, например, CreateJS.
Adobe Flash Professional CC чудесно умеет экспортировать контент в CreateJS. Тем более, что Adobe спонсирует разработку CreateJS как раз из-за того, что теперь из IDE можно контент под CJS собирать. А вот Edge-же работает с html dom.
Развитие API доступа к нативным возможностям устройства из JavaScript
С условем, что JS это JIT — будет не более, чем помигать фонариком (подсветка вспышки) и сделать фотографию с разрешения пользователя.
Рост умных телевизоров и консолей с разработкой на JavaScript
При росте % телевизоров увеличения мощности их процов, сопоставимой с требованиями современного контента — просто не будет. Соотв. там JS будет на том же уровне, как и сейчас. А торрент клиент на JS не напишешь, ведь.
Вчера крутил два разных смарт ТВ. Один LG и другой Phillips. На лыжах видео на сайте вообще во флеше запустилось, а в html5 даже не стартануло (не знаю по какой причине). На другом сайте html5 игра тормозила как черепаха.
У филипса чуток было лучше всё. Но без планшета, который как remote выступает — играть не удалось даже на уровне «получится или нет». В итоге, я просто пошел в Google Play, скачал нормальную игру не на JS и остался более довольным, чем от интимной близости с «высокими технологями» в телевизоре, где есть номинальный логотип html5.
Будущее
Я вижу лишь такое будущее у JS, которое ничем не будет отличаться от последних 2х лет.
Будут люди, которые продолжат писать
А потом, вместо адекватной работы — сидеть и наблюдать дикие лаги на планшете, т.к. 100500 фреймворков подключено (первый для определения размера экрана, второй узнает пользователь с мышкой или без, третий узнает версию браузера, четверый загружает эти все фрейморвки, пятный для работы с local store и т.д.). Извольте. Мне такого будущего не надо. Я это имею уже сегодня, вчера и позавчера.
В 2015 году желаю, чтоб JS стал просто как ActionScript 3.0 или Java. Это так же естественно хотеть, как маленькая девочка мечтает стать женщиной. А станет она вместо этого сельской бабой или куртизанкой — время покажет.
Торрент-клиент таки есть jstorrent.com/, вполне норм работает, хотя с файлами некоторых трекеров и не дружит.
Статья напомнила)
В хорошем смысле. Сам в 2015 делаю ставку на углубление знаний JS и инфраструктуры.
В хорошем смысле. Сам в 2015 делаю ставку на углубление знаний JS и инфраструктуры.
2. Типизированный JavaScript
Как раз недавно обсуждали плюсы и минусы статической типизации.
Есть у меня опасения, что TypeScript, Flow и пр. превратят JS в CSharp.
Ведь успех и гибкость JS в его:
а) простоте — всего 7 базовых операторов делают его привлекательным и комфортным для входа новичков, которые втянувшись начинают развиваться, что делает JS самым популярным;
б) свободе и демократичности — мы можем использовать подходы, наиболее подходящие как проектам, так и их отдельным частям.
Если обратить фокус на сам вопрос типизации.
Было бы интересно услышать преимущества статической типизации перед директивами в стиле jsdoc:
/**
* @param {object|object[]} recipients - one recipient or collection of them
* @param {string} message - message body
* @param {boolean} [system=false] - message type
*/
var sendMessage = function (recipients, message, system) {
// ...
};
/**
* @param {...string} parts
* @example
* var users = activeUsers.map(function (user) {
* return user['id'] + ":" + user["login"];
* });
* sendLog(“activeUsers: ", _users);
*/
var sendLog = function () {
// ...
};
Здесь я вижу явные преимущества директив перед статической типизацией:
Код будет работать «из коробки», без пре-процессинга.
Мы легко можем включать-отключать обработку директив.
Мы можем достаточно понятно описывать вариации параметров, структуру, значения по умолчанию, особенности их использования и т.д.
Смесь человеко-понятного текста позволяет создавать нам документацию внутри кода, что достаточно удобно, ведь главная проблема документации — её актуальность.
Мы имеем достаточно высокую читабельность — в IDE мы можем свернуть блоки с комментариями нажатием “горячей” кнопки и работать с самой логикой, скрыв мета-информацию. Это позволяет легко сфокусироваться на знакомом коде. При разработке крупных приложений, где логика первична, API знакомо, а команда боле-менее устоявшаяся — это важно.
В целом, директивы, как элементы изначально направляющие компилятор (вспомним хотя бы C++), а теперь пре-процессоры достаточно давнее и удобное явление.
К примеру, мы имеем большой проект и использовали jslint:
/*jslint vars: true*/
Но в какой-то момент решили переключиться на eslint.
Этот подход не обязывает нас рефакторить весь проект — мы просто меняем директивы в новых модулях и постепенно обновляет прошлые:
/*eslint eqeqeq:0, curly: 2*/
Тут мы замечаем важное качество — изолированность директив. Они не влияют друг на друга и могут обрабатываться в любом порядке. В то время, перенося контроль типов, как сервисную операцию, в надмножество языка и тем самым меняя язык (как в примере Flow, TypeScript и пр.), мы не можем так свободно и прозрачно их комбинировать и связываем себе руки.
Например, подход React создал необходимость появления JSX. Но как JSX будет сочетаться с TypeScript? Какой пре-процессор должен сначала пройти по исходному коду? И сочетаемы ли они вообще?
Мне кажется, было бы полезней развивать и перерабатывать jsdoc и пре-процессоры для его обработки, оставив языку свободу. В современном мире веб-разработки итак хватает проблем с интеграцией решений между собой и об этом я писал в своей недавней статье.
module math from «lib/math»;
Такое определение модуля выпилено из спецификации в октябре прошлого года.
Тренды какие-то прошлогодние, если честно.
Согласен с комментаторами, которые говорят, что JS всё больше будет походить на ActionScript. Если бы разработчики браузеров просто взяли бы документацию по AS3 и Flash API и реализовали бы их, то можно было бы сэкономить 5-10 лет бессмысленных метаний и велосипедостроения.
Но увы граждане будут биться головой об стену, а каждое продвижение вперёд выставлять, как эпохальное событие. Помню как пару лет назад мне доказывали, что классы и статичная типизация в JS не нужны. А теперь все с нетерпением ждут ES6.
Но увы граждане будут биться головой об стену, а каждое продвижение вперёд выставлять, как эпохальное событие. Помню как пару лет назад мне доказывали, что классы и статичная типизация в JS не нужны. А теперь все с нетерпением ждут ES6.
Компания майкрософт за последние годы подарила индустрии три версии браузера, каждая из которых имеет свои глюки, значительно тормозит и удорожает разработку веб приложений. Ох, не вам писать про тренды js 2015 года.
Вот и заканчивается 2015-й год… Что же из прогнозов в статье подтвердилось? И будет ли статья про 2016-й год?
Тут был спор про Dart, пришлось за год попробовать этот язык в разработке и честно признаться он мне весьма понравился. Есть сомнения, что он станет популярным, но обратить внимание на него все же стоит. Не буду тут расписывать интересные плюсы здесь, пост все же про js, но так вспомнился прошлогодний спор на тему. :)
Sign up to leave a comment.
Тренды JavaScript на 2015 год