Для ES6-to-ES5, согласен, что лучше использовать отдельные трансляторы, которые, к тому же, и работают быстрее. Sweet.js в его текущем виде больше подходит, когда вам нужно сделать «по-быстрому» несколько синтаксических расширений под свой проект/библиотеку/фрэймворк.
Про отладку — надеюсь браузеры этому смогут научиться.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Кроме того, у идея работать с POJSO есть свои минусы — если мы захотим по рабочему приложению получить слепок данных, чтобы их сохранить, например, — нам понадобится в каждый компонент добавить метод для экстракции этих данных из state. Посмотрите на исходники TodoMVC, там, чтобы этого избежать, пришлось все изменения делать внутри одного компонента (TodoApp), что тоже дурно попахивает, если мы говорим об архитектуре.
Чуть-чуть по-другому, то что весь state содержится в одном компоненте — это наоборот хорошо, а не плохо. Благодаря этому у нас всего один компонент, который содержит изменяющееся состояние, остальные без состояния и поэтому зависят только от своих аргументов (props в терминологии React).
Почему компоненты без внутреннего состояния это хорошо, я думаю, это понятно. Если нет — могу более подробно объяснить.
Хочу также опередить возможный контраргумент и уточнить, что в данном случае Single Responsibility Principle не нарушается — компонент отвечает только за один кусочек данных — список todo items.
Ну и никто не мешает использовать React со всяким «сахаром» для моделей — FRP штуки, Backbone.Model и прочее.
Если есть монада, то можно взять то, что внутри неё и создать из этого другую монаду
Теперь подставляем вместо слова «монада» конкретный тип данных, с которым мы работает — Maybe/Option, Promise/Future или что-то там ещё и забываем про монады. :p
headless — React позволяет ренерить UI на сервере. Он использует Virtual DOM вместо браузерного DOM для построения UI, из-за этого компоненты можно рендерить не только в бразуере, но и внутри Node.js (или любого другого js-рантайма) и Web Worker'а и для этого даже не потребуется бажный и медленный jsdom. Если интересно — можно посмотреть на react-app, набор утилит для рендеринга полностраничных (которые рендерятся прямо в document.documentElement) компонент c помощью React.
2-way bindings — реализуется поверх в десяток строчек кода, но и этого не нужно делать, так как есть уже готовая утилита — ReactLink. Вообще, 2-way bindings имеют довольного ограничинное применение, формочки в основном, поэтому не думаю, что это очень важный пункт сравнения.
rich reactive list — абсолютно не важно для React, так как он работает с Plain Old JavaScript Objects, да-да, не стоит заморачиваться и моделировать данные с которыми вы работаете в каких-то observables и прочим.
template based — для React есть JSX, который позволяет описывать React компоненты привычным HTML синтаксисом, который имеют очень простую семантику компиляции, например <div>Hello</div> превращается в React.DOM.div(null, 'Hello')
Максим, никто не отрицает право инвесторов знать и контролировать куда тратятся деньги — для этого есть к акционерное соглашение. В данном случае, некоторые инвесторы решили выйти за рамки этого соглашения и поиграть в 90-ые.
Цитата вырвана из контекста, у нас в компании регулярно проходят (проходили теперь уже) лекции на разные темы, как профильные по разработке, дизайну, так и непрофильные — от архитекутры до нейропсихологии. Данное эссе — это текст из приглашение на одну из непрофильных лекций, по-моему, по нейропсихологии. Ничего криминального в этом нету и конечно же посещение этих лекций не было обязательным.
Про отладку — надеюсь браузеры этому смогут научиться.
«Pony ORM can be used under one of the following licenses:
— Open source project: GNU Affero General Public License 3.0»
Я думал мы знаем, что обсуждаем.
Код нужно будет сделать открытым всем.
Как это позволит удовлетворить условиям GPL?
Чуть-чуть по-другому, то что весь state содержится в одном компоненте — это наоборот хорошо, а не плохо. Благодаря этому у нас всего один компонент, который содержит изменяющееся состояние, остальные без состояния и поэтому зависят только от своих аргументов (props в терминологии React).
Почему компоненты без внутреннего состояния это хорошо, я думаю, это понятно. Если нет — могу более подробно объяснить.
Хочу также опередить возможный контраргумент и уточнить, что в данном случае Single Responsibility Principle не нарушается — компонент отвечает только за один кусочек данных — список todo items.
Ну и никто не мешает использовать React со всяким «сахаром» для моделей — FRP штуки, Backbone.Model и прочее.
Теперь подставляем вместо слова «монада» конкретный тип данных, с которым мы работает — Maybe/Option, Promise/Future или что-то там ещё и забываем про монады. :p
P.S. Когда тут уже markdown сделают?
document.documentElement) компонент c помощью React.<div>Hello</div>превращается вReact.DOM.div(null, 'Hello')