Открыть список
Как стать автором
Обновить

Комментарии 137

Странно что почитали про Redux, но забыли про RxJS.
Я про него не забыл, просто у нас в проекте как раз подобная абстракция используется для событийной модели и асинхронного dataflow — но для меня было совершенной загадкой, как React'у удается быстро обновлять DOM при изменениях в данных без использования подобной абстракции. Для меня это было инсайтом — как и то, как тесно это связано с иммутабельностью и функциональной чистотой.
@Возможно, классы все-таки действительно не нужны@
Это вы моих комментариев начитались:) Как всё таки React'у удается быстро обновлять DOM при изменениях в данных без использования подобной абстракции.@? Тема не раскрыта…
тема раскрыта, любое изменение это всегда изменение ссылки, смотрим где поменялись ссылки — там перерисовываем.
Какое изменение ссылок??? Вы о чём??? Как данные влияют на структуру?:)
Вот за такой GNU стиль расстановки пробелов надо убивать.
$static ($debounce ($bindable ($memoize (function () { ... })))),
Я просто думаю что правила типографики из текстов на естественных языках применимы и к коду — ведь текстовое представление кода именно на естественных языках и базируется. То есть если вы в английском или русском языке перед скобками ставите пробел, то почему бы и в коде так не делать? Это очень естественно.

Убивать вообще никого не надо, агрессия нынче не в моде.
НЛО прилетело и опубликовало эту надпись здесь
Так, а что не так-то? Надо убрать пробелы? Добавить еще пробелов? Не очень понял, что не понравилось вам.
Небольшой вывод по прошлой статье и текущей (поправьте меня, если в моей логике есть брешь): в js мода меняется быстрее чем в индустрии женских сумочек. Поэтому если вы хотите суметь устроиться на работу через пару лет, вам стоит сейчас выбирать конторы, которые запускают много маленьких проектов. В каждом новом проекте можно пробовать ту технологию, которая сейчас в моде. Очень странная ситуация, программисты, которые работают над действительно большими и нужными проектами (а поэтому с большим количеством legacy) оказываются в проигрышной ситуации.
Мой друг как-то рассказывал мне историю про своего кореша, который ушел из Яндекса по той причине, что опыт, полученный в Яндексе был применим только в самом Яндексе.
при этом если мы нанимаем кого-то в проект — все равно спрашиваем не про либы и фреймворки, а чем this.x отличается от prototype.x и как работают замыкания. И вот ведь незадача! — часто человек весь из себя редукс, а на такие вопросы не отвечает.

Мне чтобы для себя ответить на эти вопросы, пришлось много лет делать свой фреймворк. Я об этом не жалею, потому что это позволило мне разобраться в JavaScript вплоть до самых его кишок. Но именно поэтому я не осуждаю людей, которые не знают что такое .prototype или зачем нужен Object.create — потому что понимаю, сколько надо потратить личного времени, чтобы в этих деталях разобраться. У большинства людей на работе просто нет задач, которые это требуют.


При этом, при выборе сотрудника на работу я действительно отдам предпочтение тому, кто разбирается в используемых инструментах на самом низком уровне. Возможно, это просто предрассудок и суеверие, не знаю.

Возможно, это просто предрассудок и суеверие

Нет, это принцип «смотреть на пару уровней абстракции вниз», старина Джоэл про него писал в статье «Дырявые абстракции».
А что там ещё в языке остаётся кроме скоупов? Во всём языке не больше пяти абстракций.

Язык же не висит в сферическом вакууме отдельно от его реализации и от стандартной библиотеки, тонкостей очень много. Да и в самом языке странностей хватает вообще-то. Где-то был пост с хорошей подборкой их, я запамятовал.

Вот 2 теста замечательных на знание языка. Моя практика показывает что с ребятами которые хуже его проходят, сложнее работать и наоборот. Был один случай где человек хоть и не знал как конкретно язык работает, все равно не сдавался и выдавал предположения, которые были логичны и один из вариантов был верным. В данный момент он один из лучших разработчиков у нас.


  1. http://perfectionkills.com/javascript-quiz/
  2. http://perfectionkills.com/javascript-quiz-es6/

Покажете такого человека? А то все ими грозите, а на практике не встречал людей кто не знает про прототипы, но хорошо знает redux

Там ни слова про прототипы, в основном вопросы на внимание к typeof. Ну и, естественно, как там чувак сказал в комментах: "if these scenarios… come up for you in practice quite often, then you are doing it wrong."

ужасный тест. Когда мне такие дают, я осторожно интересуюсь «у вас подобные вещи встречаются в кодовой базе?»

В плагинах и библиотеках, такое часто бывает. Нужно чтобы человек понимал что происходит перед тем как использовать библиотеку, а если уже слишком поздно, мог починить или обойти проблему.

Вот например на этот вопрос единственным правильным ответом будет «Мне кажется, что тот, кто это писал — мудак, надо брать справочник и думать, как переделать эти спагетти»:
(function f(){
    function f(){ return 1; }
    return f();
    function f(){ return 2; }
  })();

Тест как раз нормальный, реалистичный. Потому что на большинстве работ вы будете заняты как раз тем, что будете переписывать легаси код, в котором вот такого будет полно. Вы конечно можете всегда найти работу в светлом и чистом стартапе (чтобы потом в будущем кто-нибудь точно так же чесал репу над вашим кодом), но надо понимать реалии рынка — в мире есть очень много плохо написанного кода, который нужно поддерживать или хотя бы переписать. А для этого нужно как минимум уметь в сортах говна разбираться.


Как пел Кровосток, «в наше время, в нашем месте, стоит разбираться в жести...»

Я понимаю, суровый энтерпрайз, все дела, но мне кажется даже самый упоротый программист который закончил 7 классов общего образования не будет писать в таком стиле:
var x = 1;
  if (function f(){}) {
    x += typeof f;
  }
  x;

Это всего лишь редуцированные до абсурда примеры, поэтому они и кажутся абсурдом. На деле за каждым таким примерчиком стоит какой-то очень сложный и заковыристый баг из реальной практики. Который, если свести его к минимальному примеру, даст вот такой, кажущийся очевидной глупостью, сниппет кода.

После статически типизированных языков это кажется бредом. из 4 строчек кода 1 является объявлением, а еще в 3 в нормальном ЯП была бы ошибка.
  • Cannot implicitly convert type 'void' to 'bool', либо Not all code paths return a value
  • Operator '+' cannot be applied to operands of type 'int' and 'Type'
  • Only assignment, call, increment, decrement, and new object expressions can be used as a statement


