• Я так хотел попасть в программный комитет конференции, и вот я здесь, и что мы будем делать?
    +1
    У меня одного ощущение, что статья насквозь негативная по отношению к людям, которые подают заявки на доклады? Типа как «100 и 1 причина отфутболить заявку».
  • PHP-Дайджест № 146 (10 – 24 декабря 2018) + Итоги 2018 года
    +3
    Нравится тесная интеграция с консолью базы данных, что понимаются запросы прямо из кода.
  • Книга «React в действии»
    +1
    Теперь, создав редуктор комментариев...

    Серьёзно? В книге такой перевод? Господин технический редактор книги хотя бы раз русские ресурсы открывал на тему книги?
  • Mail.Ru назвала «абсурдным» рейтинг сайтов от «Яндекса» и требует удалить из него свои бренды
    +4
    Ой. Кажется, Яндекс ровно такой иск таки выкатывал. И даже выиграл.
  • Ищу senior'а без офиса и печенек: как у нас организован поиск сотрудников на 100% удаленку
    0
    Извините, вопрос такой — вот у вас есть экономия по сравнению с организацией офиса, а уровень компенсации сотрудникам ниже рынка. Вы считаете, что это нормально? Или у вас настолько высокие риски по удаленке, что вы автоматически используете понижающий коэффициент к эффективности ваших сотрудников?

    И еще, нередки случаи, когда за плохо (по мнению руководителя) или не в срок (по мнению руководителя) сделанную работу удаленщикам не платят зарплату. Как у вас с этим? Ваша фирма «кидает» своих сотрудников на деньги? Как у вас происходит арбитраж в этих случаях?
  • Стриминг видео через браузер со сверхнизкими задержками (и WebRTC!)
    0
    Расскажите лучше, что у вас со screen sharing? Если есть. И как побороть hall of mirrors?

    PS Про переводы — на webrtchacks материалы поинтереснее, переведите например про игровую площадку для Simulcast без сервера.
  • Логирование активности с использованием Web Beacon API
    0
    Сценарий, когда этот API очень полезен — очевиден, уведомить сервер, что пользователь ушел со страницы. Раньше это делалось хаками (которые тоже не всегда помогали). Применимость — автор передергивает, проблема не только с IE, сафари только-только научился (с 11.1 на десктопе, и 11.4 на мобиле, — в конце марта 2018). И в как минимум в 11.1 всплывают иногда непонятности (ведет себя неадекватно порой, падая с исключением).
  • В защиту ООП. 7 несостоятельных аргументов его противников
    0
    Одна из существенных проблем ООП, кмк, — реализация операций. То есть на классическую парадигму оно очень плохо ложится. Сложение чисел или конкатенация — тому яркий пример: objA.plus(objB) или objB.plus(objA)? (я в курсе про хелперы, но их существование не укладывается в классическую парадигму).

    И тут же всплывает еще один очевидный вопрос — операция должна вернуть новый объект или модифицировать существующий? В этом месте у ФП есть положительная сторона — идеология топит за иммутабельность всегда.

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

    Наследование — тоже хорошо там, где оно уместно. Проблема только в том, что оно резко сжимает пространство маневра при разработке сложных систем, композиция гибче. В реальной жизни мы используем одни и те же предметы как принадлежащие разным иерархиям наследования, просто не задумываемся об этом. В ООП же объект может принадлежать только одной иерархии (про cpp в курсе).
  • Дайджест свежих материалов из мира фронтенда за последние две недели №323 (8 — 22 июля 2018)
    +3
    Поддерживаю, с возвращением! Уже в телеграме начали обсуждать, не случилось ли с составителем что-то.

    Вы делаете большую и нужную работу, спасибо вам огромное.
  • Re: «Сравнение JS-фреймворков: React, Vue и Hyperapp»
    +1
    Про Vue примеры некорректные, для столь простого кода никто не будет писать рендер-функции. Образец идиоматического кода для первого примера тут, про второй вам уже сказали, шаблон был бы такой:
    <template>
      <div>
         <button @click="getData">Get posts</button>
         <div v-for="post in posts" :key="post.id">
           <h2>{post.title}</h2>
           <p>{post.body}</p>
         </div>
       </div>
    </template>
    
    <style scoped>
    h2 { color: #3AC1EF; }
    </style>
    


    И для третьего примера шаблон такой:
    <li :class="{done : done}" @click="toggle(id)">{{value}}</li>
    

    И в svelte у вас пропсы вообще не описаны — непонятно, должно ли описание быть, и как должна IDE подсказки делать при использовании компонента.

    А вообще интересно, расскажите, как там с отладкой дело обстоит? Дев тулы? Стейт менеджмент? Роутинг?
  • Сравнение JS-фреймворков: React, Vue и Hyperapp
    0
    Про render props во вью — там есть концепт scoped slots; с HOC же всё настолько печально-неудобно, что ой (кратко — очень сложный createElement вызов, очень много всего прокидывать).
  • Сравнение JS-фреймворков: React, Vue и Hyperapp
    0
    Весь шаблон обернут в with от контекста. Т.к. шаблон во втором вью сначала компилируется в JS, а затем используется. Причем компилятор — опциональный в сборке (если использовать single file component, то шаблоны уже будут в виде JS в бандле, ровно как в реакте). Фактически шаблоны во втором vue.js — сахар над рендер-функциями.
  • Антисобеседования
    0
    С точки зрения кандидата жалко тратить время на тестовое на какую-то компанию в списке из минимум десятка плюс-минус одинаковых, чтобы получить приглашение на собеседование. То есть для меня лично это показатель, как компания относится к сотрудникам — т.е. не ценит их время от слова совсем. Такие запросы сразу в отказ.

    Позитивно в этом смысле у яндекса — часовой преселект, где решают, дальше общаться с кандидатом, или оно того не стоит.
  • САМЫЙ главный паттерн в программировании
    +2
    То есть по вашему ООП — единственная парадигма, в которой можно создавать сложное ПО? Без ООП жизни нет?
  • Мышление в стиле Ramda: Неизменяемость и объекты
    0
    prop('birthCountry') — это функция от объекта, которая берет у него свойство с именем birthCountry
    Упрощенно можно было бы написать эту функцию так:
    const prop = propName => obj => obj[propName]
  • Реактивный фронтенд. История о том, как мы снова всё переписали
    +1
    Яндекс знатные почитатели NIH синдрома. create-react-app — не, сделаем своё. Nightwatch? Не, сделаем своё. Фреймворк? Не, своё. Потом, правда, выкинем, и будем пользоваться React.
  • Почему мы ещё читаем бумажные книги?
    0
    Поддерживаю, первая книга, которую заморочился подчистить и напечатать книгой.
  • Символы, генераторы, async/await и асинхронные итераторы в JavaScript: их сущность, взаимосвязь и варианты использования
    +1
    Правильно бы назвать это Multiton
  • Гари Хадсон – об удалении сенесцентных клеток и лечении рака
    0
    Если так, то смерть — это симптом.
  • Как я начал любить Vue
    +1
    Не воспринимайте это так всерьез, никто на тайпинги не покушается :)
  • Как я начал любить Vue
    0
    Vuex — мы не используем TS, и очень досадно, что комбинация IDE+Vuex при появлении тайпингов стала доставлять неудобства. Простой и короткий PR — это удалить тайпинги? :)
  • Как я начал любить Vue
    0
    Прям даже завидно. По тому, что я рассказываю про миксины — у нас оттоптались по граблям по полной. Проекту уже 2.5 года, начинался еще с 1.0 версии.
  • Как я начал любить Vue
    0
    Можно еще вопрос оффтопный, а сколько лет вашему проекту на Vue? И какое количество разработчиков? Просто грабли с миксинами у нас выросли после полутора лет, поначалу тоже всё было (казалось) радужно.
  • Как я начал любить Vue
    0
    То есть миксины нативно поддерживаются какой-то IDE? Для той же функциональности я сейчас предлагаю использовать такое:
    import { someReusableMethod } from './mixins';
    
    export default {
      methods: {
        someReusableMethod,
        someOtherMethod() { /*... */ }
      }
    }
    


    И ваш пример с extends mixin() несколько лучше, но классика множественного наследования — если два миксина пересекаются по именам, из какого унаследуется реализация? Как мне понять, из какого места прилетела реализация, если всё, что в компоненте есть — this.someMethod()?

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

    Про магию — в контекст прилетает масса странного, что непонятно откуда берется. Vuelidate -> this.$v, I18N -> this.$t, Vuex -> this.$store, Router -> this.$route, был еще vue-resource -> this.$http. Конкретно в компоненте это и есть магия, когда «ниоткуда» появляется нечто. Впрочем сама модель построения фреймворка такая. Это «easy, not simple». Само конструирование инстанса из частичек конфигурационного объекта, сборка в единое всех этих computed, data, methods, watch — из-за чего с вычислением this такие проблемы — по сути разновидность магии.

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

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

    Качество тайпингов — извините, но минимум сам Vuex вот такой — то есть одна из основных библиотек экосистемы. То, что вам докблоки не нужны — ок, верю, но это не значит, что они никому не нужны. Бегать в онлайн документацию чтобы уточнить порядок аргументов и какие принимаются — надоедает.
  • Как я начал любить Vue
    0
    Не совсем манки патчинг, но всё равно бяка. Манки патчинг в чистом виде — это как плагины ставятся :) Тот же vue-i18n
  • Как я начал любить Vue
    +1
    Из JS. Во vue.js такое сплошь и рядом — все мапперы из Vuex например. шторм 2018.1.
  • Как я начал любить Vue
    +1
    По некоторым пунктам автор излишне оптимистичен.

    Структурирование кода — миксины зло. Они затрудняют понимание кода компонента, при не очень строгом код ревью разные миксины используют друг друга, и появляется неописуемая лапша. Правда в том, что это сложно проконтролировать. Проще вообще запретить их использование (как по факту сделано в реакте).

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

    Магия везде — по коду компонента в шторме минимум сложно понять, что откуда прилетает. Мапперы на vuex не навигируются нормально. Магии в связке react/redux — ощутимо меньше.
    Маппинг по-разному работает, где-то можно писать имена с неймспейсами, где-то нельзя.

    VirtualDOM — вызов создания VNode настолько развесистый, что HOC становится лютой экзотикой. Очень много всего транслировать. Сравните с HOC в реакте.

    Отдельная хрень — этот ваш TypeScript. То есть сам по себе он норм (хотя наш проект его не использует). Но! В шторме есть такая замечательная штука — Ctrl+Q, и навигация в код зависимости. До поры-до времени всё было ок, пока в библиотеках массово не стали завозить TS тайпинги. Докблоков в них нет, Ctrl+Q фактически умер, переход на код перебрасывает в тайпинг, и приходится по дереву зависимости руками искать реальный источник. Вот так TS уничтожает существующую экосистему.

    Отдельно про TS применительно к Vue. Нормального вывода объектного контекста, как я понимаю, до сих пор нет (не особо слежу, но наличие двух разных способов прикрутить TS говорит за это). Фокусы с модификацией инстанса внешними плагинами жизнь для TS не облегчают — this.$somePlugin.xxx.zzz.ttt. Как с TS нормально уживается this.$refs.xxx — вообще загадка. Про дублирование деклараций пропсов уже решено?

    Про внутренности Vue.js — не пинал только ленивый. Эван со товарищи конечно крутой, но недокументированный код — не круто. Back to VDOM — было удивительно узнать, что оно заимствованное из другой библиотеке. Просто как-то не афишируется. Сейчас начинают наконец-то появляться статьи о внутреннем устройстве фреймворка, это радует.

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

    const resource = (url, method = 'get') => (params = {}) => axios({ url: typeof url === 'function' ? url(params) : url, method, ...params });
    
    export const resourceUsers = resource('/api/users');
    export const resourceUpdateUser = resource(({ id }) => `/api/users/${ id }`, 'patch');
    };
  • Комментарий из публикации, перенесённой в черновики.
  • Комментарий из публикации, перенесённой в черновики.
  • Дайджест свежих материалов из мира фронтенда за последнюю неделю №311 (16 — 22 апреля 2018)
    +2
    Ребята, вы потеряли смысл в переводе «Точка зрения: Angular обречен, React OK — вы заслуживаете лучшего» — так как статья называется «Point of Vue: Angular is doomed, React is OK — We deserve better» (Vue.js — третий фреймворк в рамках статьи).
  • Бешеные псы: Angular 2 vs React
    +1
    Судя по звездам на гитхабе, AngularDart даже более маргинальный, чем Clojurescript-React (разница на порядок), чем ReasonML+React (разница вдвое), и примерно вровень с Elm-React (при том, что у Elm уже есть встроенные средства работы с DOM).

    Собственно про Dart ещё настораживает, что в России ровно одна контора производит всю движуху вокруг него.
  • Бешеные псы: Angular 2 vs React
    +3
    Мне больше вот этот пассаж понравился:
    Языки. На Angular можно писать на JavaScript, на TypeScript, на Dart, на Flow — на чем хотите.

    В реалиях варианта, насколько я понимаю, ровно два — Typescript и Dart, на них оно нативно работает. Новичок помрет, раскуривая A на обычном JS (или тем более Flow). То, что это «можно» сделать — ничего не говорит о сложности. По языкам/диалектам, которые нормально поддерживаются, я думаю React далеко впереди. Варианты: JS ES5 (как там у ангуляра?), JS ES6+, Flow (очень странно автор пишет это только ангуляру, хотя инструмент затачивается под React), Typescript, Elm, ClojureScript, ReasonML.

    То есть объективно для широкой публики нормально поддерживается в ангуляре только TS (Dart маргинальный), в реакте — обычный JS и JS+Flow, и тот же Typescript (маргинальные Elm, Clojurescript, ReasonML в расчет не берем).
  • Операционная система на JavaScript? JsOS
    0
    Небольшая неточность — серверы Netware были afair вполне standalone OS. И DOS не требовали. DOS — это клиентская часть вроде.
  • О главнейшей причине существования современных JS-фреймворков
    +3
    Есть страшное подозрение, что чувство баланса по применению инструментов — а) очень индивидуальное; б) нарабатывается исключительно опытом, когда есть навык и жукверей и условных реактов/ангуляров/etc.

    ЗЫ А вообще на такую тему на хабре писать — верный хабра[роскомнадзор]. Загрызут. Такое только на медиуме.
  • Как стать фронтенд-разработчиком в 2018 году
    0
    Приведены графики сложности, но самая мякотка — вот:
    Кривые обучаемости, представленные ниже, построены с учётом того факта, что разработчик уже знаком с TypeScript и RxJS.

    То есть для ангуляра больше половины айсберга просто вынесено за скобки.
  • Разбор перформансных задач с JBreak (часть 4)
    0
    И еще одно — лобовая реализация описанного в ассемблере скорее всего будет эффективнее безумных портянок кода, сгенерированного двойным преобразованием java -> bytecode -> native code. Учим асм?
  • Классы и фабричные функции в JavaScript. Что выбрать?
    0
    А можно от последнего подхода сделать еще один шаг и перестать связывать функции и данные в объекты, и перейти к функциональному подходу, если уж так хочется. Тогда this вообще исчезнет как понятие.
  • Строгая типизация для приложений Vue.js на TypeScript
    +2
    А что, имя автора кода как-то гарантирует, что конкретный его код — хороший? Если он не очень знаком с фреймворком, ожидаемо что он может писать криво. Сразу из стартера — общепринято бить по рукам, если data является объектом, а не функцией, возвращающей объект. Впрочем остальное в стартере выглядит опрятно.

    Образец на vuejs.org, куда вы ссылаетесь — лохматого года, и явно не Typescript. Вы его портируете, и остальные лохматости оставляете как есть. Причём там есть извиняющая причина (не факт, что браузер свежий), а у вас её нет (т.к. компилятор TS обязателен).

    К слову, Эван, при всём к нему уважении, зачастую пишет/выкладывает невменяемый код. С документированием кода во всей Vue.js экосистеме (включая сам фреймворк) очень плохо всё. Как пример, можно смотреть на vuex. И сравнить его с redux. Оцените например как реализован vuex хелпер mapGetters (то, что вчера пришлось смотреть).
  • Строгая типизация для приложений Vue.js на TypeScript
    +1
    Очень хорошо, что кто-то пишет на русском про TS применительно к Vue.js. Но остальное…

    Про «строгую» типизацию в TS, где есть any и нет soundness — вам уже сказали.

    Построение — мне лично кажется что class MyComponent extends FrameworkName {… } — семантически кривой конструкт. Сравните с:
    class MyComponent extends React.Component {… }

    Извините, но от кода просто кровь из глаз. Как будто ES6 прошел мимо, к чему такая многословность?

    Сам Vue.js очень «волшебный» фреймворк, а вы ему еще магии добавляете. Официальный стайл-гайд требует, чтобы для фреймворка явно описывались типы свойств компонента. У вас — массив. Исправляем, делаем явно — и получаем дубликат описаний, то есть еще хуже.

    Вот так вообще писать нельзя, динамически меняющиеся свойства статикой упихиваем в data секцию:
    data: function () {
            var sortOrders: any = {};
            (this.$props as DemoGridProps).columns.forEach(function (key) {
                sortOrders[key] = 1
            })
            return {
                sortKey: '',
                sortOrders: sortOrders
            } as DemoGridData
        }
    


    Для этой цели есть секция computed.
  • Веб-разработка – с чего начать?
    0
    Весь код на Java

    Вопросов больше не имею. Подавляющее большинство JS программистов такой роскоши себе позволить не может. А как только вы сталкиваетесь с JS-зависимостями, весь ваш ООП из Java потенциально идет в топку. См. например печально известный манки-патчинг (про smoosh-гейт слышали из последнего?)

    PS Не скажу за GWT, но скажем Vaadin то еще дерьмо.