Если использовать webpack — это очень удобно. А потом есть куча модулей, которые можно использовать как на клиенте, так и на сервере, зачем тогда остальные разделять?
npm хорошо бы допилить напилником, чтобы main директива была более кастомная и будет просто замечательно.
Есть еще допустим apm — пакетный менеджер для Atom. Все пакеты под него публикуются в npm, и они вполне могут использовать jquery (и кстати используют), или иконки.
Фактически помимо серверной части и браузерной есть промежуточная, для nw.js/atom-shell/native-script/react-native и тому подобных, которые имеют доступ как к node-api (io) так и браузерному (dom). Для такого использования лучше npm ничего быть не может.
Библиотека — да. Если вы пишите библиотеку для работы с AE, а я захочу ее использовать — мне совсем не весело будет за вашей библиотекой еще и jquery тащить, ради его API.
Вообще не понимаю, при чем тут jquery может быть, давайте в pdf.js jquery добавим
Я бы еще поспорил с тем как делают, на coffee почти забили, посмотрите на то, с какой скоростью развивается babel.
В babel можно отключать некоторые преобразования, таким образом не обязательно использовать все его возможности и например для iojs можно вообще половину отключить (let, const, arrow-function и еще пачку)
Поправляйте, или нет, вы ставите в жесткую зависимость от jquery, достаточно серьезную библиотеку. А я изначально написал — мечтаю о том дне, когда это закончится. На jquery свет клином не сошелся, стандартный js куда богаче, чем раньше, есть полифилы и куча маленьких модулей, отлично решающих свою задачу. jQuery тут не нужен.
jQuery — god object. И похоже вам это нравится, потому что вы хотите на него навесить еще больше ответственности.
Если мне нужно работать математическими преобразованиями — я напишу себе такую библиотеку, или возьму существующую. Со слоями в AE — аналогично. Это отдельный сервис, никак не связанный с jquery.
А по поводу прототипов — угу, не хорошо, но в качестве исключения для стандартных методов, вроде map, filter, trim и тд норм. Кому совсем припекает — lodash, хотя на мой взгляд стандартную функциональность лучше просто оборачивать в полифил.
Промисы можно и с coffee юзать, все что делает babel в плане стандартной библиотеки — подрубает core-js, а это набор полифилов, который можно подключить и в coffee.
А в целом — полностью согласен.
Тем, что в один прекрасный, светлый момент можно будет убрать babel. С coffee такого сделать никогда не получится.
Ну и естественно новые фишки, yield только-только поддержали в coffee, async-await судя по всему будет только в форке. Модули не понятно, будут или нет.
Какой-то вы бред говорите. Когда скачиваешь билд библиотеки как раз не понятно что туда входит. А если используешь npm/bower — сразу видно зависимости.
Сейчас и в jquery компонентах куча повторяющегося кода. Полифилы новых функций, целые либы, обычно они достаточно маленькие, но все равно.
В node мире все становится лучше — компоненты стараются переиспользовать другие компоненты, вот того же хотелось бы и в браузерном js.
Да уже есть polymer, angular, react. Не знаю как polymer, но найти под angular кучу необходимых компонентов практически не реально. Банально большинство wysiwyg требуют jquery. Или select2-подобных плагинов.
Странно в 2015 году восхваление jquery, если честно. Хочется наоборот, чтобы библиотека отправилась быстрее на покой, а все плагины вокруг были переписаны нативно.
Да, это интересно. Спасибо за развернутый ответ, надо будет посмотреть на dart внимательней. А все эти вещи выполняются в рантайме? Вопрос следует из слухов о огромном рантайме, который тянет за собой даже helloword.
Мне не понятно одно — если AtScript удалось вмержить в typescript, почему то, что не хватает в TS, а есть в dart также не добавить в TS и все? Зачем еще один язык, тем более транслируемый?
Вы про нейросети слышали? Слышали, что люди, создающие их не в состоянии точно объяснить, как в итоге сеть выбрала именно этот результат, при условии достаточно большого кол-ва факторов? Например современные поисковые системы.
А теперь представьте, что ИИ — это нейросеть, работающая не на одну конкретную область, а вообще на все что угодно. То есть предсказать поведение такой программы тем более невозможно.
npm хорошо бы допилить напилником, чтобы main директива была более кастомная и будет просто замечательно.
Есть еще допустим apm — пакетный менеджер для Atom. Все пакеты под него публикуются в npm, и они вполне могут использовать jquery (и кстати используют), или иконки.
Фактически помимо серверной части и браузерной есть промежуточная, для nw.js/atom-shell/native-script/react-native и тому подобных, которые имеют доступ как к node-api (io) так и браузерному (dom). Для такого использования лучше npm ничего быть не может.
Вообще не понимаю, при чем тут jquery может быть, давайте в pdf.js jquery добавим
В babel можно отключать некоторые преобразования, таким образом не обязательно использовать все его возможности и например для iojs можно вообще половину отключить (let, const, arrow-function и еще пачку)
Чем такой метод не подходит?
Если мне нужно работать математическими преобразованиями — я напишу себе такую библиотеку, или возьму существующую. Со слоями в AE — аналогично. Это отдельный сервис, никак не связанный с jquery.
А по поводу прототипов — угу, не хорошо, но в качестве исключения для стандартных методов, вроде map, filter, trim и тд норм. Кому совсем припекает — lodash, хотя на мой взгляд стандартную функциональность лучше просто оборачивать в полифил.
А в целом — полностью согласен.
Ну и естественно новые фишки, yield только-только поддержали в coffee, async-await судя по всему будет только в форке. Модули не понятно, будут или нет.
Не надо. Лучше посмотрите в сторону ES2015 babeljs.io.
В node мире все становится лучше — компоненты стараются переиспользовать другие компоненты, вот того же хотелось бы и в браузерном js.
А теперь представьте, что ИИ — это нейросеть, работающая не на одну конкретную область, а вообще на все что угодно. То есть предсказать поведение такой программы тем более невозможно.