Я понимаю, что возможно там удалено много кода, и на самом деле это разбавлено кучей кода, который не оказывает влияния на поведение, но делает ошибку менее заметной, но блин яхз как можно не заметить сразу все вышеперечисленное. И ладно, я допускаю, что такое может случиться в продакшне, но считать это тестом по ЯП это я просто не знаю. Могу предположить, что где-то встречаются индивиды, которые оставили после себя на поддержке подобные перлы, и для отбора кандидатов на саппорт в эти самые места можно было бы использовать такие тесты, но он позиционируется как мейнстрим…
Они работают по БЭМ методологии. В технологиях это не ограничивает, но, насколько я знаю, методология вынуждает использовать весь БЭМ стек, хочешь ты или нет, иначе будешь много грабель собирать. Это не плохо, но такие навыки применимы как-правило только в крупных компаниях: Mail.ru, Яндекс, Rambler, и другие, которые работают по БЭМ.

Ребята работающие с БЭМ, будут интересны ваши комментарии по поводу смены места работы, есть ли сложности с этим.
Яндекс очень активно ее продвигает, по-возможности.

Можно прийти на их мероприятия, и Я-Субботники, при желании.
https://events.yandex.ru/events/bemup/
https://events.yandex.ru/events/yasubbotnik/

Правда, не знаю проводят ли они еще их.
+1 уволился с любимой работы ( любил её пять лет ), только потому что опыт который там получал, ни где больше спросом не пользовался.

Для больших нужных проектов есть другие технологии. Отличные от JS. Со строгой типизацией и нормальными классами. В которых во главе угла не мода, а читаемость, понятность кода, единообразие стандартных решений. Что позволяет годами поддерживать продукт с >100K LOC, просто и комфортно рефакторя старый код, а не подрываясь на "а давайте перепишем все на этой новой и блестящей свистоперделке".

В любом веб-проекте есть js. А по вашим словам выходит, что веб-проекты не могут быть большими и нужными.

Еще как могут )) Вам сюда Dart

НЛО прилетело и опубликовало эту надпись здесь

Честно и без обид: надоело читать как в каждом треде по JS люди жалуются о том как им тяжело живется и на проблемы у которых есть удачное решение. Которым они не пользуются в силу того, что им "религия" и "стадный инстинкт" не позволяют.

Ваше поклонение Dart тоже своего рода «религия».
К вопросу о «новых и блестящих свистоперделках» ;)
Извините, но даже Google предпочел TypeScript Dart'у.
НЛО прилетело и опубликовало эту надпись здесь
Меня всегда удивлял этот странный путь развития JS (ES).

Все js разработчики всегда плюются в сторону классов и типов, но при этом лучшие из них создают свою собственную систему классов / типов, а V8 под капотом типизирует создаваемые объекты.
Некоторые и вовсе собрались и создали TypeScript. Казалось бы крутая штука! Но как и все, что делается под эгидой Microsoft — сделано криво.

Дошло до того, что в ES2015 все же ввели классы, но не ввели типизацию (надеюсь, еще одумаются), теперь половина плюется, половина с радостью использует. Классы на самом деле хороши, но нету модификаторов доступа (public, private), которая иногда очень даже нужна. Нету полей класса, их можно объявить только через конструктор.

Почему все крутые чуваки в мире JS (ES) всегда стараются изобрести велосипед?

Вот уже много лет есть готовый язык, который основан на базе ES5, в котором есть Классы, Декораторы, Spread syntax, Поля классов, Модификаторы доступа, Интерфейсы. При этом язык позволяет создавать и использовать анонимные объекты и функции как в ES5, позволяет не описывать типы у параметров и возвращаемых значений, позволяет принимать любые значени (т.е. писать в ES5 стиле).
ActionScript3 — язык созданный на базе ES5, для Flash. Но сам синтаксис очень вкусный и без проблем подошел бы как путь развития синтаксиса ES.
Вернее, не Декораторы, а мета-теги (аннотации). Декораторы из ES имеют все же более мощный синтаксис.

Мой посыл был в том, что можно же взять такой синтаксис за основу и просто прикрутить к нему синтаксический сахар в виде стрелочных функций, асинхронных функций и генераторов.
Просто каждый пытается принести ООП в JS — а он там не нужен, нужно просто в языке разобраться а не пытаться прилепить классы или еще чего.

Классы это просто удобная декларативная форма конструирования прототипов, ничего плохого в этой абстракции нет per se. Плоха именно ES6 реализация, которая ломает идею «прототипы это тоже объекты» на уровне синтаксиса. То есть было:


Foo = $class ({ methodA: ..., methodB: ... })

стало:


Foo = class { methodA () { .. } methodB () { ... } }

Это даунгрейд по сравнению с ES5, по той причине, что прототип синтаксически перестал быть объектом, и я не могу переопределить реализацию class, добавив какой-нибудь препроцессинг этого. Для этого появился костыль в виде декораторов:


Foo = @decorate class { ... }

Но — ха-ха — это все равно даунгрейд, потому что внутри { ... } у нас не объект. Там другой синтаксис, который является подмножеством JSON — не позволяя делать key: value, а значит, теряя в выразительности.


Никакого смысла в ключевом слове class нет — оно не решает ни одну проблему, но создает кучу проблем. Все плюшки классового синтаксиса доступны и в объектах. Вот смотрите:


obj = {
    method () { },
    get prop () { },
    foo: bar
}

Видите? Я могу так же коротко записывать методы и акцессоры, но при этом я не теряю возможности сделать foo: bar. В ES6 достаточно было сделать лишь это, не было никакой нужды вводит ключевое слово class.


Проприетарные системы классов в JS просто выглядят так, как будто они пытаются имитировать классы. На деле они дают намного больше чем классы, и по факту являются просто абстракцией, позволяющей удобно описывать прототипы. И эти системы потому у каждого фреймворка свои, потому что у каждого решают какие-то свои задачи, специфичные для фреймворка. Скажем, где-то есть миксины, где-то нет. Ключевое слово class все ломает, запрещая разработчикам как-то встраиваться в механизм создания прототипа, фиксируя этот механизм, обрубая все замечательные возможности, которые появились в различных фреймворках.


Когда разработчики стандарта JS осознали, что же они натворили — бегом побежали делать декораторы, которые эту проблему немного позволяют решить. Но правильным шагом было бы исключить class из стандарта (сделать его deprecated), и развивать идею декораторов для объектов. Оставив задачу конструирования прототипов в userland. Потому что там нужна гибкость, и классы в ES6 эту гибкость уничтожили.

Брр, не подмножеством, конечно же, а вообще несовместимой с ним фигней, усложняющей язык.

Ниже я уже ответил, что не DOM-манипуляцией едины. Есть желание писать действительно большие системы на js. Системы, которые позволили бы полностью заменить большинство нативных приложений. Но столь огромные приложения очень тяжело поддерживать, если нету системы классов и типов.

