Анджей Гужовский: Riot.JS, или как приготовить современные Web Components
Wiki Tag: js
Vue.js
Я могу подтвердить, что two-way binding иногда не так прост и не так читабелен, но большинство из этих страхов связаны с общим страданием людей от первой версии Angular, где двусторонняя привязка была, может быть, не самой лучшей. И все же… это, вероятно, не было самым большим просчетом даже в Angular. Посмотрите на мой быстрый редактор, который я накостылил недавно с Vue.js для нашей платформы на Drupal (заранее прошу прощения за дизайн, это бэкенд UI для наших операторов, а дизайнеры заняты, создавая интерфейсы для наших клиентов, так что этот кусок функционала ждет своего часа, чтобы стать красивым):
Почему мы выбрали Vue.js (а не React)
Почему мы выбрали Vue.js (а не React)
Мы решили использовать Vue.js после того, как построили тестовое приложение c идентичным функционалом – наш калькулятор — на React, Vue.js и Angular2.
React.js
Популярность React взлетела до небес за последние год-два, и теперь, пожалуй, это выбор по умолчанию для JS разработчика, который хочет написать на фронтенде что-то сложнее трехстрочного абзаца кода.
Мы запилили несколько SPA и динамических виджетов на React, мы тестировали React Native (под iOS) и Redux. Я думаю, что React был большим шагом для мира JS с точки зрения осведомленности о состоянии, и он показал многим людям, что такое реальное функциональное программирование в хорошем, прагматичном ключе. Также я думаю, что React Native велик – он буквально меняет весь ландшафт мобильной разработки.
Читать дальше
WebAssembly как киллер фича, и возможный убийца 2D Canvas
я не удивлюсь если выход в массы этой технологии в связке с “Unity”подобными движками – оставит далеко позади фронтенды построенные на канвасе в плане быстродействия = комфортности работы пользователя.
технологии на самом деле редко становятся киллер фичей ПО. но, бывает. и WebAssembly для задач где только канвасом рисовать – может оказаться именно такой.
уже сейчас для таких задач надо использовать asm.js, и, минимум, морально готовится к выходу WebAssembly
Читать дальше
React.js
Серьезно не копал, но кажется React может стать прекрасной заменой Backbone.js. Потому что подход в использовании схож. Дизайн внутренностей совсем другой, да.
но Почему мы выбрали Vue.js (а не React)
И подчеркну, они оба НЕ фреймворки, а View библиотеки. Это минус, если нужно сложное веб приложение, и плюс – если надо к сайту добавить UI, и не перелопачивать весь фронтенд ради этого. А Angular.js и Ember.js – заставят 
Javascript-фреймворки
Javascript-фреймворки – это круто. Очень. И – больно.
И эти тысячи фреймворков, каждый из которых как две капли воды зачастую похож на друг друга, особенно во flux фреймворках — это прямо «придумай свое название точка JS». И из этого ада там, где Google Web Toolkit уже давно умер, надо как-то выбрать. Блин, что делать? Конечно, надо было что-то подумать, как бы посмотреть, как другие где-то что-то выбирают в Интернете, залезть и где-то спереть результат.
Хабр: Javascript-фреймворки: должен остаться только один
Qooxdoo
Забытый, но живой фреймворк, из старого поколения. В котором была предпринята попытка полностью уйти от работы с HTML, и работать с web UI как с привычным GUI.
Qooxdoo. Разрабатываем TODO List
Из старого поколения еще можно назвать Dojo Toolkit. Но он более сложный, чем Qooxdoo, и не такой GUIевый.
Can.js
Сравнение Angular, Backbone, CanJS и Ember
Итоговая табличка из статьи
| Оценки | Angular | Backbone | CanJS | Ember |
|---|---|---|---|---|
| Функции | 5  |
2 |
4 |
5 |
| Гибкость | 3 |
5 |
4 |
3 |
| Порог входа и документация | 2 |
4 |
5 |
3 |
| Продуктивность разработки | 4 |
2 |
4 |
5 |
| Сообщество | 4 |
5 |
3 |
4 |
| Ecosystem | 4 |
5 |
2 |
4 |
| Размер | 4 |
5 |
5 |
2 |
| Производительность | 3 |
4 |
5 |
4 |
| Зрелость | 4 |
5 |
4 |
3 |
| Защита от утечек памяти | 5 |
3 |
5 |
5 |
| Сумма | 38 | 40 | 41 | 38 |
Knockout.js
Мнения с Хабра
Лучше Knockout-а вряд ли что-то можно придумать.
AngularJS?я бы на их месте использовал бы html5 атрибут data все таки не зра его вводят, вместо своего ng
Ну, там есть такая возможность: data-ng- вместо ng-
Но сути это не меняет — Нокаут лучше из-за самого сильного механизма observables. Я могу иметь наблюдаемое проперти, которое в свою очередь возвращает в качестве значений другой наблюдаемое проперти. Причем, все они могут быть зависимыми без указания мной явных цепочек зависимостей.
Но и для многих аспектов Нокаут предоставляет гораздо более удобное и лаконичное API. Те же кастомные байндинги в Нокауте делаются одной или двумя функциями, а в angular готового рецепта нет.
Соглашусь. Многие теряют из виду тот факт, что темплейты Нокаута остаются валидным HTML-кодом, а значит их может править верстальщик или дизайнер без оглядки на синтаксис разработчиков. Тем более, с учетом того, что в большинстве случаев темплейты инлайнятся в текст страницы, а не прячутся в script тагах, темплейты верстальщик может править непосредственно по готовому живому HTML прямо из браузера.
Backbone.js
Backbone — не фреймворк, это библиотека.
Backbone is a library, not a framework, and plays well with others.
Статьи от Gaperton`а (Vlad Balin)
Backbone.js on Steroids
Posted on 2014.06.24 at 23:33
Расскажу, пожалуй, про старую тему – разработку одностраничных JS-приложений. С тех пор, как я послежний раз об этом писал, прошло много времени – наверное, года 3. И с тех пор много чего изменилось. Появилось множество разных JS фреймворков, в моду вошел two-way databinding.
Однако, мэйнстримом (примерно 40% применений) на данный момент является Backbone.js, работающий в связке с jQuery и Underscore.js. Причиной этого, возможно, является его простота. Backbone прост в том смысле, что ему достаточно легко обучить команду, собирающуюся писать одностраничное приложение, и не имеющую в этом опыта. Это безусловный плюс backbone (как и его популярность), однако, его минусом является то, что он слишком прост. То есть, на голом backbone не так просто сделать что-то, кроме совсем простого.
вся статья
Допустим, у нас есть группа разработчиков на PHP, которые знают чуть чуть JS и jQuery. Что самое простое мы можем сделать, чтобы начали писать браузерное приложение, и были продуктивны немедленно?
Мы можем попробовать использовать тот же принцип, и те же архитектурны правила, к которым они привыкли в PHP. У них были шаблоны с встроенным PHP? Отлично, мы будем использовать такие же шаблоны со встроенным JS, которые будут разворачиваться в браузере. Они использовали jQuery? Отлично, мы сохраним jQuery.
Нам остается задать этому какую-то структуру. Элемент UI – это будет объект View с присоединенным DOM-элементом, и методом ‘render’, который должен разворачивать шаблон в присоединенный элемент. Помимо этого, View должен уметь перехватывать события UI, и вызывать свои методы.
4. BackboneJS
Кому-то могло показаться после прочтении предыдущей статьи, что мне “просто нравится бэкбон“, или что я считаю его лучшей в мире технологией. Это не так. Мы начали с backbone по двум причинам: (1) многие с него начинают, и (2) это, пожалуй, минимально возможный фреймворк для браузерных приложений.
5. Backbone Sucks
Marionette и Chaplin — фреймворки, которые работают поверх популярной библиотеки Backbone.js. Оба хотят облегчить разработку одностраничных JS-приложений. В таких приложениях, фронтэнд выполняет задачи, которые в прошлом выполнялись на сервере (вроде рендеринга HTML из данных).
Бэкбон спроектирован, как минималистичная библиотека, а не как полноценный фреймворк. Мой опыт показал, что Бэкбон хорош только как ядро архитектуры JS-аппликейшна. И Марионетка, и Чаплин появились, потому что Бэкбон предоставляет мало структурирования для реальных приложений. Они решают те же проблемы. Так что между ними довольно много сходств — возможно, даже больше, чем отличий.
хабр: MVC-фреймворки на JavaScript: сравнение Marionette и Chaplin
JsRender
http://www.jsviews.com/#jsrender
Хабр: JsRender: Новое поколение jQuery Templates
Использование JsRender с JavaScript и HTML
Более сложная функциональность шаблонов JsRender
P.S.
с Хабра
Шаманство всё это. Плагин для jQuery без jQuery, под который нужно учить отдельный синтаксис.
Лучше Knockout-а вряд ли что-то можно придумать.
Node.js
Теоретически очень перспективная платформа.
По эффективности работы в рантайме – иногда лучше даже Джавы. Да и по скорости создания простых REST приложений.
Но, согласен с выводами в После года использования NodeJS для разработки
Я потратил год, пытаясь заставить JavaScript и более специфичный Node работать на нашу команду. К сожалению, за это время мы потратили больше часов на поиск документации, знакомство со «стандартами», споры о библиотеках и отладку тривиального кода, чем на что-то полезное.
Посоветовал бы я Node для больших проектов? Абсолютно нет. Будут ли люди использовать его всё равно? Конечно будут. Я тоже пытался.
Вполне возможно вы удивлены, что я делаю сейчас? Сейчас я продолжаю писать главные части наших продуктов и API, используя Python.
Два столпа JavaScript: функциональное программирование
Почтенный мастер Ку Чи шел со своим учеником, Антоном. Надеясь вступить с мастером в дискуссию, Антон сказал: «Учитель, я слышал, что объекты это очень хорошая вещь — это правда?» Ку Чи с сожалением посмотрел на своего ученика и ответил: «Мой глупый ученик, объекты — это замыкания для бедных.» Антон поклонился и вернулся в свою келью изучать замыкания. Он внимательно прочитал всю серию работ «Lambda: The Ultimate…», потом все остальные статьи по этой теме, и создал небольшой интерпретатор с использованием объектов эмулирующих функционал замыканий. Он многому научился, и стал искать встречи с мастером, чтобы похвастатья. На своей следующей прогулке с Ку Чи, Антон сказал: «Учитель, я усердно изучал этот вопрос, и теперь понимаю, что объекты действительно являются замыканиями для бедных.» Ку Чи ударил Антона своей палкой и сказал: «Когда же ты научишься? Замыкания — это объекты для бедных». В этот самый момент Антон достиг просветления.
Читать дальшеДва столпа JavaScript: наследование через прототипы
«Проблема объектно-ориентированных языков в том что они тащут за собой всю неявную среду. Вы хотите получить банан, но кроме банана в нагрузку получаете гориллу, и все чертовы джунгли!». ~ Джо Армстронг
Читать дальше