Суть проблемы в том что реальный размер элемента (физический, тот, который пользователь видит своим глазом) зависит от ppi
и на разных
операционных системах/видео драйверах/видео картах/экранах
будет разный физический размер пикселя.
Т.е. если дизайнер смотрит на свой макет с платформой 89ppi ( для наглядности предположим, что и у него хорошее зрение), и считает все элементы удобными, чекбоксы попадаемы, текст читаем
то пользователь с экраном с 121ppi (и для наглядности плохим зрением) будет с ним не согласен.
И еще одна проблема в догонку.
Нет нативного API для определения, открыта ли страница на тачскрине, или на мыше и клаве
Крупный планшет и старый экран могут иметь одинаковое разрешение. Есть варианты с угадованием, но они не 100% (узнав по userAgent тип ОС и предположить, что это за устройство)
P.S. Это всё и не критично, и не существенно, и проявляется в редких случаях,
но вносит свои неудства, так сказать не идеально.
P.P.S. Все эти ограничения из-за политики безопасности браузеров.
Вопрос к автору. Прошу прощения за нескромность. А какой у вас опыт в разработке?
Если вы начниающий разработчик и хотите выбрать для себя фрейморк, то не утруждайтесь и используйте Bootstrap
Просто если у вас нет большого опыта вы вряд ли сможете оценить каждый фреймворк
Про сетки:
Сейчас 4 основных разрешения это
1366, 1920, 320, 768 (в порядке популярности)
4 колонки для мобильника
8 колонок для планшета
12 колонок для ноутбука и старых мониторов
24 колонки для desktop и TV, причём здесь желательно ограничивать ширину где-то на 2400 или 2880
Да и для наших дизайнеров, понять, что нарисовать один макет для 1280 — этого не достаточно, ну ни как.
Еще нужно не забывать про такой кошмар как ppi (pixel per inch) размер пихеля
при чём, его ни как не определить средствами браузера
Проблема в том, что существуют такие устройства у которых
диагональ 17 дюймов а разрешение 1747х1092 (121ppi)
диагональ 19 дюймов, а разрешение 1440х900 (89ppi)
т.е. на одном экране ваши 1000px будут 20 см, а на другом будут 28.5 см (1inch=2.54cm)
К сожалению, нет, я работал с ним только на 2-3 страницах.
Но по первому впечатлению могу сказать что использовать его можно только в виде отдельных компонентов.
Да есть крутые.
Но как архитектура, semantic-ui не удобен.
А да вспомнил крутой косяк: Высота кнопки по умолчание 36px, а инпута 38px (из-за бордера)
Мне после бутстрапа, где все элементы красиво встают в ряд, показалось дико.
а как на счёт удобства?
Мы попробовали поменять bootstrap на Semantic-ui, мне показалось не удобным и сырым.
В семантике большая проблема с совмещением компонентов и вложеностью.
Я так и не смог зделать нормального верхнего меню.
Может я не умею его готовить, но с bootstrap-ом проще
Согласен! WordPress, Drupal хоть и не фреймоврки, но очень удобные инструменты для Вась и Петь!
А вот с Женей вопрос спорный. Будет ли написан код Васей и Петей так, как этого предлагают разработчики фреймворков? Сколько времени нужно Жене на изучение всех фреймворков и библиотек? А хватит ли запала и т.п.
Соглашусь еще раз для менеджеров фреймворки могут быть и выгодны. но для кода и для разработчика, как специалиста, вряд ли.
Конечно я согласен, что где применим, там надо применять!
Но, уж слишком тонкая грань между удобством первого старта и жёсткостью разросшегося приложения.
Надо уметь их готовить. А на это уходит время не одного проекта. А за это время мода успеет поменяться.
(Backbone->Angular->React)
На моей практике либо приложение на столько маленькое, что тянуть ради него фреймворк как из пушки по воробьям, либо она такое большое, что со всеми фреймоврками и библиотеками порог входа несколько месяцев для ознакомительного изучения их всех. А когда начинают появляться в них баги… или заказчик хочет того, что с фреймворком ой как сложно сделать. (Например Lazy-loading для Angular 1.2) вот тогда сильно задумываешься о том, стоит ли оно того?
Всеми руками за! Отличная статья! Давно пора трезво смотреть на эту моду! Подпишусь под каждым словом!
Но я не могу отделаться от мысли, что лучше вложиться в собственные знания и навыки в рамках самой веб-платформы.
Именно! Лично я предпочитаю изучению хода мыслей других разработчиков, изучение основ самого web-a!
Изучение.
Снова изучать.
И причём ты ни когда не сможешь сказать со 100% увереностью что ты отлично разбираешься в этом фреймворке,
если ты его только сам не разрабатываешь.
На доскональное изучение уходят месяцы. Лучше открыть w3c.org и понять где корни ошибок и т.п.
Хочу добавить что каждый фреймворк накладывает свой угол зрения и он уже того, что можно создать с помощью нативного web-а(который еще и гибче)
Справедливости ради скажу, что я не участвую в проектах со 100+ количеством разработчиков, для которых создаются данные фреймовки. Но они создаются для узкого круга задач (Да, да, а вы думаете гугл/телеграм заботиться о ваших архтектурах?) И в тех проектах где действительно прменим фреймворк стоит задуматься о написании своей системы.
именно! Бесплатные! А как же студенты и опен сорс? Да и просто поиграться или показать кому-то, платить по 5$ в месяц?
На php бесплатных хостингов море!
Суть проблемы в том что реальный размер элемента (физический, тот, который пользователь видит своим глазом) зависит от ppi
и на разных
операционных системах/видео драйверах/видео картах/экранах
будет разный физический размер пикселя.
Т.е. если дизайнер смотрит на свой макет с платформой 89ppi ( для наглядности предположим, что и у него хорошее зрение), и считает все элементы удобными, чекбоксы попадаемы, текст читаем
то пользователь с экраном с 121ppi (и для наглядности плохим зрением) будет с ним не согласен.
И еще одна проблема в догонку.
Нет нативного API для определения, открыта ли страница на тачскрине, или на мыше и клаве
Крупный планшет и старый экран могут иметь одинаковое разрешение. Есть варианты с угадованием, но они не 100% (узнав по userAgent тип ОС и предположить, что это за устройство)
P.S. Это всё и не критично, и не существенно, и проявляется в редких случаях,
но вносит свои неудства, так сказать не идеально.
P.P.S. Все эти ограничения из-за политики безопасности браузеров.
Если вы начниающий разработчик и хотите выбрать для себя фрейморк, то не утруждайтесь и используйте Bootstrap
Просто если у вас нет большого опыта вы вряд ли сможете оценить каждый фреймворк
Сейчас 4 основных разрешения это
1366, 1920, 320, 768 (в порядке популярности)
4 колонки для мобильника
8 колонок для планшета
12 колонок для ноутбука и старых мониторов
24 колонки для desktop и TV, причём здесь желательно ограничивать ширину где-то на 2400 или 2880
Да и для наших дизайнеров, понять, что нарисовать один макет для 1280 — этого не достаточно, ну ни как.
Еще нужно не забывать про такой кошмар как ppi (pixel per inch) размер пихеля
при чём, его ни как не определить средствами браузера
Проблема в том, что существуют такие устройства у которых
диагональ 17 дюймов а разрешение 1747х1092 (121ppi)
диагональ 19 дюймов, а разрешение 1440х900 (89ppi)
т.е. на одном экране ваши 1000px будут 20 см, а на другом будут 28.5 см (1inch=2.54cm)
Он акцентирует внимание на очень большом количестве недочётов, которые упускают другие редакторы.
Но по первому впечатлению могу сказать что использовать его можно только в виде отдельных компонентов.
Да есть крутые.
Но как архитектура, semantic-ui не удобен.
А да вспомнил крутой косяк: Высота кнопки по умолчание 36px, а инпута 38px (из-за бордера)
Мне после бутстрапа, где все элементы красиво встают в ряд, показалось дико.
Мы попробовали поменять bootstrap на Semantic-ui, мне показалось не удобным и сырым.
В семантике большая проблема с совмещением компонентов и вложеностью.
Я так и не смог зделать нормального верхнего меню.
Может я не умею его готовить, но с bootstrap-ом проще
Соглашусь, с первого раза читать трудновато.
Илюстрации великолепные! Интересно, вы действительно свободно рисуете как левой, так и правой или сменили кисть для баланса картины?
А вот с Женей вопрос спорный. Будет ли написан код Васей и Петей так, как этого предлагают разработчики фреймворков? Сколько времени нужно Жене на изучение всех фреймворков и библиотек? А хватит ли запала и т.п.
Соглашусь еще раз для менеджеров фреймворки могут быть и выгодны. но для кода и для разработчика, как специалиста, вряд ли.
Но, уж слишком тонкая грань между удобством первого старта и жёсткостью разросшегося приложения.
Надо уметь их готовить. А на это уходит время не одного проекта. А за это время мода успеет поменяться.
(Backbone->Angular->React)
На моей практике либо приложение на столько маленькое, что тянуть ради него фреймворк как из пушки по воробьям, либо она такое большое, что со всеми фреймоврками и библиотеками порог входа несколько месяцев для ознакомительного изучения их всех. А когда начинают появляться в них баги… или заказчик хочет того, что с фреймворком ой как сложно сделать. (Например Lazy-loading для Angular 1.2) вот тогда сильно задумываешься о том, стоит ли оно того?
По делу, кто может подробно объяснить с примерами и сутью:
И его реализация для преобразования строки в массив Char-кодов (иммею ввиду String.charCodeAt())
Моя реализация
В приципе я понимаю кое-как, но хотелось бы подробно, полностью и точно.
Именно! Лично я предпочитаю изучению хода мыслей других разработчиков, изучение основ самого web-a!
И причём ты ни когда не сможешь сказать со 100% увереностью что ты отлично разбираешься в этом фреймворке,
если ты его только сам не разрабатываешь.
На доскональное изучение уходят месяцы. Лучше открыть w3c.org и понять где корни ошибок и т.п.
Хочу добавить что каждый фреймворк накладывает свой угол зрения и он уже того, что можно создать с помощью нативного web-а(который еще и гибче)
Справедливости ради скажу, что я не участвую в проектах со 100+ количеством разработчиков, для которых создаются данные фреймовки. Но они создаются для узкого круга задач (Да, да, а вы думаете гугл/телеграм заботиться о ваших архтектурах?) И в тех проектах где действительно прменим фреймворк стоит задуматься о написании своей системы.
Слишком сильно Angular & React размаркетингован!
Они имеют свою нишу.
На php бесплатных хостингов море!