Класс из ES2015 (принято же так называть, а не ES6) действительно не столь хорош, каким бы мог бы быть. Я выше приводил пример языка, который был бы отличным путем развития.

class Foo {
   private var _startPoint: {x: 5, y:10};
   private var _callback:Function;

   function set startPoint(startPoint) { this._startPoint = startPoint; }
   function get startPoint() { return _startPoint; }

   function set callback(func:Function) { _callback = func; }
}


Это лишь для демонстрации синтаксиса. Как видно, то, что вам не нравится в ES2015 в том же as3 реализовано так, как вам хотелось бы. Хотите — пишите в ES5, хотите пишите в виде ООП.
Т.к. это все же ES, никто не отменяет использование прототипов, можно уже существующим объектам подсунуть миксин.

Да, я согласен с тем, что классы (как сущность в синтаксисе) нужны для того чтобы статическим анализаторам (системе типов) облегчать работу. То есть в данном случае это просто контракт типа, который говорит что «а вот у нас такие методы есть», и это сразу доступно сразу после разбора AST, без необходимости делать глубокий вывод типов, как это делают инструменты типа Tern. Документацию опять же генерить легче.


Аннотации типов (и их статический анализ) в JS сейчас уже вовсю появляются — в статье про это упомянуто (Flow). Так что это может быть внешним инструментом.


Мне вообще очень нравится на самом деле то как развивается JS. Новые расширения языка сначала появляются извне, как внешние инструменты. А потом уже стандартизуются, когда становится очевидно, что это работает и работает хорошо. Babel это лучшее что случилось с JS за последние годы — а вовсе не «костыль», как многим кажется. Потому что стандарты делаются для людей, а не люди для стандартов. И чтобы понять, что нужно стандартизовать — это сначала должно быть опробовано людьми (комьюнити) и зарекомендовать себя. Но такой фидбек луп был невозможен до Babel.

Потому что там нужна гибкость, и классы в ES6 эту гибкость уничтожили.

Что именно классы уничтожли? Что мешает их не использовать если они вам не подходят?

Не использовать их, к счастью, мне ничто не мешает. Но именно поэтому я и недоумеваю, зачем они вообще нужны. Их функциональность прекрасно была доступна на уровне библиотек, и при этом была намного гибче. Что именно они уничтожили, я описал в начале статьи (где про декораторы написано). Без декораторов для моих задач ES6 классы вообще выглядят как бессмысленный огрызок.


Пока что мне вот подсказали, что для статического анализа типов классы хорошо, как хинт. Это действительно так, наверное.

Пока что мне вот подсказали, что для статического анализа типов классы хорошо, как хинт.

Любому программисту это должно быть очевидно.

и при этом была намного гибче

Вот как раз на «уровне библиотек» и «гибче» не позволяет использовать преимущество классов — жесткая и однозначно интерпритируемая/анализируемая структура.

Не стоит слепо повторять чужие слова, об «уничтожили» и тому подобное.

Какие чужие? Это мои слова, и это основано на моём опыте. Я как раз делал систему классов и декораторов для ES5, и вижу какие напряги возникают с попытками перенести это на нативные ES6 классы. Я не готов отказываться от этого только для статического анализа типов, это совершенно неразумный tradeoff в моем случае.


Просто вы видимо пришли из мира Java и пытаетесь писать код в таком же стиле. Разумеется, в таком случае JavaScript покажется каким-то ущербным Java без системы строгой статической типизации. Но это просто потому что вы не понимаете фишки JS.

Но это просто потому что вы не понимаете фишки JS.

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

Согласен, я погорячился с выводами. Просто я часто замечаю, что люди пытаются сделать из JS какой-то Java, хотя куда правильнее было бы двигаться в сторону функциональных вещей — и таким образом достигать статической верифицируемости. Собственно, я в этой статье и изложил видение того, как этого можно было бы достичь. А прототипы и динамичность языка мне нравятся именно возможностями метапрограммирования (embedded DSL), и это не очень пока совместимо с Java-подходом. Java это такой энтерпрайз-фашизм, а в JS есть дух хардкора, молодости и эксперимента. И вот это я и называю «фишкой».

> Java это такой энтерпрайз-фашизм

Это было очень сильное заявление. Оно очень точно описывает все программные продукты от IBM.

В java «хардкора» не меньше, чем в js, он просто другой =)
но обсуждение этого топика скатится в холивар)))

Как я писал ниже, есть настроения писать серьезные приложения на js с большими объемами логики (фактически заменить нативные приложения). Эти приложения должны быть Легкими в поддержке и Быстрыми в изучении.

Вот к примеру какая-нибудь программа для расчета бухгалтерии. Сейчас есть онлайн-решения, но они построены по принципу тонкого клиента. А ведь можно же сделать толстый клиент, который сможет работать оффлайн и не будет на каждый чих дергать бекэнд.
Объемы бизнес логики в бухгалтерском приложении неимоверные. А при текущем положении дел такое приложение будет состоять из сырых хеш таблиц и функций, которые с ними работают.

Но в целом да, можно сказать: «не хочу в такой проект, я хочу что-то классное!»
Просто вы видимо пришли из мира Java и пытаетесь писать код в таком же стиле. Разумеется, в таком случае JavaScript покажется каким-то ущербным Java без системы строгой статической типизации. Но это просто потому что вы не понимаете фишки JS.

Я уже почти десять лет как JS-программист, и пришел в него далеко не из джавы. Я писал правда большие вещи, библиотеки, игры, которые активно развивались и успешно поддерживались годами. Это не каждые полгода новый сайтик на 50 табличек сверстать. Статическая типизация — это не wish, это необходимость для любого крупного проекта, который не должен быть заброшен через месяц после релиза и у которого стоят высокие требования к качеству. Мы к этому пришли не с «Джавы», а кровью, разгребая динамическую типизацию. Хотя еще пять лет назад я был уверен, что утиной типизации — хватает:
Типизация — утиная, JavaScript не содержит подводных камней, просто люди не могут его понять


Декораторы — и вполовину не дают всего необходимого. Именно потому у них там от силы memoize, debounce и т.п. заваливается. Тот же memoize вообще бесконтрольный — плюет в память неограниченно и навсегда, да и невозможно вменяемо почистить от устаревших данных. Как покрыть тестами функцию, на которую наложили debounce?

