Примерно полгода назад CEO Reddit Стив сообщил о том, что мы перепроектируем сайт. Главный вопрос тут — как именно мы этим занимаемся. В наше время фронтенд-разработка очень сильно отличается от того, что было во времена, когда Reddit появился на свет. Сейчас имеется огромный выбор вариантов для каждой подсистемы веб-приложения. Как рендерить страницы? Как стилизовать контент? Как хранить и обслуживать картинки и видеофайлы? Как писать код? В современных условиях ни на один из этих вопросов нет готового ответа. Одним из первых подобных вопросов, на который нам необходимо было найти ответ, звучал так: «Какой язык выбрать?».
О богатстве выбора и требованиях к языку
Как ни странно, нашим языком для фронтенда не обязательно должен был стать JavaScript. В конечном счёте, какой бы язык для этой цели ни был бы выбран, код, написанный на нём, всё равно компилируется в JavaScript. Однако, во что именно компилируется код, возможно, менее важно, чем то, что именно пишет разработчик. Выбор языка оказался делом непростым. Вот что нам пришлось рассмотреть:
- BuckleScript
- ClojureScript
- CoffeeScript
- Elm
- ElixirScript
- JavaScript 2016 и будущие версии языка
- JavaScript + аннотации
- Nim
- PureScript
- Reason
- TypeScript
И это, кстати, далеко не полный список. У каждого языка есть свои плюсы и минусы, поэтому для того, чтобы помочь самим себе выбрать один из них, мы сформулировали следующие требования:
- Это должен быть язык со строгой типизацией. Типы, на микроуровне, играют роль документации. Они помогают, до определённой степени, обеспечивать правильность кода, и, что важнее, упрощают рефакторинг. Ещё одним соображением, в силу которого мы искали язык со строгой типизацией, была скорость разработки. Мы стремились найти строго типизированный язык, так как хотели ускорить работу. Такая идея идёт вразрез с тем видением типизации, которое сложилось у многих программистов. А именно, принято считать, что это — дополнительная нагрузка на разработчика, которая снижает скорость работы. Однако повышение скорости разработки означает ещё и увеличение вероятности появления ошибок. Нам нужна была типизация для того, чтобы код содержал как можно меньше ошибок, даже если пишут его быстро. Строгая типизация, кроме того, полезна в быстрорастущих проектах. Наша команда инженеров постоянно увеличивается в размерах, и число тех, кто работает над кодом, стабильно растёт.
- Нужно, чтобы существовали хорошие вспомогательные инструменты. Учитывая то, чем мы собирались заниматься (серьёзное перепроектирование сайта), у нас не было времени на то, чтобы самостоятельно создавать значительное число вспомогательных средств. Было очень важно, чтобы мы могли быстро приступить к работе, используя готовые решения с открытым кодом. Если говорить конкретнее, то вот о каких именно инструментах идёт речь. Это — интеграция с популярными системами сборки (например, с Webpack), поддержка линтера, простая интеграция с фреймворками для тестирования. Если интеграция вспомогательных систем для какого-то языка была неочевидной, мы больше этот язык не рассматривали.
- Язык должен был использоваться в серьёзных проектах. Если язык выглядел хорошо, но в реальности использовался лишь в мелких проектах отдельных энтузиастов, он вполне мог оказаться неподходящим для нашей задачи. Кроме того, если язык не используется в серьёзных проектах, возникают вопросы о том, долго ли такой язык просуществует, и о том, как быстро разработчики языка будут реагировать на сообщения о найденных в нём ошибках.
- Наши разработчики должны освоить язык достаточно быстро. В вышеприведённом списке есть прекрасные языки, единственный минус которых — слишком большой срок, который нужен разработчикам для того, чтобы их освоить. Среди них хочется отметить Elm и PureScript. Мы серьёзно обсуждали вопрос их использования. Однако, в итоге оказалось, что их внедрение означало бы слишком большой объём работы, необходимый для освоения новых концепций программирования разработчиками, которые с ними не знакомы, для выхода их на уровень, позволяющий продуктивно работать над проектом.
- Язык должен работать и на клиенте, и на сервере. На Reddit очень важно SEO, поэтому отсутствие универсальной системы выдачи готовых к отображению в браузере страниц — это большая проблема.
- Хорошая поддержка библиотек. Мы не собирались писать всё с нуля. Существуют некоторые задачи, для решения которых нужны надёжные, проверенные временем библиотеки. Нам хотелось, чтобы у нас была возможность выбора того, что нам нужно, из существующих библиотек.
После рассмотрения этих требований мы остановились на двух вариантах. Первый — TypeScript. Второй — JavaScript + Flow. Но, прежде чем сделать окончательный выбор, мы хотели как можно лучше понять особенности TypeScript и Flow, а также различия между ними.
Компиляция или аннотирование?
Одно из важных различий TypeScript и Flow заключается в том, что TypeScript — это язык, который компилируется в JavaScript, а Flow — это набор аннотаций типов, которые можно добавлять к JavaScript-коду. Корректность аннотированного кода проверяет статический анализатор.
Вышеописанные различия прямо влияют на то, как именно пишут программы. Взгляните, например, на работу с перечислениями в TypeScript и Flow.
TypeScript
enum VoteDirection {
upvoted = 1,
notvoted = 0,
downvoted = -1,
};
const voteState: VoteDirection = VoteDirection.upvoted;Flow
const voteDirections = {
upvoted: 1,
notvoted: 0,
downvoted: -1,
};
type VoteDirection = $Keys<typeof voteDirections>;
const voteState: VoteDirection = voteDirections.upvoted;Так как TypeScript — компилируемый язык, с его помощью можно создавать типы, которые определяются во время выполнения программы. Во Flow же типы — это всего лишь аннотации, поэтому мы не можем полагаться на какие-либо трансформации кода для создания представлений типов во время выполнения программы.
Однако, у TypeScript, в силу того, что он является компилируемым языком, есть определённые недостатки. При интеграции TypeScript в существующую кодовую базу есть вероятность того, что компилятор усложнит процесс сборки. У нас есть устоявшийся процесс сборки с использованием Babel и слоя транспиляции. Имеется несколько оптимизаций, которые хотелось бы сохранить даже при переходе на TypeScript, поэтому нужен был способ интеграции TypeScript, который не разрушил бы ту схему работы, которая уже есть. Результатом внедрения TypeScript стал бы гораздо более сложный процесс сборки.
В противовес обработке TypeScript, Babel автоматически удаляет аннотации типов Flow. Если бы мы выбрали Flow, процесс сборки приложения не усложнился бы.
Проверка корректности кода
В области проверок корректности кода Flow обычно показывает себя лучше, чем TypeScript. Во Flow, по умолчанию, запрещается использовать типы, допускающие значение
NULL. В TypeScript 2.x была добавлена поддержка типов, в которых не допускается NULL, однако, эту возможность нужно включать самостоятельно. Кроме того, Flow лучше выводит типы, в то время как TypeScript часто обращается к типу any. Помимо типов, допускающих значение
NULL и вывода типов, Flow лучше в вопросах ковариантности и контравариантности (вот материал на эту тему). Одна из типичных проблемных ситуаций здесь — работа с типизированными массивами. По умолчанию массивы во Flow инвариантны. Это означает, что следующая конструкция во Flow вызовет ошибку:Flow
class Animal {}
class Bird extends Animal {}
const foo: Array<Bird> = [];
foo.push(new Animal());
/*
foo.push(new A);
^ A. This type is incompatible with
const foo: Array<B> = [];
^ B
*/Однако, попытка сделать то же самое в TypeScript завершается без сообщений об ошибках.
Typescript
class Animal {}
class Bird extends Animal {}
const foo: Array<Bird> = [];
foo.push(new Animal()); // в typescript всё нормальноМожно найти ещё много похожих примеров, однако, общий вывод заключается в том, что Flow гораздо лучше показывает себя в деле проверки типов, нежели TypeScript.
Экосистема
Всё, что было сказано до сих пор, говорит о преимуществах Flow. Его легче интегрировать в проект, он лучше справляется с проверкой типов. Почему же мы остановились на TypeScript?
Одно из важнейших преимуществ TypeScript — его экосистема. Он отличается потрясающей поддержкой библиотек. Практически все библиотеки, которыми мы пользовались, либо имеют описания типов в самих библиотеках, либо представлены в DefinitelyTyped. Кроме того, TypeScript обладает отличной поддержкой IntelliSense в VSCode и в плагинах для других популярных редакторов, которыми мы пользуемся (например, среди них — Atom и SublimeText). Более того, мы обнаружили, что TypeScript умеет обрабатывать аннотации JSDoc. Это оказалось особенно полезным, так как мы переходили на TypeScript с JavaScript.
Кроме того, TypeScript отличается большей «социальной значимостью», и есть ощущение, что срок его жизни будет достаточно долгим. Существует несколько крупных проектов, использующих TypeScript (среди них — VSCode, Rxjs, Angular, да и сам TypeScript), поэтому у нас имеется уверенность в том, что набор его возможностей сможет соответствовать целям нашего проекта, и в том, что язык в ближайшие годы никуда не денется. По поводу же Flow нас беспокоит то, что он был создан для решения специфических задач в Facebook, и то, что его развитие будет определяться тем же диапазоном задач. TypeScript, с другой стороны, ориентирован на широкий спектр проблем, работой над ним занимается Microsoft. Всё это позволяет нам предполагать, что если мы столкнёмся с ошибками и сообщим о них, нас услышат и примут меры.
Кроме того, так как TypeScript — это язык, являющийся надмножеством JavaScript, мы можем ожидать, что развитие TypeScript, в частности, поддержка им новых типов и языковых конструкций, будет следовать за развитием JS. Язык и система типов будут развиваться параллельно, так как работа над ними идёт одновременно.
Итоги
Мы выбрали TypeScript, так как уверены в том, что сможем быстро обучать всему необходимому новых разработчиков (число наших фронтенд-инженеров утроилось за последний год). Мы уверены в том, что язык соответствует нашим запросам в деле перепроектирования сайта. Кроме того, всё говорит о том, что TypeScript будет существовать ещё долго, а наши изыскания показали, что он хорошо интегрируется с нашей кодовой базой. Однако, для нас самое главное это переход на строго типизированный язык.
Использование типизированного языка уже принесло некоторые результаты. В коде стало меньше ошибок, связанных с типами, мы увереннее выполняем большие рефакторинги. Встроенная документация теперь сосредоточена на концепциях, а не на описании внутреннего устройства объектов и параметров функций. В результате мы можем сказать, что TypeScript — это именно то, что нам было нужно.
Уважаемые читатели! Пользуетесь ли вы TypeScript или Flow?
Комментарии (55)
AstarothAst
24.07.2017 15:28+8После прочтения возникает ощущение, что выбор делался примерно так:
— Flow лучше в этом и в этом, у TypeScript явных преимуществ как бы нет… Но все используют TypeScript, поэтому какого черта?! Ребята, будем использовать TypeScript!
Aries_ua
24.07.2017 21:33Просто типа стильно, модно, молодежно.
Смотрел, TypeScript — не понравилось. Пишем на ES2016. Команде нравится.
Что касамо типизации для входящих данных, то написал небольшой класс, который типизирует данные для последующей передачи в класс, валидатор или для сохранения. Хватает за глаза и незачем тянуть еще кучу всего. Что касамо чтения кода — то в команде договоренность — писать JSDoc для методов и классов.
И добавлю что перешли на async/await и код реально упростился и стал очень простым и читаемым.
slavap
25.07.2017 09:41+5Что конкретно команде нравится? Не писать типы и вместо них писать JSDoc? Или писать «небольшие» классы с валидаторами на каждый чих? Тянуть кучу всего — это о чём?
raveclassic
25.07.2017 10:40+3не понравилось
А что именно не понравилось? И чем в таком случае выигрывает ES2016?
knotri
25.07.2017 10:09+1Как будто хайп это что-то плохое — это означает комьюнити, библиотеки о чем автор в статьи таки сказал.
Rayman2u
25.07.2017 10:49+2Я посмотрел Flow и ужаснулся, когда тот начал проверять все библиотеки в node_modules. Сотни ошибок и предупреждений и на тот момент не было решения для этого, кроме того, чтобы все зависимости добавить в исключения => нет типизации для зависимостей.
Сейчас что то поменялось?
DarkGenius
24.07.2017 15:38+4Так как TypeScript — компилируемый язык, с его помощью можно создавать типы, которые определяются во время выполнения программы.
Что это за типы, определяемые во время выполнения? Насколько мне известно, типы выводятся на этапе транспиляции.
letchik
25.07.2017 09:41Так как TypeScript — компилируемый язык, с его помощью можно создавать типы, которые определяются во время выполнения программы.
TypeScript не компилириуемый, а транслируемый. Кроме того вся информацию о типах на этапе трансляции удаляется. Итоговый JavaScript ничего о типах не знает.mayorovp
25.07.2017 09:55Одно другому не мешает: компиляция есть разновидность трансляции. Раньше считалось что компиляция — это такая трансляция когда на выходе — машинные коды, но появление JVM, CLR и LLVM значительно размыли понятие компилятора.
Кроме того вся информацию о типах на этапе трансляции удаляется. Итоговый JavaScript ничего о типах не знает.
Смотря о каких. Автор же приводит конкретный пример: перечисления. Они остаются в итоговом Javascript.
vintage
25.07.2017 13:58+1Знает, через рефлексию. Специальный флаг компилятора позволяет добавлять немного информации о типах в рантайм. Довольно куцую информацию правда.
slavap
25.07.2017 09:57+1И неожиданно — если в класс Bird добавить любое свойство, например flying: boolean, то Typescript вполне себе успешно ругается на push. Так что дело не в инвариантности, а в том, что не нужно плодить пустых наследников.
raveclassic
25.07.2017 10:43Все верно, просто структурная типизация не сразу в голове укладывается, вот люди и недоумевают.
mayorovp
25.07.2017 10:57+1К сожалению, смесь двух видов типизации до добра не доводит:
class A { foo: string } class B { bar: string } function test(x : A | B) { if (x instanceof A) { console.log(x.foo); } else { console.log(x.bar); } } test({ foo: "Hello, world" }); // undefined
Компилятор мог бы заметить ошибку при проверке типов — но не заметил.
raveclassic
25.07.2017 13:43Дело в том, что такие проверки через
instanceofбессмысленны, так как проверяется не номинальное наследование, а наличие в цепочке прототипа конструктора. Так какA.prototypeне находится в цепочке прототипов{foo: '123'}(что абсолютно верно), то выполняетсяelse-ветка.
Далее из-за, опять-таки, структурной типизации интерфейс классаAидентичен интерфейсу{ foo: string }, поэтомуtestв состоянии принять такой объект вместо инстанса.
Решением будет вместо обычного юниона использовать discriminated с общим ключом.
UPD: Номинальные типы пока на стадии обсуждения
mayorovp
25.07.2017 13:44Решение-то я знаю, но как заставить компилятор выругаться на некорректный код?
raveclassic
25.07.2017 13:53+1Можно вот так:
class A { private __nominal_A: A; //или что еще покруче foo: string; }
Тогда в
testничего не запихнуть, кромеnew A(), но как по мне лучше перестать пытаться писать на TS как на C#.
vintage
25.07.2017 17:19interface Object { __proto__ : this } class A extends Object { foo: string } class B extends Object { bar: string } class C { foo: string } class D extends Object { foo: string } class E extends A {} function test(x : A | B) { if (x instanceof A) { console.log(x.foo); } else { console.log(x.bar); } } test( new C ); // error test( new D ); // ok test( new E ); // ok test({ foo: "Hello, world" }); // errormayorovp
25.07.2017 19:55Не проверял, но если ваши примеры верны, то это ничуть не решение получается:
var d = new D(); d.foo = "Hello, world!"; test(d); // undefined
Druu
25.07.2017 15:16> К сожалению, смесь двух видов типизации до добра не доводит:
Никакой смеси нет. В тайпскрипте только структурный сабтайпинг (на данный момент). В вашем примере по факту, баг occurence typing'а — чекер не должен уметь выводить тип B для х в негативной ветке, только А в позитивной. Впрочем, это могло быть сделано и специально (правильное поведение вынудило бы переписывать ооочень много подобных кейзов).raveclassic
25.07.2017 15:38Почему не должен? Type narrowing вполне себе работает. Если ввести в юнион третий тип, например
class A { foo: string } class B { bar: string } class C { foobar: string } function test(x : A | B | C) { if (x instanceof A) { console.log(x.foo); } else { console.log(x.bar); //error } }
то будет ошибка, так как
barне существует в оставшемся юнионеB | Cmayorovp
25.07.2017 15:44От того что ошибку замаскировали, лучше не стало. Потому что на самом деле в ветке else должно было остаться объединение A | B | C.
raveclassic
25.07.2017 16:06С какой стати? instanceof type guards
Это не ошибка, а ожидаемое поведение при структурной типизации.mayorovp
25.07.2017 16:12+1С такой стати, что из провала проверки instanceof нельзя логически вывести структурное несоответствие типа (что и демонстрирует мой пример).
А тот факт, что подобное нелогичное поведение вдруг стало ожидаемым, и говорит о том, что "смесь двух видов типизации до добра не доводит".
Druu
25.07.2017 16:08+1> Почему не должен?
Потому что такая семантика у instanceof. Из x instanceof A следует, что в х есть поля А, но из того факта, что !(x instanceof A) не следует, что в х нет полей А, иными словами, у нас нету никаких корректных утверждений о типе значения в негативной ветке. Мы не можем утверждать, что в негативной ветке у нас тип !A, а значит, и не можем утверждать, что он A | B — A = B. По-этому narrowing должен быть только в позитивных ветках.raveclassic
25.07.2017 16:25Из x instanceof A следует, что в х есть поля А, но из того факта, что !(x instanceof A) не следует, что в х нет полей А
Из этого следует, что в цепочке прототипов
xестьA.prototype, то есть уxесть поля, перечисленные именно в A. В негативную ветку тогда попадает утверждение, что в цепочке прототиповxнетA.prototype, соответственно вxнет и полей, перечисленных именно в A конкретно для этой ветки. Хотя, если юнион включает в себяAи что-то "еще", то при разнице останется это "еще", даже если оно включает в себя поля изA(повторяющиеся).
Не понимаю, почему это вызывает столько вопросов, объясните, пожалуйста, подробнее?
mayorovp
25.07.2017 16:29Посмотрите еще раз на мой пример. Прототипа — нет, а поля там только из A, полей из B — нет.
raveclassic
25.07.2017 16:36Ну так это же другая проблема.
instanceofсам по себе не проверяет на структурное соответствие, он проверяет на наличие конструктора в прототипе. Соответствие выводится из того, что у вас юнион состоит из классов и вы используете instanceof, проверяющий как раз конструктор. Но я уже написал, что лучше instanceof вообще не использовать, так как снаружи вам всегда может прилететь объект такой же структуры, но не несущий в прототипе нужный конструктор.mayorovp
25.07.2017 16:38Так о том и речь. Из положительной проверки instanceof следует структурное соответствие, а из отрицательной не следует ничего. В языке же почему-то из отрицательной проверки следует отсутствие структурного соответствия...
raveclassic
25.07.2017 16:45Эм. Если у меня юнион из 3х классов, значит объект с типом этого юниона содержит в цепочке какой-то из прототитипов этих конструкторов. Если он точно не содержит один из них (instanceof провалился), почему из этого не следует, что в негативной ветке он уже "содержит один из прототипов оставшихся конструкторов"?
Я правильно понимаю, что вы ведете к тому, что, будь в TS номинальная типизация, то можно было бы не беспокоиться внутри
testо том, что снаружи прилетит объект с той же структурой но без нужного прототипа?mayorovp
25.07.2017 16:51Я не "веду к этому", я об этом сказал в первом же сообщении.
Если мы разрешаем передачу
{ foo: "Hello, world!" }как значения типа A — то нельзя говорить о том, что в значении типа A | B есть хоть какие-то прототип и конструктор!raveclassic
25.07.2017 16:55Но ведь это не совсем так… Мы разрешаем передачу объектов как значения интерфейса
A, тогда какinstanceofпроверяет не интерфейс, а конструктор (то есть реальное js-значение — функцию).
И, понятно, что мы не можем использовать само значение для указания типа аргумента, только его интерфейс (который просто автоматически выводится).
Более того, если вы в юнион вместо классов объедините интерфейсы, вам даже instanceof выполнить не дадут.mayorovp
25.07.2017 17:04Так в том-то и проблема, что из несоответствия конструктора не следует несоответствие интерфейса!
raveclassic
25.07.2017 17:33Правильно, но инстанс конструктора
Aимеет интерфейсA, но не всякий объект с интерфейсом A является инстансом конструктораA.
Тут проблема несколько иная.x instaceof Aвам гарантирует наличие нужных полей, если в цепочке есть прототипA. Более того, можноinstanceofиспользовать на любомobject typeдля любого конструктора, даже не из юниона, тогда тип в ветке условия будет расширен прототипом дополнительного конструктора:
class A { foo: string } class B { bar: string } function test(x: B) { if (x instanceof A) { x.bar; //ok x.foo; //ok } }
С другой стороны, интерфейс
B(а в аргументах идет именно интерфейс, а не конструктор) не гарантирует наличия конструктораBв прототипе, а лишь гарантирует наличие полей изBгде-то, либо на инстансе, либо в прототипе.
Из всего этого вытекает, что, даже если вы принимаете в аргументах объект с интерфейсом
B, вы не можете гарантировать, что где-то в прототипе этого объекта не сидит конструкторA, и, соответственно, что нельзя применятьinstanceof Aдля объекта с интерфейсомB. Именно поэтому тайпчекер разрешает использовать классы не из юниона вinstanceof.
Но если интерфейс
Aобъединен в юнион с интерфейсомB, то в веткеx instanceof Aвы уже рассмотрели интересующий вас случай, когда вам нужны поля изA. А если это произошло, то можно спокойно "вычитать" из юниона поля изA.mayorovp
25.07.2017 19:58Но если интерфейс A объединен в юнион с интерфейсом B, то в ветке x instanceof A вы уже рассмотрели интересующий вас случай, когда вам нужны поля из A. А если это произошло, то можно спокойно "вычитать" из юниона поля из A.
Нет, в ветке
x instanceof Aбыл рассмотрен только случай совпадения прототипа. Но остался случай когда поля из A есть — а прототипа A нету.raveclassic
25.07.2017 21:02-1Ну так если в аргументах
Bкак выше, то вelseи будет толькоB, так как ситуация, когда прототипаAнет, а поля есть, запрещена типом аргумента.
А если там
A | B, то будет вычет, так какA | Bподразумевает наличие полей. В этом месте нет проблемы, код корректный и сужение типа тоже корректное.
Проблема в том, что компилятор позволяет запихнуть в функцию структурно идентичный объект. И то, это не проблема, а особенность структурной типизации.
Пока что же, сужение в ветках с
instanceofмне видится вполне валидным, так как тип аргумента функцииtestявно указывает на наличие полей.
Но я согласен, что это неудобно, неочевидно и нужно всегда про это помнить. Поэтому я просто не использую юнионы из классов и instanceof.mayorovp
25.07.2017 21:10Ну так если в аргументах B как выше, то в else и будет только B, так как ситуация, когда прототипа A нет, а поля есть, запрещена типом аргумента.
В том-то и дело, что такая ситуация не запрещена.
Druu
25.07.2017 17:05> Из этого следует, что в цепочке прототипов x есть A.prototype, то есть у x есть поля, перечисленные именно в A.
В Тайпскрипте нет такого отношения. A < B => А содержит все поля B. Проверка типов для instanceof не может проверить что-либо кроме этого, потому что на уровне типов тайпскрипта ничто иное невыразимо. По-этому soundness чекер не должен выводить ничего для негативной ветки. Но в тайпскрипте намеренно жертвуют soundness ради удобства и более простой типизации существующего кода и привычных для жс паттернов, так что вполне возможно, что и тут оно — by design.raveclassic
25.07.2017 17:34Ну как же нет, вон я выше показал пример, когда использование
instanceofна дополнительном конструкторе расширяет тип в ветке интерфейсом этого конструктора.Druu
26.07.2017 01:55-1Не интерфейсом, а _его полями_. В тайпскрипте нету номинальных типов. Нигде нету. И instanceof типизируется структурно (как и все остальное), по наличию полей, а не номинально. Утверждения вида «Х реализует интерфейс А» невозможно выразить на тайпскрипте. На уровне типизации нету никаких классов, интерфейсов и прототипов вообще. Есть только типы, которые либо содержат какие-либо поля, либо не содержат. Единственные утверждения, которые вы можете делать на тайпскрипте: «Х содержит поле Y».
raveclassic
26.07.2017 09:27Вы придираетесь к словам, понятно же, что типизация структурная.
Окей, для веткиif (x instanceof A),xсодержит все поля интерфейса A. Так лучше?Druu
29.07.2017 02:49+1> Вы придираетесь к словам, понятно же, что типизация структурная.
Это не придирка к словам, это то как работает алгоритм тайпчека (и от этих «придирок» он будет работать с разным результатом)
> Окей, для ветки if (x instanceof A), x содержит все поля интерфейса A. Так лучше?
Да, именно это утверждение формулируется на уровне типов. Но, вот проблема, сам instanceof в рантайме поля не проверяет. По-этому мы можем быть уверены в том, что в позитивной ветке поля есть. Но не можем быть уверены в том, что их нету в негативной.
kvaps
Уж кому как ни reddit стоит рассказывать об успехах frontend разработки :)
Boomburum
Комментарий выглядит как намёк добавить тег irony )
VioletGiraffe
Таки да, Reddit — визуальная каша нечитаемая. Лучше б «украли» концепцию у Хабра, тут ориентироваться на порядок проще и приятнее.
Milein
В чём ориентироваться-то?
На хабре пишут статей в день, сколько тем создают в 10 минут в активных сабах реддита.
И комментариев тут чаще всего не больше пары десятков, редко пара сотен, а на реддите на тысячи счёт идёт бывает.
Не подумайте, я не заявляю что реддит идеален (иначе бы не было того же RES), но «ориентируйтесь на сайт в котором весь контент за день обычно можно пролистать за 10-20 минут» это несерьёзно.
apro
В тему frontednt,
а в reddit действительно нет пред просмотра комментариев или я что-то упускаю?
Milein
Перед публикацией? Судя по всему нет. Но есть с RES (Reddit Enhancement Suite).
dom1n1k
Огромное число раз видел ссылки типа «анонимус запостил нечто на реддит и развернулась активная дискуссия» — перехожу посмотреть, а там 10-20-30 комментариев. Ураган прямо! Один из самых популярных сайтов мира, однозначно. Бывают, конечно, действительно активные топики — но редко.
Milein
Так всё зависит от популярности тематики.
Но это как бы нормально, чем более нишево, тем меньше дискуча. Да, есть темы, которые на реддите обсудить затруднительно, аудитория видимо там не сидит нужная. Но всё хоть сколько-то мейнстримовое — угу, ураган.
Но вообще да, ~9-ый по популярности сайт в мире, чего ёрничать-то.
justboris
Мобильная версия у них вроде ничего.
Но с десктопа на нее не попасть, редиректит на большую.