Спасибо. Писал в большинстве своем из опыта приобретённого в работе. Подходить к проектам стараюсь максимально индивидуально и соответственно на каждый случай можно написать свое мини-резюме советов)
Это не универсальные решения, а скорее мысли, к которым могут прислушаться pm-ы и взять на заметку))

Да, согласен, если описывать весь спектр зоны работ pm-ов, можно и не остановиться вовсе в рассуждениях))

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

Спасибо за дополнение, всегда рад комментариям и уточнениям)

Могу рассмотреть Ваш конкретный вопрос.

Часто возникает ситуация, что заказчик уже купил тему и не хочет с ней расставаться («Вот мне она понравилась, тем более что она уже готова, и времени у вас это займёт мало»). Тут и начинаются пляски с бубном, потому как многие вещи даже совпадающие с дизайном сложно реализовать. А если в исходниках ещё и нет psd файлов, то дизайн может быть нарисован вообще шедевральный. Тут то и начинается полная вакханалия и приходится шаблону ломать кости. А подружить конфиги шаблона со своим кодом это не такое уж и простое дело.

Там действительно есть несколько статей, читал их ранее, но описывают они в основном только админку, а как устроен сам Gantry 5 ни слова. И как вести разработку под него не сказано.

С одной точки зрения, вы абсолютно правы. Но ведь можно сделать 3-4 небольших шаблона и несколько необходимых частиц, а в последствии применять их на фрилансе. Это должно ускорить работу.

В следующих статьях рассмотрим этот вопрос более подробно ;)

Очень интересные примеры, получается, что присутствует только частичная автоматизация управления ресурсами на уровне JavaScript, однако чтобы освободить ресурсы железа, придется чистить руками. Большое спасибо за разъяснение, учтем этот аспект в будущем.

Касательно замечания по управлению памятью, для WebGL родным языком является JavaScript.
В данном языке конкретных функций ручного управления памятью не предусмотрено, значение переменной в памяти остается до тех пор пока есть хотя бы одна ссылка на переменную далее вступает в действие сборщик мусора.
Понятно, что если бездумно плодить переменные и оставлять их висеть в памяти ничего хорошего не будет, но это уже вопрос оптимизации программы.Так как WebGL программируется в JavaScript эти принципы так же применимы.
Тезис об автоматическом управлении памятью подтверждается и печатными источниками. Однако я не буду утверждать, что вы не правы в своем высказывании, если у вас есть информация или конкретное руководство по ручному управлению памятью при разработке WebGL приложений прошу поделиться. Очень интересно будет почитать и применить на практике для создания качественных, оптимизированных приложений.

Перейдите в chrome://settings
Нажмите кнопку + Показать дополнительные настройки
В разделе Система, найдите пункт Использование аппаратного ускорение включите кликнув на флажок ( и далее вам необходимо перезапустить Chrome для того чтобы изменения вступили в силу)
Затем включите WebGL:
Перейти в chrome://flags
Найдите пункт Включить прототип WebGL 2.0
Убедитесь в том, что WebGL активирован (вам необходимо перезапустить Chrome чтобы любые изменения вступили в силу)
Затем проверьте состояние WebGL:
Перейти в chrome://gpu
Найдите элемент WebGL: Hardware accelerated в списке Graphics Feature Status. Надпись Hardware accelerated должна гореть зеленым

Вот такой есть мануал

Ну судя по тому что сафари не поддерживает WebGl 2.0 Apple не сильно торопиться с внедрением стандарта, так что могут быть проблемы на аппаратном уровне. Хром на эпловских осях иногда выдает такие финты что волосы дыбом становятся.

Без сомнения WebGL 2.0 вкусная технология и со временем она возьмет свое, однако на данный момент суммарная поддержка по браузерам менее 30% и это печально. Я даже не беру в расчет «любимый» всеми фронтэндщиками IE, все печально и со стороны Apple, а это приличная доля пользователей.

Дизайнеры рисуют в пикселях, верстальщики верстают тоже в пикселях, так зачем же их бросать? Мне кажется еще рано это делать.))

Шрифт, размером меньше 12-ти — это шрифт, которым написано число и год над вашим комментарием. (10px) Если весь текст был бы такого размера — читать было бы сложновато.

Браузеры пока не умеют переносить часть слова на следующую строку (без подключения специального плагина), поэтому выравнивание на всю ширину пока лучше не делать.

«А зачем ?» — что вы имели ввиду? Если речь идет об использовании трехмерной графики, то тут я с вами не соглашусь. Презентации, карты, виртуальные гиды высокой детализации, дополненная реальность в конце концов, браузерные игры. Примеров множество, вычислительные мощности растут, пользователь требует все более и более продвинутых интерфейсов.

Спасибо!) Больше примеров и рисунков будет в следующей статье по этой теме;)

в смысле этой проблемы нет, хотя я очень пытался)

Не сталкивался еще, попробовал повторить эту проблему со своим кодом, но все также.

Использовал только нативные способы без подключения дополнительных библиотек. С помощью полифила можно просто через for..of перебрать formdata и с помощью set менять данные как нам угодно, но это уже не так интересно. Проблема с ie в итоге обходится с помощью ручной сборки всех данных с формы, а не простым вызовом конструктора к текущей форме.

Тоже интересовался этим вопросом, но, перерыв пару-тройку страниц поисковой выдачи в гугле по нескольким запросам, оставил тщетные надежды на использование данного сервиса.