Я уж молчу об оптимизации. Я понимаю, что современным хипстерам срать на нее хотелось и они готовы использовать O(n2) вместо O(n) исключительно для понтов, чтобы функцию можно было назвать чистой, пол-стейта приложения пересоздается ради того чтобы изменить три поля, МусороСборщик не хипстер, все сдержит, а функция заворачивается в функцию в функции, которую вызывает функция через функцию, в результате стек-трейс не влезает в экран. Но лично мы по-максимуму отказались от замыканий (постарались вынести их в момент инициализации игры или заменить на циклы, а эвенты — это методы обьектов) и этим +30% производительности игре добавили. А это, кстати, 60 фпс вместо 45. А это еще мы не использовали всякие новомодные «давайте 100 раз пересоздадим объект для того, чтобы сделать элементарную операцию».

А операция такая. У вас 10000 объектов, которые приходят с сервера. У них есть свойство, например Группа. Необходимо сгруппировать их по этому свойству в массивы. Вот процедурный код:
(objects) {
  let result = {};
  for (let obj of objects) {
    if (result[obj.group] == null) {
      result[obj.group] = [ obj ];
    } else {
      result[obj.group].push( obj );
    }
  }
  return result;
}


Как написать новомодно?
(objects) {
  return objects.reduce((result, obj) => ({
    ...result,
    [obj.group]: [
      ...(result[obj.group] || []),
      obj
    ]
  }), {});
}


Черт ногу сломит, линейное количество выделений памяти, квадратичное количество операций, зато модно, иммутабельно и можно перед другими хипстерами похвастаться, какой у тебя поддерживаемый код.

Я тоже делал систему классов в далеком 2010-м. И я ее делал по той простой причине, что не существовало такой системы, которая поддерживала б современные на тот момент технологии, например аксессоры(get, set). Да, современные классы далеко не идеальны. Они очень далеки от идеала. Как и деструктуризация, которая имеет другой синтаксис в сравнении с импортом. Но ключевое слово «класс» нужно. Чтобы движки нормально оптимизировали инстанциирование, без костылей с иннер-классами, чтобы проверять ошибки на этапе компиляции (а для этого еще нужна типизация, пусть и опциональная), чтобы иметь нормальное автодополнение в IDE, когда оно не вываливает мне на голову тонну всего, что похоже и чтобы IDE подсвечивала, когда я ошибаюсь. Чтобы было нормальное логирование в консоли, где я видел бы, что именно представляет из себя этот объект. Чтобы, когда я открываю чужой код, который писали 6 месяцев назад и вижу там аргумент config мне не приходилось использовать телепатию, звать того человека или ставить логирование, запускать код, смотреть что пришло, а потом на продакшене выяснить, что оно еще, в другом месте может получить совершенно другие данные, которые проходят утиную типизацию в старой логике, но не проходят в новой. Я уж молчу, что классы тестами покрываются очень легко — есть методы, есть состояния, которые можно проверить. Когда ж человек, который думает, что он пишет на ФП начинает комбинировать функции и использовать функции, которые возвращают функции — это покрывать тестами черт ногу сломит. Самый простой пример — React.PropTypes.shape возвращает функцию, которая не валидирует вне своего контекста. Замыкания по сути выполняют роль классов, только ты в классах явно описываешь стейт, а замыкание — какой стейт захочешь — такой и захватишь, при этом он не логируется в консоли, плохо чистится сборщиком мусора и совершенно неявный.

проверять контракты типов для свойств в JavaScript — так что наш ToggleButton мог бы выглядеть так:

ToggleButton = ({ label : String, toggled = false }) => <button toggled="{toggled}">{label}</button>


И при этом обязательность и тип свойства label проверялись бы еще до запуска программы!

Нет, не получится, в деструктуризации нельзя указывать типы. Тут обсуждаем варианты:
https://github.com/facebook/flow/issues/235

В свете этого, «классовая» запись выглядит просто как кривой бессмысленный костыль — и оно бы таким и было, если бы не один важный момент

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

И да, механика классов в ЖС пока малоюзабельна из-за ряда проблем, но это не причина отказываться от них и их развития в будущем, как говорит один из тех хипстеров по ссылкам, которые дал автор.

Про то что Flow не умеет в типизацию destructuring-выражений это, конечно, печально — но думаю это всего лишь временная неувязка. По поводу ваших сетований об алгоритмической сложности «хипстерского» (wtf) кода — вы же должны понимать, что это лишь специфика вашей работы (игры?), связанной с повышенными требованиями к производительности.


В достаточно сложном проекте (ERP предприятия), работающем с кучей данных (сотни тысяч записей в таблицах, обрабатываемых на client-side) мне пришлось всего пару раз вручную написать цикл — это собственно, табличный контрол который осуществлял виртуализацию рендеринга и фильтрацию/сортировку датасетов. Во всем остальном, «прикладом» коде я с радостью использовал все прелести функциональных выражений, вообще не думая о том, насколько быстро они работают (покуда это не начинало тормозить).


Premature optimization is the root of all evil, как говорится. Я в JS пришел из C++ и дико рад, что мне в моих повседневных задачах больше не надо думать о таких вещах, как ручной менеджмент памяти или там, упаси боже, какие-нибудь cache misses. Я хочу забыть про это, как про страшный сон, и заниматься вещами поинтереснее, чем бессонными ночами думать о «протекающих абстракциях» в моем коде. Покуда он работает и работает приемлемо — я не хочу об этом думать.

Статическая типизация — это не wish, это необходимость для любого крупного проекта, который не должен быть заброшен через месяц после релиза и у которого стоят высокие требования к качеству.


Вот я тоже удивляюсь как люди этого не могут понять, просто молятся на свое ФП. Видимо не сталкивались с большимим проектами и с тем когда разработчики в команде разного уровня. ФП (а также миксины и прочее функциональное месиво) хорошо в блоге показать, на ютюбе роликов сделать, но не для разработки больших и серьезных проектов.
Я не возражаю против этого, у js действительно свой увлекательный путь, который нужно полюбить.

Но! Почему-то миллионы леменгов хотят принести ООП и систему классов. Стоит посмотреть на старые библиотеки / фреймворки. Каждая из них вводит свой вариант создания Класса. jQuery, Backbone, Lodash, у них у всех свой путь к созданию эдакой системы типов. «Более современные» идут тем же путем.
Ответственные за развитие ES вводят классы. Может не все так хорошо с этим путем?

И ведь это все мы сейчас смотрим только с точки зрения веба (js для работы с DOM), тут и вправду можно обойтись ES5 и компонентным подходом к написанию кода.

Но кроме как для работы с DOM js используется еще и на бекенде (node.js | express.js). На js сейчас пишутся огромные веб-приложения с кучей бизнес логики (не только манипуляция с DOM). А еще игры пишут на js.
И вот для больших приложений и игр без объектной модели довольно тяжело будет обеспечивать поддержку.

Вот представим, что у нас есть Quake, написанный на js (Quake — это очень маленькое, по объемам логики, приложение). И у нас есть ошибка, конкретную точку, где она проявляется — мы знаем. Как найти все пути, которые приводят к этой точке кода?

