> Скорее отсутствие подробных данных в объявлении снижает привлекательность лота

У нас на митапе ребята из Авто.РИА (apelsyn) делились информацией, что так оно и есть.

$7 экономии, если из расходов только эти $7 — действительно, не так уж и много, но если их совместить с остальными небольшими расходами — получится $50+ в месяц, а это уже, согласитесь, немало. Конечно, для лида-архитекта, который получает $7-10k это копейки, но большинство, всё таки, зарабатывает гораздо меньше указанного.

А как открытый репозиторий заставит автора поддерживать именно открытую версию, а не ту, которую он создал закрытой на базе существующего кода? :)

Наблюдаю со стороны за развитием браузера. Сейчас он уже совсем взрослый :)

Тем не менее, есть открытые вопросы, на которые не смог найти ответа на сайте:

1) Когда ожидается мобильная версия? Сейчас больше 40% трафика — мобильный (http://gs.statcounter.com/platform-market-share/desktop-mobile-tablet). Для меня, к примеру, пользоваться одним браузером на используемых мною платформах — критично. Не нашёл роадмапы :(

2) Планируется ли OpenSource? :)
О преимуществах и недостатках, думаю, рассказывать нет смысла.

3) Выше упомянули, что планируете писать собственное ядро на замену Chromium. В свете последних событий (миграция M$ Edge на Blink), почему бы, и правда, не поддержать открытость? Как вы верно заметили, развивать Chromium «со стороны» достаточно таки проблематично. Firefox последних версий очень и очень хорош.

Спасибо.

Честно говоря, не могу придумать ни одного кейса, когда в Реакте необходимо наследование, кроме наследования от Component/PureComponent.

> this.stopTimer = this.stopTimer.bind(this);
> this.resetTimer = this.resetTimer.bind(this);

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

class MyComponent extends PureComponent {
  state = {
    stopped: false,
  };

  stopTimer = () => this.setState({ stopped: true });

  render() {
    return (
      <button onClick={this.stopTimer}>Астанавитесь!</button>
    );
  }
}

> для этого добавим установку document.title в метод render():

Какой ужас :)

Здесь лучше подойдёт componentDidUpdate, потому что рендер может вызываться бесчисленное количество раз в зависимости от различных условий и всё, что он должен делать — возвращать новый VDom, за счёт чего «лишний» рендер будет менее дорогим.

Воистину, нет лучшей цензуры, чем самоцензура.

Юзали это на предыдущем проекте. Чертовски удобно использовать объект в качестве аргумента, особенно на стыке модулей.

Имею похожий опыт с RN.

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

Пообещал друзьям написать приложение для их небольшой компании, выбирал тулкит. Поклепал концепты на разных технологиях: Cordova, NativeScript, ReactNative, Java (Android). Как бы ребята из Facebook не обещали «почти нативный перформанс», у них ничего не получилось. Библиотеки роутинга кривые, анимации странные, FlatList и компания тоже подтормаживают.

С NativeScript опыт получше, там реально чувствуется, что «почти как нейтив», но на момент существования концепта моего приложения оно подглючивало и не хватало описаний .d.ts для нативных методов и классов.

В итоге решил остановиться на Java, поскольку приложения 100% нейтив, не тормозят и скорость разработки не настолько сильно и упала (если вычесть, что я ранее не делал ничего для Андроида).

Со своей стороны могу порекомендовать вам посмотреть на проект от Google — j2objc, если много бизнес-логики. Ещё есть kotlin.native, но он пока в зачаточном состоянии, так что на свой страх и риск :)

Играл как-то в демо-версию Factorio. Было очень интересно и жутко не хватало расширенного контента. Купил её через Steam, начал играть и как-то запал сразу пропал. Поиграл полтора часа и оформил возврат, в причине возврата так и написал: в демке было круто, а в полной версии оказалось не фаново. Деньги вернули.

Конечно, пользовался я таким всего раз, так что не знаю, может это скорее исключение, чем правило.

> если в течении 15 минут удаленный сотрудник не вышел на связь в рабочее время

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

Не хочу вас огорчать, но на моём домашнем компьютере $mol фризится (не тормозит, а именно фриз на некоторое время) при обновлении чисел, в то время как React работает адекватно.

Да, это я понимаю. Но зачем заставлять придумывать уникальный ID (пусть даже сгенерированный или полученый любым другим способом), если этого можно не делать? Тем более, что сам фреймворк (можете кидать тапками) предоставляет инструмент, который гарантированно будет работать в любых условиях?

Не могу судить, насклько vue-матичен код в статье, но вместо

const element = document.getElementById(this.name)

лучше использовать ref

vuejs.org/v2/api/#ref

Как минимум, это позволить разместить более одного компонента на странице.

Прочёл дальше этот тред.

Вы немного ошибаетесь, поскольку в статье речь идёт о доступности (это когда человек, к примеру, не видит и пользуется скрин ридером, соответственно, остаётся только клавиатура в его распоряжении), а не о запрете выхода из модалки без тыканья в кнопку табом.

А у меня в проекте встречается даже такой код, и мне от этого немного грустно:



А ещё половина кода использует styled components, а половина — scss. И целая горка других проблем и нюансов.

Из-за этого немного смотрю в сторону vuejs (как минимум, не будет styled component и scss каши), но проектов таких пока в наш офис не заходило.

Типизация

Вдруг, кому пригодится.

Далее подразумевается, что используется Flow. Там, вроде бы, есть описания типов, но у меня не удалось их завести. Получилось многословно, но лучше так, чем вообще без. Делал как-то так:



P.S. потерял веру во Flow, потому что на практике он оказался глючноватым. Вернее, не сам Flow, а сопутствующие средства разработки: опробовал WebStorm и VS Code с разным уровнем успеха. Последний некоторое время даже работал. Потом отвалился. Такие дела.

Данный бенчмарк, как верно заметили выше, измеряет скорость взятия одного файла с одного диска.

Преимущество асинхронных IO запросов раскроется только если одновременно читать/писать файлы с разных дисков, разных сетевых подключений и так далее.