Компания Facebook сообщила (https://github.com/facebook/react/issues/10191#issuecomment-...), что не имеет возможности отказаться от применяемой ныне лицензии BSD с дополнительным соглашением (https://github.com/facebook/react/blob/master/PATENTS) об использовании патентов ("BSD+Patent"). Представители Facebook пояснили (https://code.facebook.com/posts/112130496157735/explaining-r.../), что отказ от текущего текста приложения о патентах приведёт к ослаблению защиты от патентных троллей и увеличению ресурсов, которые придётся тратить на отражение необоснованных патентных исков.
Напомним, что в прошлом месяце Фонд Apache добавил "BSD+Patent" в список (https://www.apache.org/legal/resolved#category-x) несовместимых лицензий, код под которыми не разрешается использовать в проектах Apache. До 31 августа проектам Apache предписано избавиться от зависимостей под лицензией "BSD+Patent", таких как JavaScript-фреймворк React (https://github.com/facebook/react), применяемый в том числе в Apache CouchDB. Как вариант выхода из сложившейся ситуации Facebook было предложено (https://github.com/facebook/react/issues/10191) перелицензировать код React под более современной лицензией Apache 2.0, которая близка к используемой в Facebook связке и включает пункты для минимизации рисков от патентных исков (лицензия отзывается в случае патентного иска против создателя открытого кода).
Facebook указывает, что патентное дополнение, в котором фонд Apache усмотрел несбалансированное перекладывание рисков на потребителей продуктов, является ценой текущей политики открытости, при которой Facebook пытается развивать в качестве открытого ПО по возможности все свои программные и аппаратные проекты. К сожалению, такая большая компания как Facebook является привлекательной целью для различных патентных исков, и компания не готова отказаться от текущего варианта патентного соглашения как дополнительного рубежа защиты. В текущей ситуации Facebook не может сменить лицензию, не подставляя себя под удар необоснованных судебных исков.Facebook подчёркивает, что ограничения, касающиеся связки "BSD+Patent" внесены только во внутренние правила Фонда Apache и затрагивают только проекты данной некоммерческой организации. При этом связка остаётся полностью совместимой с лицензией Apache 2.0 и проектами на её основе, развиваемыми не под эгидой Фонда Apache. Ранее в черный список Фонда Apache также были добавлены такие лицензии, как GPL, AGPL, LGPL и BSD-4-Clause.
URL: https://code.facebook.com/posts/112130496157735/explaining-r.../
Новость: http://www.opennet.me/opennews/art.shtml?num=47051
А теперь экспертам остается лишь говорить: "Фейсбук использует апачевские проекты, пострадает лишь фейсбук, апачу ничего, а вот фейсбуку скоро кирдык, надо только подождать, надо только подождать, ...".while (true) {
println("надо только подождать");
}
while (true) {
printf("надо только подождать, ");
}
while (true) {
printf("надо только подождать, ");
sleep(100*365*24*60*60);
}
на кой нужна эта failbook'овская печалька, когда есть vue ?https://cdn-images-1.medium.com/max/1600/1*aih3tU-cP43tiBy3QM5PYA.png
Можно с уверенностью сказать в обратном порядке.
vue не типобезопасен. Не, какой-нибудь хелловорлд на нескучном имплисит рефлекшн интроспекшн API проекты писать -- самое то. Но вот как только пытаешься весь их нескучный апи организовать в терминах статической типизации -- так все. Поэтому vue, несмотря на его симпатичность, годится исключительно для хелловорлдов и туду-мвц-демо. В энтерпрайзе серьезных конкурентов реакту пока нет.Как пример: суешь ему на вход массив (экземпляр Array), а он над ним шаманит при помощи рефлексий, чтоб отслеживать каждый push/pop. Ну куда это годится? Суешь одно -- а он его мутирует наhUI. У прикладников и так своих проблем полно, а тут еще какие-то странные правила вида "это сюда object.hello = 'world' не присваивай, а присваивай через $set(object, 'hello', 'world')". Деды дали нам паттерны, IObservableValue/DataBindingContext и прочие хорошие штуки. Но нет. Не хотим паттерны. Хотим жрать рефлексии/интроспекции.
Но повторюсь: идеальнее vue для хелловорлда фреймворка не найти. Сам иногда использую в пет-проектах.
Ы, какое отношение имеет типобезопасность к фреймворку ? Это какбэ к javascript претензии выражать надо - т.е. в центральную прачечную. нужна статика, есть куча приочек или тот же typescript
> Ы, какое отношение имеет типобезопасность к фреймворку ? Это какбэ к javascript
> претензии выражать надо - т.е. в центральную прачечную. нужна статика, есть
> куча приочек или тот же typescriptТак а я о чем? React+typescript возможен, успешно практикуется в тырпрайзе. Vue+typescript невозможен в силу ущербности апи vue. Все ссылки на эту связку, которые ты приведешь, настолько сыры, что и на хелловорлдах придется ногу сломить.
ну ну салянка с бабелем и тайпскрипт удачи.
TypeScript из коробки поддерживает JSX (см. TSX) и имеет лодеры для вебпака. Зачем Babel?
js и типобезопасность в одном предложении - это результат употребления наркотических веществ или просто шизофрения.
Я всегда знал что реактом с jsx пользуются только идиоты и/или школьники. Ну и да, реализация через врапер свойств нужна для поддержки старых браузеров в которых нету Proxy. Это в любом случае лучше реакта, который либо обновляет весь DOM на каждый чих, либо юзает пачку костылей чтобы угадать что реально нужно изменить в DOM. Вот такая вот безопасность типов по реакту. А ещё реакт заставляет писать на смеси жс и хтмл и его фактически нельзя юзать с другими языками, где есть реальная "типобезопасность".
> жс и хтмл и его фактически нельзя юзать с другими языками, где есть реальная "типобезопасность".Опровергну тебя тремя буквами: tsx.
> Опровергну тебя тремя буквами: tsx.И так для каждого языка своя реализация: language + sx. Очень классное решение.
>> Опровергну тебя тремя буквами: tsx.
> И так для каждого языка своя реализация: language + sx. Очень классное
> решение.Исключительно для сахара. Можно и без jsx/tsx прекрасно обходиться, юзай вместо <div/> какие-нибудь React.createElement('div'). Сам же потом и попросишь сахар. (На самом деле не попросишь, ибо дальше хелловорлдов у такого типичного опнетовского иксперта как у тебя дело не пойдет.)
>Исключительно для сахара. Можно и без jsx/tsx прекрасно обходиться,Да, для этого есть нормальные темплейты
>>Исключительно для сахара. Можно и без jsx/tsx прекрасно обходиться,
> Да, для этого есть нормальные темплейтыТеймплейт -- это функция вида input => string. Значит чтобы организовать Virtual DOM, придется заново парсить то, что нагенерировал темплейт, чтобы определить, что же реально изменится в DOM. Очень разумно, да. Может сразу делать body.innerHTML = renderEverything() на каждый ховер?
Какой только херни не напридумывают прикладушники, лишь бы не работать. А вообще
обожаю слушать срачи ООПэников. 99% рабочего времени разбираются как работают их
фреймфорки иль как там называете терабайты говна из JS/PHP/RUBY/и прочего отстоя.
Илитка в треде, все в укрытие
> обновляет весь DOM на каждый чихУчите матчасть, гражданин хелловорлдщик. Писать в гугле Virtual DOM, нажать Enter, с помощью устроиства типа "оптическая мышь" кликать по найденным статьям, используя школьные знания о русском или английском алфавите -- читать по слогам найденные статьи.
> Учите матчасть, гражданин хелловорлдщик. Писать в гугле Virtual DOM, нажать EnterТы бы сам разобрался, например доки по реакту прочел, узнал бы про shouldComponentUpdate. И да, первая версия vue прекрасно обгоняла реакт по перформансу и без шадоу дома :)
> shouldComponentUpdateВсяко лучше, чем автомагические угадывания с патчингом входных аргументов и с рефлекшн/интроспекшн, где если чуть что-то перестает работать -- надо дергать за issues того японца, где он пояснит, что object.hello делать не нада, а нада $set. Даже входной массив очистить по-человечески нельзя, надо какие-то __$__-методы дергать.
> прекрасно обгоняла реакт по перформансу и без шадоу дома :)
Обгоняла? Сейчас уже не обгоняет значит? Если что -- меня не особо интересуют бенчмарки, но раз когда-то обгоняла, а сейчас нет -- тем хуже для vue. API проектировать надо нормально, с четкими интерфейсами, без каких-то там "называть входные ключи начиная со знака доллара не нада, испорчу вам объект своими __$__-методами".
>> shouldComponentUpdate
> Всяко лучше, чем автомагические угадывания с патчингом входных аргументов и с рефлекшн/интроспекшн,
> где если чуть что-то перестает работать -- надо дергать за issues
> того японца, где он пояснит, что object.hello делать не нада, а
> нада $set. Даже входной массив очистить по-человечески нельзя, надо какие-то __$__-методы
> дергать.А просто почитать доки не судьба? У вью всё предсказуемо, у реакта - нет. Или ты один из тех кто доки не читает и сразу в баг трекер постишь "у меня ни работает"?
>> прекрасно обгоняла реакт по перформансу и без шадоу дома :)
> Обгоняла? Сейчас уже не обгоняет значит?И сейчас обгоняет, просто шадоу дом к этому не имеет отношения.
> А просто почитать доки не судьба?А просто вменяемые интерфейсы оформить не судьба? Какого х, скажите на милость, в объект добавляются х з откуда взявшиеся методы $set & c. ?
> сразу в баг трекер постишь "у меня ни работает"?
В условиях нескучного имплисит рефлекшн/интроспекшн, японец -- единственный человек, который сможет разобраться в собственном рефлекшн/интроспекшн. В условиях вменяемых интерфейсов с кодовой базой фреймворка разберется кто угодно. Забудем на минутку, что vue абсолютно никак не натянуть на typescript, а потому годится исключительно для хелловорлдов.
> И сейчас обгоняет
На сколько миллисекунд? Очень интересно, сколько спичек сэкономили.
React не заставляет использовать jsx:
const t = React.createElement;
t("div",{...
На хтмл заставляет писать любовь писателя к хтмл.React не обновляет весь реальный DOM.
А с pure-компонентами вообще оверхед к нулю стремится.
Период полураспада всех этих хипстер поделок год-два, потом появляется новая yoba технология
> на кой нужна эта failbook'овская печалька, когда есть vue ?Ой, да ладно. У вас, js-ников, тренды и фреймворки меняются как перчатки.
Использую оба Vue и React могу сравнить
- В целом по сравнению с реактом на Vue действительно интерфейс пишется намного быстрее, практически со скоростью мысли.
- В Vue меньше готовых компонентов, но свои компоненты пишутся в разы быстрее чем в реакте. Прикрутить какую-то либу в удобненький компонент - минутное дело, конечно при наличии знаний.
- HTML прям в JS лично для меня кажется довольно неудобным, по сравнению с красиым языком темплейтов в Vue.
- По многократным бенчмаркам на интерфейсах разной сложности Vue всегда рендерит быстрее.
- Редукс (дефакто стандатрный стейт в реакте) настолько запутан что порог вхождения довольно высокий, новичкам придется много почитать. Фейсбучники кстати признают эту проблему и собираются ее решить, но когда?. Vue-шный стейт (vuex) вероятно скопирован с редукса, тем не менее он намного проще, за пару дней начинаешь делать рабочий красивый код.
- В vue шикарнейшая красивая документация, у фейсбучников почемуто всегда находишь инфу невпопад. Это очень субъективно, возможно у меня вывернуто восприятее, но все фейсбучные поделки почемуто кажутся откровенно е*нутыми, включая сам facebook
- На реакте легче найти работу потому что он популярен, во всяком случае на биржах ремоут работы. И хоть писать на реакте не удобно, сам он тормозной и внутри содержит кучу мусора, к сожалению реальность такова что инвестировать свое время правильней в react.
- У react-а есть react-native который позволяет писать на нем под телефончики. Писать мобильное UI на Vue разьве что можно под електроно-подобные поделки, но там нет тонн либ для доступа к API ос телефона.
- Один из ключевых минусов Vue - только один контрибьютор Evan You. Не смотря на то что этот человек делает невероятно удобный и шустрый фреимворк, к сожалению нет ни каких гарантий что завтра он останется таким же как сегодня.
- Если вы налажали в коде то оба фреимворка могут выставить вам совсем неадекватный стектрейс по которому вы ничего не поймете. Такие баги занимают больше всего времени по этому первое время советую вдумываться и писать все очень аккуратно. Касается обоих но в реакте наделать глупостей лично мне удовалось легче.
>Vue-шный стейт (vuex) вероятно скопирован с редуксаОн скопирован с MobX, альтернатива редуксу.
>У react-а есть react-native который позволяет писать на нем под телефончики.
У vue есть weex от алибабы.
> Ранее в черный список Фонда Apache также были добавлены такие лицензии, как GPL, AGPL, LGPL и BSD-4-Clause.GPL, AGPL, LGPL за что?
Известно за что.Кому как, а мне после данного факта Фонд Апач кажется еще менее нужным.
> GPL, AGPL, LGPL за что?--Пермиссивщики, сэ-э-р.
А BSD-4-Clause тогда как? По моему они просто закусили удила. Видимо скоро пристрелят :-)
> А BSD-4-Clause тогда как? По моему они просто закусили удила. Видимо скороВидимо, они Столмана читали и согласны. По поводу BSDL-4cl, по поводу GPLv3...
> пристрелят :-)
Возможно. Хозяева не любят страптивых рабов.
> Ранее в черный список Фонда Apache также были добавленывсе лицензии, кроме лицензий от Apache
Ну и фиг с ними, есть божественный Vue.js.
Что им мешает изменить зависимости на preact + preact-compat который полностю совместим с React и под лицензией MIT.Даже переписывать не нужно.
Mithril.js лучше реакта по всем параметрам. Инфа 100%
> Mithril.js лучше реакта по всем параметрам. Инфа 100%Наивный болтун, решил что они перепишут код?
Странная логика у апача, лицензии BSD-2/BSD-3 разрешены, хотя вообще никаких прав на патенты не дают.Лицензия Facebook BSD+Patents (которая по сути BSD-3 + дополнительные права на использование запатентованных технологий) запрещена.
Apache в отличие от Facebook асоциальные личности.
> Странная логика у апача, лицензии BSD-2/BSD-3 разрешены, хотя вообще никаких прав на
> патенты не дают.
> Лицензия Facebook BSD+Patents (которая по сути BSD-3 + дополнительные права на использование
> запатентованных технологий) запрещена.https://github.com/apache/incubator-superset/issues/3148#iss...
> Странная логика у апача, лицензии BSD-2/BSD-3 разрешены, хотя вообще никаких прав на
> патенты не дают.Пермиссившики же. Фб им не даёт, а _забирает_. Ну, как GPL, панимаишь?
---"Каптёр. чужое! Халява! Взять, взять!!"
Чего там GPL у кого забирает? Что-что? Код нужно в проект возвращать? А, ну беда, беда.
Выбравших это для собственного проекта поздравляю.
А чем вам мешает patent clause? Вы собрались подавать в суд на Facebook? :)
Зато они могут в суд подать. Если посчитают, что ты конкурируешь с facebook.
Как будто если бы была просто BSDL, то это бы что-то меняло.
> Как будто если бы была просто BSDL, то это бы что-то меняло.Видимо юристы ASF видят большще твоего. В новости наверху не написано, что с "дополнениямм" подать с суд на fb нельзя, а без "дополнений" можно? А то я не читал -- сходи, посмотри??
> А чем вам мешает patent clause? Вы собрались подавать в суд на
> Facebook? :)Фб идёт против Великой Пермиссивной Идеи -- "Проприертарщикам можно В-Ф-С-Й-Ё-О-О!!!". За это перписсифная ASF не любит проприертарщика Фб, ибо как же они могли ограничить пермиссивную лицензию, да? Для других проприертарщиков, то есть.
Это прямо как какой-нибудь one-upstream проприертарщик выыбрасывает через стену "опенсорсненький коммьюнитивненький опен-коре-нный" релиз своей проприертари -- под GPLv3= или AGPLv3 -- чтоб и все остальные проприертарщики, и дедушка Столман жабой давились, а "конкуррентное преимущество" оставалось у папика....
Да про ASF понятно, вопрос, чем вот лично анонимусам с опеннета этот clause мешает. Тем же, чем и GPL.Касаемо проприетарщиков - реакт - это ж не приложение, а библиотека, open core модель вокруг библиотеки невозможна. Этот clause ограничивает только других крупных проприетарщиков с большим патентным пулом, всем остальным от него не меняется вообще ничего.
BSD - самая свободная, говорили они, пока один некоммерческий фонд во всю рубился с правобладаетелем о перелицензировании.
сразу тонны оправданий повсюду https://code.facebook.com/posts/112130496157735/explaining-r.../
Компания открывает исходники и выкладывает проект. Прибегают какие-то левые фанатики и чего-то требуют. Свободно!
> Компания открываетВам подано кушать на лопа ^W коудеплексе.