Спасибо за комментарий, я пытаюсь в этой теме разобраться и у меня есть небольшой фидбэк к вашему комментарию:


Но! Почему-то миллионы леменгов хотят принести ООП и систему классов

Да, это целая проблема. Потому что: https://www.youtube.com/watch?v=wfMtDGfHWpA
Ещё примеры: https://medium.com/javascript-scene/how-to-fix-the-es6-class-keyword-2d42bb3f4caf а так же многие другие статьи Eric Elliott
Один из вариантов решения (возможно не самый лучший, но не плохой так точно): https://github.com/stampit-org/stampit


jQuery чисто прототипная библиотека, хоть new и скрыт за фабричной функцией.
Backbone, верно, проблема разобрана здесь: https://vimeo.com/69255635
Lodash, с точки знения пользователя вообще функциональная библиотека.


Вот представим, что у нас есть Quake, написанный на js (Quake — это очень маленькое, по объемам логики, приложение). И у нас есть ошибка, конкретную точку, где она проявляется — мы знаем. Как найти все пути, которые приводят к этой точке кода?

Возможно FP может помочь? Например Redux с глобальным state и Immutable data может помочь отследить что привело к этой ошибке. Плюс в реальном времени её можно пофиксить. Поскольку весь код написан на pure functions, никаких посторонних эффектов быть не должно.

>> Но! Почему-то миллионы леменгов хотят принести ООП и систему классов
> Да, это целая проблема. Потому что: https://www.youtube.com/watch?v=wfMtDGfHWpA

Система классов не подразумевает под собою наследование. Более того, с наследование — это действительно боль (в большинстве случаев). Классы очень хорошо можно использовать для типизации (классификации), к примеру, чтобы не в комментах писать, какой тип может приниматься методом, а напрямую в декларации метода его вставить. Так же, система классов позволила бы улучшить производительность рантайма: точно известно сколько памяти нужно выделить, точно известно, сколько полей есть в классе, известны ссылки на методы и т.д.

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

Для этого разве нужны классы?
Для этого нужна возможность декларировать Тип.

Сразу оговорюсь, мне больше нравится немного улучшенный Си-шный вариант ООП: структуры с методами, которые имплементят интерфейсы.
Интерфейсы описывают Тип, «структуры с методами» (так и тянет сказать Класс) — имплементация Типа. Желательно без наследования.
Все взаимодействие ведется либо через Тип, либо через Конкретные «структуры с методами» (когда разные имплементации не подразумеваются).
— это я подразумеваю под определением Класса.

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

Спасибо за ответ!


будет очень больно

Да, та же проблема что и у multiple inheritance. Хорошо что в js её не так сложно решить как в java, c#.

> Возможно FP может помочь? Например Redux с глобальным state и Immutable data
> Поскольку весь код написан на pure functions, никаких посторонних эффектов быть не должно.

1. FP, Immutable data
Не столь принципиально, каким путем пойти, FP и OOP справятся в целом одинаково.
Но вот Immutable data… Immutable data для шутера! В этом случае GC будет вызываться очень часто, ваш ноутбук будет перегреваться, FPS будет… FPS иногда будет =)

2. pure function, global state
если все будет на pure function, то кто будет обновлять состояние?))
  1. Признаюсь тут я дилетант, но даже мои дилетантские тесты показывают что для большого количества объектов постоянное клонирование приводит к задержкам, так что я согласен. Интересно, есть ли материалы по решению этой проблемы для ФП...
  2. :) Не до такой степени pure конечно. Примерно как в Redux.
Из того, что встречалось мне, в качестве решения можно использовать билдер, но в приделах одной функции.
Если нужно выполнить 10 изменений, можно из объекта сделать билдер, на нем произвести эти 10 изменений, и наружу отдать новый экземпляр неизменяемого объекта. Тем самым вместо 10 клонирований будет всего 2.

но это отступничество от идеологии, как и global state =)
Возможно FP может помочь? Например Redux с глобальным state и Immutable data может помочь отследить что привело к этой ошибке. Плюс в реальном времени её можно пофиксить. Поскольку весь код написан на pure functions, никаких посторонних эффектов быть не должно.

Вы пробовали дебажить Редакс? Крупные игры — это не веб-сайты, где много одинаковых табличек, тут кустарные вещи работать не будут.

Уважаемый TheShock вам по-любому виднее! Я только разбираюсь c ФП и считаю что хорошо понимать где его нужно использовать, где не нужно. Тоже самое и с class, closure, и т.п. Особенно в свете последих статей от Eric Elliot, а также материалов от Brian Lonsdorf. Хотелось бы материалов без предпочтения сравнивающих разные подходы, рассматривая где и когда их использовать. Но раз такого нету, приходится через комментарии (ну и в личных проектах) вот так узнавать мнение =) Простите мне мое лукавство.


П.с. спасибо вам за ваши статьи и комментарии на хабре, всегда очень интересно вас читать!

Да, после ас3, код на джс выглядит уж больно кастурбатым. Остаётся haxe.

Flowtype для слабаков, да? ;)

Да, я в курсе про Flowtype, но заметьте — это сторонний плагин для babel, чтобы расширить стандарт ES. Это даже не proposal для ES7.

Вот прям из всех щелей прет типизация, но ее не пускают и даже не хотят рассматривать. А прет на сколько сильно, что даже пишут свои велосипеды (хинты через jsdoc) и расширения для стандарта как плагины для babel.

Мое сообщеним именно про это и было, что развитие похоже на изобретение нового лучшего велосипеда. И потом годами идет разнобой в спецификации и в реализации. По спеке уже давно есть классы, генераторы и т.д., на деле — только babel спасает, нужно все в ES5 транслировать.

Можно конечно сказать «Да кому нужны пользователи IE!!! Пусть ставят FF или Chrome!», но как ни крути, не везде такой ответ будет адекватным. Да ни FF, ни Chrome не поддерживают еще полноценно ES2015, а уже почти 1 год прошел :)

Я не столь часто использовал TypeScript, так что могу ошибаться с выводами, но на моём опыте, используя его — там сделаешь поблажку, тут, у тебя всё в конце концов, грубо говоря, превратится в один большой any, хотя казалось бы, всё так хорошо начиналось. И требования к декларации d.ts всё только усугубляют, хотя куча сторонних уже готовых деклараций спасают положение, но всё же...


