• Хеви-метал оболгали: на самом деле тяжелая музыка положительно влияет на здоровье своих поклонников
    0
    а вот не факт… Мне кажется что тот же Блюз не особо вдохновлен классикой. Изначально это была музыка черных и врятли они много классики слышали
    Но утвердждать не буду
  • Хеви-метал оболгали: на самом деле тяжелая музыка положительно влияет на здоровье своих поклонников
    0
    предпочитающие напряжённую, мощную и неординарную музыку


    а как ученые определяли неординарную и ординарную музыку?
  • Темный день для Vue.js
    –1
    Svelte интересен концепциями, но не более. Можете посмотреть доклад Ильи Климова на эту тему, достаточно содержательно и отвечает на вопрос, почему у Svelte мало шансов занять большую нишу
  • Темный день для Vue.js
    +2
    вы немного отстали от жизни) давно уже не выходит «по фреймворку в неделю».
    Три основных игрока уже давно закрепились. React/Vue/Angular.
    И обратную совместимоть давно никто не ломал. Да и Vue 3 ее не ломает.
    Хотя мажорная версия имеет на это полное право
  • Темный день для Vue.js
    0
    В JS врятли появится типизация. Так как в рантайме она не нужна. Да и зачем тащить лишний код в браузер когда можно все проверить на этапе сборки?
  • Темный день для Vue.js
    +1
    А при чем тут typescript если речь о JS фреймворке? Поддержка фремворком ts это лишь дополнительная плюшка.

    А на счет того что typescript начнет противоречить стандарту ES — тоже весьма сомнительно. Ведь он изначально позиционировался как надмножество над ES.
    Пока правда не понятно как они будут выкручиваться из данной ситуации с декораторами
  • Введение в пользовательские CSS-свойства
    0
    К примеру вот такого на препроцессорах не сделаешь.

    .icon {
      --size: 18px;
      
      width: var(--size);
      height: var(--size);
    
      @media (max-width: 400px) {
         --size: 16px;
      }
    
    }
    


    Плюс не забыаем, что css в браузере отлично управляется через js. А значит мы можем меня ть значения каких-либо css переменных в рантайме
  • Введение в пользовательские CSS-свойства
    0
    нет общепринятых правил. Есть правила принятные на конктретном проекте, не более. Плюс подходы типа CSSModlues лучше работают именно с camelCase нотацией
  • Готовим идеальный CSS
    0
    1. Мы выиграем мы немного процессорного времени… но зачем? Если в приложении есть страница где так много стилей что это начинает играть роль, то скорее всего проблема в самом коде. Если существующий код оправдан, то это уже очень специфичный кейс

    2. Нет css, нет js. Есть компонент. Если правите что-то — то вы правите компонент. И его стоит загрузить заново.
    Если у вас при правке компонента переобсирается css на 5МБ, то опять же это уже проблема организации кода.
  • Готовим идеальный CSS
    +1
    Можно вынести CSS в отдельный файл для раздельного кэширования JS и CSS


    А зачем вобоще кешировать js и сss отдельно? Компонент это не js и не css, это все вместе. Разбиваем на чанки — кешируем чанки.
  • Лучше, быстрее, мощнее: styled-components v4
    0
    если вам что-то не нужно, не значит что это не нужно другим.

    Это отличный инструмент, со своими плюсами и минусами
  • Лучше, быстрее, мощнее: styled-components v4
    0
    styled-component работает не через inline стили, а генерит css-классы которые и прокидывает в элементы
  • CSS-in-JS — мифы и реальность (на примере styled-components)
    0
    При использовании BEM вам никто не помешает в разных компонентах, случайно заюзать одно имя класса более одного раза…
    С SC этой проблемы вообще не возникает
  • Использование промисов в JavaScript
    0
    Во первых, статья про язык, а не про то где какие его фичи поддерживаются.

    Во вторых, это не проблема, берете babel и вперед.
  • Использование промисов в JavaScript
    0
    Дак вроде как это вошло в уже в ES2018
  • Как прятать
    0
    И чем это отличается от opacity: 0? Opacity просто делает элемент прозрачным (или полупрозрачным), а visibility: hidden ещё не даёт с ним взаимодействовать: навести, кликнуть, сфокусировать.


    Так же что стоит заметить, что opacity создает новый контекст для расчета z-index. Плюс opactity можно анимировать
  • Комментарий из публикации, перенесённой в черновики.
  • Современный найм — отстой
    +4
    как то вы недооцениваете сложность современного фронтенда
  • Способы организации CSS-кода
    0
    Вот и назвать его надо ico-leftpanel


    Вот только завтра приходит дизайнер и переносит вашу левую панель на право, а ваши иконки по прежнему содержат в себе leftPanel
  • Коллбэк в JavaScript… Что за зверь?
    +1
    при чем тут fetch?
  • Коллбэк в JavaScript… Что за зверь?
    –2
    Вот только сами промисы создаются с передачей в конструктор фукнции в качестве параметра. То есть — callback

    element.addEventListener('click', ()=> {...}) 
    

    на промисы или async/await как будете переводить?
  • Node.js и cote: простая и удобная разработка микросервисов
    +2
    Не силен в микросервесах, да и в бекенде тоже… Но разве микросервисы не подразумевают, что любой микросервис в системе может быть написан на любой технологии и языке? И пока нет реализции cote на других языках и платформах, использовать его для создания большой системы будет проблематично?

    А в целом за статью спасибо. Интересно
  • Больше, чем React: Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов
    0
    По-моему отличная статья!

    Правда для 1-го aпреля.

  • JavaScript. Вопросы на собеседовании
    0
    в последний версии Chrome уже нет этой проблемы — пример рабочий
  • Стилизация React-компонентов
    0
    Смотрели, не понравилось.
    Написали свое react-bem-classes — может кому понравится
  • Пробрасываем роуты Angular 2 через роутер Laravel 5
    0
    Никто и не говорил про разные домены. На каком домене это все крутиться вообще не при чем. Мы говорим о разбиении на два логический проекта(на уровне репозиториев)

    Бессмысленное для пользователя генерирование на сервере html с данными при старте каждой сессии

    Не бесмыленное — визуально перформанс растет. C сервера приходит уже готовый html
    плюс такие страницы индексируются поисковиками

    Лишний блокирующий загрузку всего остального запрос за html, которого могло бы и не быть.

    нода не блокирует загрузку за счет асинхроности js

    Невозможность выложить на статический сервер типа github.io.

    и? сколько страниц в интернете генерится, к примеру, php их тоже нельзя выложить

    Невозможность без плясок с бубном завернуть в cordova или chrome app.

    лично заворачивал в cordova приложение где фронт был написан с прослойкой на node (c reactjs) — проблем никаких. Потому что фронт умеет рендериться там где есть js

    Костыли для обеспечения кроссбраузерности.

    при чем тут нода?

    Невозможность раздачи через CDN

    аналогично с "невозможность выложить на статический сервер типа github.io."

    Плюс выноса фронта в отдельный проект в том, что сам фронт и решает каким ему быть после сборки — статикой или легким nodejs сервером. Он никак не завазян на язык/фреймворк бекенда. Мы можем переписывать любую часть, другой это коснется

    Он полностью абстагирован от бека, как бы это было например с iOS или Android приложением.

    Я уж молчу на сколько это удобно когда бекендерам вообще не приходиться думать, о html/css/js файлах — в их репе их просто нет.
    А фронтедрам не нужно поддерживать локальную версию бека, заботиться о миграциях, установки зависимотей бекнда и так далее. Они спокойно забирают данные с удаленного сервера и все. + Всегда могут локально просить данные с продакшен сервера(ведь часто баги появляются именно на рабочем контенте)

    На эту тему советую почитать вот эту статью https://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/
  • Пробрасываем роуты Angular 2 через роутер Laravel 5
    0
    "чёткое разграничение зон ответственности" — как раз таки будет разбиения проекта на два отдельных =)

    "Сами по себе они отрендериться на сервере не смогут" — для этого есть nodejs

    "куча проблем с кешированием" — при полноценном серверном рендере страницы не статичны, а в случае если вы отдаете браузеру просто пустой html-заглушку то это не большая проблема, так как все "большие" части(js/css) все равно закешируются
  • Пробрасываем роуты Angular 2 через роутер Laravel 5
    0
    решени с решеткой это не изящное решение, решетка для браузера это якорь к которому нужно проскролить страницу после ее загрузки, а никак не часть роута.

    History Api придумали не просто от нечего делать.

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

    Ваше решени это просто костыль и использование инструментов(решетки в урле) не по назначению
  • Пробрасываем роуты Angular 2 через роутер Laravel 5
    0
    я не могу предоставить вам рабочий кусок кода, потому что я не знаком с данным фреймворком но примерно это может выглядеть так (пcевдокод)

    Route::get('/templates/{template}', [
        'uses' => 'MyApp\AngularTemplatesController@index',
    ])
    
    Route::get('/templates/{template}', [
        'uses' => 'MyApp\AngularTemplatesController@index',
    ])
    
    Route::get('/assets/*', [
        'uses' => 'MyApp\staticController@index',
    ]);
    
    Route::get('/api/*', [
        'uses' => 'MyApp\apiContoller@index',
    ]);
    
    Route::get('*', [
        'uses' => 'MyApp\IndexHTMLController@index',
    ]);
  • Пробрасываем роуты Angular 2 через роутер Laravel 5
    0
    "определить какие урлы должен обрабатывать бекенд(статика, api) все остальное уже "редеректить" на html где урл подхватит клиент"

    чем не решение?
  • Пробрасываем роуты Angular 2 через роутер Laravel 5
    +1
    Даже если оставлять все один проектом, то есть решени куда лучше:
    определить какие урлы должен обрабатывать бекенд(статика, api) все остальное уже "редеректить" на html файл где урл подхватит клиент.
    Идея копипастить урлы из одного файла в другой это просто ужас.
  • Пробрасываем роуты Angular 2 через роутер Laravel 5
    +3
    под каждый Angular 2 роут в директиве @RouteConfig нам придется создать копию в роутере Laravel;

    Вот уже в этот момент, автор должен понять, что что-то он делает не так
  • Пробрасываем роуты Angular 2 через роутер Laravel 5
    0
    Можно так же поднять для фронта маленький сервачок на node.js — использовать как проксю(отпадает необходмость в CORS) и, если нужно, ддя серверного рендеринга.

    Хотя если все на одно домене то ни прокси, ни CORS вообще не нужны.

    Первую схему мы юзаем для dev окружения, то есть мне как фронтеннд разработчику не нужно поднимать локально бекенд, вторая схема для production
  • ES6 и за его пределами. Глава 1: ES? Настоящее и Будущее
    0
    Ну многие фичи реализованные нативно будут работать быстрее чем их полифилы на es5.
  • AngularJs, краткое пособие по созданию PhoneCat Application
    0
    Эта статья будет полезна тем, кто ещё не сталкивался с разработкой на AngularJs и хочет в сжатые сроки освоить базовые принципы


    ИМХО но если кто-то не сталкивался с AngularJs (1.x) то может уже и не стоит? Вакансии если и есть, то по большей части «поддержка старого проекта»
  • Как мы год живем без sprockets и с react
    +1
    А зачем пытаться рендерить react через rails?

    Мы уже сами пол года разрабатываем фронт как отдельный проект, по апи получаем все нужные данные, если нужен серверный рендеринг — запускаем сервер на ноде, который если нужно используем еще и как прокси для запросов к api(если все крутится на одном домене то можно этого и не делать, но для dev  окружения необходимо)

    Бекендеры рады — работают с чистыми данными, не парятся за  html и прочие фронтедреские штуки
    Мы(фронтендеры) тоже рады — от проекта к проекту работаем в привычном для себя окружении в независимости от того, что крутится на бекенде
  • Изоморфное Приложение с React и Redux
    0
    Статья называется «Изоморфное Приложение с React и Redux», а не «Изучаем Redux»

    Изоморфное — подразумевает серверную и клиентскую части, вот вам и expressjs
    ES6 — минимум для react-комьюнити, уже вроде как стандарт (babel позволяет), да и если начинать писать приложении с нуля, то сегодня не вижу смыла писать его на ES5
    Роутинг есть почти в любом приложении, поэтому обойти этот вопрос было бы странно
    immutable, да можно было не включать сюда =) Но тоже не вижу особых проблем, не так уж его и много
  • Обзор ES6 в 350 пунктах. Часть вторая
    +1
    Promise.all(...promises) создает промис, который разрешается, когда все промисы ...promises выполнены или один из них отклонен.


    Я конечно уверен всего лишь на 99%, но если хотя бы один из ..promises отклонен то Promise.all тоже будет отклонен
  • Одного лишь адаптивного дизайна мало: нам нужна адаптивная производительность
    0
    Идея поддерживать весь зоопарк устройств, конечно, отличная.

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

    И замечание по переводу
    Слово «полизаполнения» лучше не переводить, а так и оставить — «полифилы» =)
  • Изоморфное Приложение с React и Redux
    0
    Спасибо за перевод!

    Давно присматриваюсь к Redux, а времени пока что-то нет(сейчас проект на flummox), а тут все по полочкам разложено.

    У меня вопрос, есть ли красивое решение для проблемы связанных запросов?

    Пример:
    У нас есть два action creators: getCurrentUser и getFriendsByUserId
    Получается, что первый выполнит запрос на получение id текущего пользователя, а второй по этом id получит список его друзей.

    Как при этом можно организовать тот же рендер на сервере?

    (Возможно, что цепочка может быть и длиннее двух запросов)