Javascript умирает или перерождается?

Практика заворачивания в аспект — github.com/Meettya/clinch/blob/master/src/file_processor.coffee#L42

rejectOnInvalidFilenameType = (methodBody) ->
  (filename, cb) ->
    unless _.isString filename
      return cb TypeError """
                must be called with filename as String, but got:
                |filename| = |#{filename}|
                """
    methodBody.call @, filename, cb

<..somewhere in class...>

loadFile : (rejectOnInvalidFilenameType (filename, cb) ->
  <...method body...>
)

гиде гемор?

Javascript умирает или перерождается?

Ага, правда в половине случаев придется кастовать, потому что «ну так надо» и придумывать велосипеды, как бы эту проверку побороть.
И потом, если что-то не покрыто тестами и вылезло в деплое — ССЗБ.

Исчо раз повторяю — если нужна проверка типов — заверни в аспект. Если нужнен конкретный тип — заверни в аспект.

В 80% случаев мне нужна гибкость.
Обычно мои методы ловят массив или скаляр, который заворачивают в массив — вуаля, понятный интерфейс готов.
Хошь foo('bar'), хошь foo(['fizz','baz']).

Кроме того, вся эта магия с типами будет работать только внутри MS-го варианта. Как только ты сделал из своего кода либу и упаковал в JS — пуффф, магии больше нет. И отгруженная либа, которую вызывает кто-то еще в JS-е становится нифига не безопасна, а вот если все в аспектах было — все ок, аспект он и в Африке аспект.

Этож очевидный косяк.

Javascript умирает или перерождается?

Класс! Здорово сказано.

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

Почему вам стоит использовать TypeScript

А что именно под контрактом подразумевается?

Тестируем память с помощью Memtest86+ и VirtualBox

При таких объемах надо разводить руководство на че-то типа www.simmtester.com/page/products/sp3000/sp3info.asp или www.memorytesters.com/ и тестировать на потоке.

Тестируем память с помощью Memtest86+ и VirtualBox

ХМ… ИМХО тогда проблема скорее в менеджменте и програмно она точно не решается :) Да и аппаратно не все так просто :)

Тестируем память с помощью Memtest86+ и VirtualBox

Забавный метод, но ИМХО 4-8-портовый KVM надежнее. Они вменяемых денег стоят, если без наворотов.
Типа D-LINK DKVM-4K.

Будущие улучшения средств веб-разработки в Firefox

настроенный express под node,js + плагин LiveReload (который бесплатный) — и правь в любом редакторе хоть Coffee, хоть Stylus, хоть Jade :)

Простой упаковщик CommonJS модулей для использования в браузере — clinch

Done, v 0.2.9 в js варианте, правда из npm пакета я src не выкидываю никогда, потому как у меня тесты на него завязаны.

Простой упаковщик CommonJS модулей для использования в браузере — clinch

А… хм, как-то все время вылетает из головы, что не у всех npm install coffee-script -g :)

Точно, перепакую сегодня, спасибо за напоминание.

Простой упаковщик CommonJS модулей для использования в браузере — clinch

И в конце концов справедливость восторжествовала — how to use Handlebars with clinch.

Надеюсь окажется полезным и мой спам еще не задолбал :)

Простой упаковщик CommonJS модулей для использования в браузере — clinch

Хм. Итожя:

Как и грозился — API кастом-процессоров теперь есть.
Неожидано — Handlebars не будет, авторы перемудрили с предкомпиляцией и я его прикрутить тупо не смог :)

Хотя, может у кого-то с API теперь и получится.

Простой упаковщик CommonJS модулей для использования в браузере — clinch

Good news for everyone! ©

API для сторонних обработчиков будет, постараюсь сегодня выкатить до вечера.
С примером как прикручивается Handlebars.

Простой упаковщик CommonJS модулей для использования в браузере — clinch

Ну, с clinch по идее должно сработать :)

Просто в node немного не так

Да, но делать так же в браузере — получишь ровно то, что туда положил — смысла как мне кажется никакого.
Я вот даже как-то и не знал, что она (node) так себя ведет :)

Простой упаковщик CommonJS модулей для использования в браузере — clinch

Посмотрел повнимательнее — Handlebars — вроде бы несложно, возможно добавлю в поддерживаемые шаблонизаторы.
С dust как-то мутновато, там идея немного не по формату такой компиляции, так что пока фик знает.

Простой упаковщик CommonJS модулей для использования в браузере — clinch

Странно, на живой пример можно посмотреть?

Вообще-то код модуля вызывается в контексте глобали, т.е. this.jQuery должен найтись, если он в глобали есть.
Пруфф — здесь и ниже.

Иначе пустышка бы из примера выше не сработала бы.

Ну, т.е. надо до бандла просто подгрузить на страницу jQuery и все должно сработать.

Простой упаковщик CommonJS модулей для использования в браузере — clinch

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

Простой упаковщик CommonJS модулей для использования в браузере — clinch

Контейнер примерно так выглядит — di_container.coffee.
Правда это навороченный вариант, с само-разрешением зависимостей, но идея именно такая.

Простой упаковщик CommonJS модулей для использования в браузере — clinch

они загружаются во время загрузки

Может быть в вашем смысле это чем-то оправдано, но в общем случае динамический require — это ммм… плохая идея.
Во-первых он очень синхронный — там куча всего под капотом происходит с суффиком Sync.
Во-вторых, потому что что-то надо было что-то делать с во-первых — он кеширует все вещи, которые были запрошены, в результате фактически в экземпляре процесса висят все штуки, которые были разрешены.

ИМХО лучшее, что тут можно сделать — сделать контейнер, который будет статически рекверить все, и отдавать отдельные элементы по имени. И подключить этот контейнер в код.

А можно у вас делать синонимы

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

А как включить jquery в бандл

Как бы идеологически использованиеи именно бандлов, а не какого-то app связано с тем, что clinch скорее аналог component, в том смысле что с его помощью можно делать маленькие виджеты, или кучу разных мелких хелперов. Если надо завернуть целый app — тут overhead не так страшен.
Поэтому немного неверно включать большие либы в бандл, их можно грузить отдельно, или, что правильнее — брать из CDN, а в бандле делать «пустышку», типа такой.

###
This is lodash shim
###

module.exports = @_

Простой упаковщик CommonJS модулей для использования в браузере — clinch

Он не «просто парсит страницы», он смотрит в сгенерированный AST кода на предмет наличия лексемы require.

У меня есть в коде например, что то типа такого

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

Для списка файлов и директорий clinch вряд ли подойдет — основная фишка как раз и была в нативной поддержке vanilla CommonJS из коробки, бо mocha.