Мне нравится Flow именно потому, что типизация опциональна и нужна "только там, где нужна". На всё "фигак-фигак" можно смело забивать болт и писать на чистом ES5, а любой критичный код можно собирать даже с рантайм проверками (по крайней мере в dev'е). Единственное чего не хватает — это, например экспортирования указанных типов в Metadata, например для последующего анализа внутри DI контейнера для двойной диспатчеризации. А так — идеал, никому не мешает — хочешь используй, хочешь — нет.


Ну это моё имхо.

После знакомства с TypeScript я начал сомневаться в адекватности его авторов. Они взяли js добавили к нему типизацию, но сделали это криво. Сделали это через велосипед и костыли. А ведь все уже было готово, готовый язык, готовые ИДЕ, статические анализаторы и прочее. Нужно было лишь взять и дописать транслятор AS3 -> JS. Заменить flash sdk, на web sdk или node sdk — и вуаля, у тебя мощный инструмент для созданий серьезных веб-приложений. Если бы они так сделали, глядишь, сейчас не изобретали бы еше одно колесо, а прочно засели бы на серверах и дали бы буст для производительности в браузерах.

Полностью согласен, но это всё издержки подхода "без строгой типизации везде и всюду — жизнь не мила".


P.S. При таких запросах… Ну так Haxe же: https://haxe.org/ =)

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Для чего вам еще один язык, компилирующийся в JS https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js?
Вопрос стоял очень просто, добавить немного статического анализа хотя бы на уровне своего приложения. Причем без overhead в виде килобайтов и длительной загрузки собственной системы типов на клиентской стороне.
Никто не рвется переписывать тысячи JS-библиотек, так как типизации нет на уровне виртуальной машины в браузере, и ни один из существующих компиляторов не способен выдать из другого языка высокоэффективный JS-код.
А работать надо здесь и сейчас. И использовать чужие библиотеки, написанные не на typescript, зато оттестированные и проверенные тысячами разработчиков. Отсюда необходимость в d.ts, ну либо как во flow, каждый сам проверяет интерфейсы чужих библиотек.
Резюмируя, TypeScript никогда не позиционировался, как «убийца JS», мало того, не зная JS, писать на нем — самоубийство. Это «синтаксический сахар для JavaScript» https://msdn.microsoft.com/ru-ru/magazine/dn890374.aspx.
И это эффективный помощник для тех, кто понимает.
так как типизации нет на уровне виртуальной машины в браузере
не способен выдать из другого языка высокоэффективный JS-код

На самом деле есть: https://en.wikipedia.org/wiki/Asm.js. То есть типизация на уровне VM вполне себе есть, просто она неявная. Можно писать такой код, который будет в очень эффективные конструкции JIT'ом скомпилирован. Вот из вики пример:


int f(int i) {
  return i + 1;
}

function f(i) {
  i = i|0;
  return (i + 1)|0;
}

Вот эти |0 гарантируют компилятору, что результатом выражения будет тип integer, и что это можно в эффективные инструкции скомпилировать. Ну это самый примитивный пример. Компилятор Emscripten автоматически все это генерит (это транспилятор из LLVM байткода в JS)


На деле JIT очень продвинутые оптимизации делает, например может понять где у вас POD-структура, а где динамический словарь.

(соответственно, если бы у нас в языке были явные хинты типов, то это существенно облегчило бы работу JIT'у; но суть в том что «под капотом» JS все очень даже типизировано уже — осталось лишь во «фронт-енде» — в самом языке — хинтинг типов добавить — и можно неиллюзорный профит ловить, от возросшей производительности)

Любой язык построенный на классах, и AS3 в этом смысле не исключение, рано или поздно приводит к росту статического ядра. Выходом из данной ситуации могла бы послужить введенная в ES6 конструкция Object.setPrototypeOf(child, parent), позволяющая динамические строить иерархии используя классы как объекты; Но в существующих фреймворках данный подход почему-то не просматривается.
Если честно, не совсем понимаю, что вы имеете ввиду под «ростом систического ядра», и что за статическое ядро. Не могли бы вы рассказать про это? И какая в этом проблема?

На счет Object.setPrototypeOf, не совсем понятно, каким образом прототипное наследование «извне» будет лучше классического (или того же прототипного, но с классическим привкусом, как в ES2015) наследования «изнутри».

Динамически собирать иерархию объектов, с возможностью «множественного наследования», когда порядок подключения родителей имеет значение и порою бывает критическим. Думаю, это не лучший способ построения кодовой базы. Пока это небольшой проект — все будет довольно не плохо, а когда в системе будет несколько сотен сущностей — тут уже будет тяжело поддерживать и разбираться.

Возможно, я не прав или не понимаю этой концепции, но на данный момент у меня такая точка зрения.
Андрей, есть два способа организации кода — наследование и композиция. Композиция предполагает применение чужеродного кода. Но если этот код полезен, то рано или поздно он переносится в ядро. Возьми Drupal например. Не вижу ничего плохого в «множественном наследовании». У вас в есть указатели на классы. В запросе указываешь на тот который нужен. Именно иерархия будет динамически собираться. Если надо то и сохранятся в виде снимка иерархии из указателей и данных. Порядок подключения определяется следованием элементов в массиве. В маппинге задать последовательность в принципе невозможно. Запустил, поднял из репозитария иерархию, поработал. Если надо сохранил. Все дела.
Начнем с того, что компоненты React — функции. Ничего никуда не делось.

Ну да, это просто терминологическая путаница. Я почти сразу подправил статью после публикации, просто видимо вам в RSS (или еще куда) старая версия подсосалась.

А как на счет

class User {
get hi(){
return 'hi'
}
}

let Vova = new User();
console.log (Viva.hi)

Мне этого в моей реализации было достаточно.

Тоже изучал тему статических
свойств классов, на 2ality есть ссылка, что это антипатерн.

Еще есть бабелевская обертка для использования статических свойств.
У вас «Вова с приветом» привет передавал, но устал и не добрался до консоли.
«Крутые чуваки» просто лишний раз хотят засветить свое имя говоря что классы не нужны. Вся эта функциональщина должна быть помещена в голову для анализа полной структыры проекта, желаю удачи этим чувакам с их миксинами при работе с большимим поектами. В конце концов не нужные классы не используй, но не нужно называть свою функциональщину серебрянной пулей. Типов в JS не ожидается, потому что предоплагаю странные люди пишу стандарты. Вот TypeScript сделали инженры, а не хипстеры.
К чему мне ваши ссылки на ресурсы для джуниоров? Я ваши миксины использовал более 10 лет назад, когда их так еще не называли. Так и не поняли чем эти миксины могут навредить большому проекту? Хипстерня любит функциональщину, это очевидно, но на практике такой подход не всегда оправдан.
К чему мне ваши ссылки на ресурсы для джуниоров?

Вы забыли пару восклицательных знаков =)


Так и не поняли чем эти миксины могут навредить большому проекту?

Хотелось бы разобраться. Если вас не затруднит.

Хотелось бы разобраться. Если вас не затруднит.

Попробуйте порефакторить эту «функциональную кашу», сразу разберетесь. Функциональщина делает из кода месиво, которое не может быть однозначно интерпретировано на этапе разработке. Происходит разработка скриптов.

ФП тут не причем. Я говорю о прототипном программировании учитывая что прототип это объект и в js объекты динамически расширяемы. Посмотрите пожалуйста на мои ссылки ещё раз, особенно на первую. Как вы на одних лишь классах решите проблему из видео?

Я не пытаюсь даже спорить, мне лично понятны недостатки и преимущества обоих подходов. Эта чудесная композиция / миксины и ФП (все это делает из кода неконтролируемое месиво) в целом подходят только для простых проектов, можно сказать для проектов где работает один человек которому скучно писть поддерживаемый код (назовем его хипстер).
Странно, насколько я помню, пока что в React не особо успешно решена проблема пересчета виртуального DOMа у деток пересчитываемого компонента, даже если они не изменяются.
https://jsfiddle.net/duskpoet/69z2wepo/53398/

Мб туда надо PureRenderMixin вкорячить?


https://facebook.github.io/react/docs/pure-render-mixin.html


Просто, как я понимаю, по дефолту Реакт свои компоненты не считает за чистые функции. И вызывает render() всегда. Я именно поэтому и упомянул два раза в статье, что описываю «идеализированный» Реакт :)

Ага, тогда вполне неплохо. А Redux похоже вообще отказались от React-классов и используют чистые функции. Хорошо люди устроились.

Кстати — в React 15.3.0 добавили класс верхнего уровня React.PureComponent. Чтобы нормальные пацаны от него наследовались, а не от React.Component. Там render вызывается только, когда нужно

С добрым утром, декораторы депрекейтнули и уже года полтора думают что с ними делать. Т.е. по факту в языке и компиляторе (babel 6) их нет, только в виде leagcy пакета. =)

Ну это меня не печалит, потому что у меня свои «декораторы», которые вообще даже в ES5 работают. Я просто прикидывал, как их можно было бы реализовать, будь у нас нативный синтаксис. Хотя по мне, лучше бы они классы депрекейтнули, ха-ха.

Офигеть, ещё даже не зарелизили, а уже депрекейтнули… Куда катится этот язык?

Это просто SerafimArts панику наводит. На самом деле это не депрекейт, а просто обновляют черновик стандарта, и пока апдейт идет, из Babel временно убрали текущую реализацию (она доступна в виде внешнего плагина). Это нормальный процесс работы, и декораторы еще вернутся. Их уже юзают многие технологии популярные — например ангуляр2, mobx.

Ну это с иронией было сказано. Никуда они не делись, но там ситуация примерно как с модулями в плюсах: Собираются, ставят на повестку вопрос "ну что будем делать с декораторами?", отвечают — "ничего". На этом обсуждение заканчивается. +)

Третий год использую RactiveJS и пока не разочаровался. Для любителей ReactJS посоветовал бы еще глянуть на InfernoJS. Говорят у них diff сделан значительно лучше.

Та часть что про keyed lists в диффе.

Честно говоря подробно не разбирался. Мне вот RactiveJS нравится почти всем, его и использую, хотя знаю что тесты по скорости он проигрывает фактически все. Пока меня это не беспокоило, видимо задач не было где бы я увидел разницу между тем как рендерит ReactJS и RactiveJS. Другим может и не подойти конечно.

Будем честны. Все поднятые Вами проблемы решаются сменой языка программирования на тот, в котором statless и promises реализованы на уровне языка. Elm, Clj, F# и ни разу не на TypeScript или "статический" js + Flow. Например


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

Но изначально React создавался, как урезанный Elm с классами. Ну и тэ пэ

Я в соседнем топике как раз про это и пишу:

Я кстати уверен что в будущем люди не то что «забудут этот недохаскель». Но реально перейдут на хаскель. Ну точнее его браузерную инкарнацию какую-нибудь, типа Elm. Очевидно же, что все к тому идет, просто не революционным, а эволюционным путем. JS все больше и больше становится похож на это, в какой-то момент уже просто не будет смысла использовать JS, все свитчнутся на какой-нибудь транспилируемый в него язык. Они и сейчас есть, такие языки, просто люди еще не понимают до конца, зачем они нужны — но это в какой-то момент станет очевидно всем. И появление таких вещей как React/Redux в массовом сознании это очень мощные сигналы к этому.

[...]

И тут интересный дальше момент — это определяет архитектуру нашего приложения. То есть, выгодно юзать Redux. А это уже все прямиком пришло их функциональных языков, из Elm в частности. И постепенно никакого смысла в том чтобы использовать JS вместо Elm не будет. Потому что Elm позволяет еще и статически верифицировать всю программу так, что у вас вообще нет runtime exceptions. А это и есть ультимативная цель всего этого замеса.
Ну, у Elm судя по обсуждениям на hackernews есть свои проблемы, в частности запутанный ffi (вызов js из elm). К тому же это довольно упрощенный Haskell ориентированный на фронтенд, т.е. не язык общего назначения. Мне самому очень нравится Haskell и поэтому это меня немного огорчает… Смотрю в сторону ghcjs и purescript. Что о них думаете?

Я хаскеллом не обмазываюсь уже лет восемь, поэтому совершенно выпал из контекста — про ghcjs и purescript впервые слышу. Я про Elm-то узнал буквально на днях, когда узнавал откуда у React/Redux ноги растут. Даже не успел его попробовать толком.

упрощенный Haskell ориентированный на фронтенд

Не упрощённый Haskell общего назначения избыточен и слишком сложен для решения проблем, типичных для клиентской вебморды.

запутанный ffi (вызов js из elm)

Иначе Elm не даст гарантий безопасности рантайма, очевидно же.

Пробую писать на Elm. FFI как такового там нет. Есть так называемые port для взаимодействия с кодом на JavaScript. И есть native-модули, которые естественно пишутся на JavaScript. Непосредственного вызова JavaScript из Elm нет.


Любители Haskell могут также посмотреть на Fay. В отличие от Elm это упрощённый Haskell (нет классов типов) с тривиальным FFI.

Вряд ли Haskell такой уж идеальный ЯП что вот так прям взлетит в будущем, учитывая его сложность. Упомянутый Elm скорее взлетит, ибо он проще. Я собственно про то, что его можно же уже сейчас брать. То есть те причины, по которым его люди избегают ("у меня в проекте DataTimePicker из jQuery UI, как мне его вставить в Elm ?!") мне не кажутся убедительными, если только нет действительно большого количества legacy кода.


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

Я не согласен про JavaScript, как язык, он очень универсален и прост. Поэтому интерпретаторы JS есть везде, их относительно легко писать. Попробуйте написать для haskell кучу GHC для всего на свете, это адский труд, который должен быть оправдан (например, повышенная надежность мед. оборудования и т.д.).
Другое дело, что многие web-задачи стали именно такими, требующими скорость исполнения, максимальное покрытие тестами (требованиями) и т.д. И в JS просто нет многих вещей для этого. Но, ИМХО, и не нужно. Ведь задачи, для которых он был создан никуда не делись.
Ну ок, неудобно на нем писать сами компоненты, зато теперь есть пока еще не такая крупная и сложная задача — компоновка этих компонентов, сборка и доставка (webpack.config.js, gulp и т.д.). Станет эта задача большой и сложной, напишем под нее компилятор haskell.
Зато появится задача управления docker-контейнерами, когда нам станет не хватать docker-compose.yml с его возможностями.
Эта цикличность никуда не денется: начинается все с конфигов, потом сложных конфигов с переменными, потом простых скриптов, потом сложных скриптов, а потом уже (через N шагов) вся мощь haskell :-) Я кстати вот не уверен, что пора уже прям до haskell доводить, может хватит пока Java, C# уровня? Так рассудили и создатели TypeScript.

Посмотрите на стили, та же история, CSS, SCSS и сейчас уже в react вот и стили программируемые (react material ui), а в react native и вовсе один способ.
В общем, не нужно трогать JS, нужно перетерпеть ситуацию с компилированием в него и дождаться webassembly.

Есть еще такой момент для размышлений. Что, если нам вообще не нужна надежность и гарантия в браузере? Что если пользователь является частью экосистемы и сам допиливает то, что ему нужно (привет, adblock, userscript и др расширения). Можно конечно давать менять какие-то жестко зашитые вещи (ну вроде как поддержка плагинов), но что если гибкость до самого корня (DOM, сеть и т.д.) является залогом успеха развития веб? Для чего мне жестко зашивать и проверять кучу параметров, а потом выслушивать, что исчез логотип хабра, если каждый пользователь все равно создаст собственный хабр в браузере для просмотра статей. Может стоит не бороться с этим, а возглавить?

А приложения, требующие высокой стабильности и надежности, всегда можно реализовать для каждой платформы нативно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
зато теперь есть пока еще не такая крупная и сложная задача — компоновка этих компонентов, сборка и доставка (webpack.config.js, gulp и т.д.)
В нормальных платформах/языках это делает компилятор/линковщик. В js это, как и всё остальное, реализовано через одно место — с помощью гимнастики на волшебных костылях.

Что, если нам вообще не нужна надежность и гарантия в браузере?

Простите, но это похоже на бессвязный поток понятий
Как по мне, фейсбук (автор Реакта) не тот сайт, для которого нужно было городить огород.
Там хватило бы и jQuery.
Код должен быть понятен большинству, а не только крутым перцам.
Такой код дороже.
А еще фейсбук память жрет.

На самом деле, код на jQuery намного дороже. Это примерно как лечить зубы у плохого стоматолога. Вроде бы дешевле, но выходит что дороже. И потерянное время вам никто не вернет.


И оправдано это именно в мегапроектах типа Фейсбука. У них тысячи компонентов, миллионы строк кода. Для маленьких же сайтов-визиток, конечно же, лучше использовать jQuery. Или вообще голый DOM (в jQuery смысла не очень много с появлением нативных селекторов).

Я не спорю, для многих сайтов (скорее приложений с веб-интерфейсом) больше может подходить какой-то фреймворк.

Но вот как раз фейсбук не такой сайт.

Вот почему у них миллионы строк кода?
Потому что, грубо говоря, не используют jQuery, а городят огороды.

https://habrahabr.ru/post/308148/

Вряд ли стоит писать на голом js.

Вы уже много фейсбуков написали? :) Просто у вас о нем очень примитивизированное представление. Любой веб-проект на деле намного сложнее чем кажется.


Фейсбук стали использовать React не так давно, значительная часть их кода всё еще на условных «джиквери» (разных предшествующих реакту технологиях, в общем). Если бы они с самого начала юзали React, им бы возможно удалось избежать как раз-таки их этой многомиллионной кодовой базы.

НЛО прилетело и опубликовало эту надпись здесь

Есть такой принцип — «не сломано, не трогай». Никто не будет переписывать миллионы строк работающего кода, только чтобы чуваки могли еще парочку статей об этом написать в модный журнал.

НЛО прилетело и опубликовало эту надпись здесь
>Любой веб-проект на деле намного сложнее чем кажется.

Не спорю.
С морды всей кухни не увидеть.
Но js это более морда и не понимаю, чего там у ФБ такого сложного.

ЛС
Подгрузка ленты
Комменты

Там больше сложностей на бекэнде, а не на фронте.
Код который обычно пишут на jQuery абсолютно не поддерживаемый и не развиваемый. Задача jQuery очень узкая. В первую очередь при разработке чего-то большого необходима структура и модульность. jQuery структуру не предоставляет, и большая часть любителей jQuery не способна самостоятельно задать гибкую структуру.
>В первую очередь при разработке чего-то большого необходима структура и модульность.

Это так сложно разбить код хотя бы на файлики?

>jQuery структуру не предоставляет

А плагины?

>и большая часть любителей jQuery не способна самостоятельно задать гибкую структуру.

То есть Вы не используете jQuery из-за того, что кто-то не может задать гибкую структуру? :)
НЛО прилетело и опубликовало эту надпись здесь
>Вы хоть раз видели, как кто-либо пишет код проекта плагинами?

Нет.
Сам использую их только для повторного использования.
Но ничто не мешает.

>В том и дело, что «большая часть любителей jQuery» этим даже не заморачивается.

Ну да, это большинству просто не нужно. :) Вы тоже не используете jQuery из-за того, что кто-то что-то не умеет? :)

>А если в проекте собрались «крутые перцы», которые могут написать «по уму», то почему бы им не взять более удобную технологию?

Выходит менее понятно :)
Куча дырявых абстракций.
https://habrahabr.ru/post/308154/#comment_9763712

Удобную, но более сложную, технологию стоит использовать, когда это оправдано.
Для сайта вроде ФБ и проще вряд ли это оправдано.

Кому-то нравиться прыгать с технологии на технологию, а кто-то решает задачи.
НЛО прилетело и опубликовало эту надпись здесь
А что плагины? Плагины всего лишь расширяют функциональность работы с DOM.
Вообще-то плагины не только ДОМ.
Хабр не туда коммент вставил :)
А зачем сначала делать копию объекта с изменёнными полями, а потом проходить по дереву и сравнивать? Почему бы не создавать сразу дерево изменений?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.