1. Именно это я и сказал постом выше
2.1. Отсутствие понимания идеологии шаблонов проектирования — это проблема квалификации программистов
2.2. При коллективной разработке на базе сформированной архитектуры вам всегда придется разбираться в ней. И самый простой способ это сделать — общение с архитектором этой системы, как вы и сказали выше. Так было, так есть, и так будет всегда
3. Если вы не были знакомы с этим шаблоном проектирования, то это совсем не означает, что ваш подход не основан на нём
По-моему в вашей статье немного путается «мягкое» с «тёплым». MVC — шаблон проектирования, так же как и MVVM и т.д.
Это означает, что за основу берется какой-то шаблон проектирования(MVC, например), но совсем не означает, что в вашей конечной архитектуре будет только модель, представление и контроллер(такое бывает только в очень маленьких проектах).
При чём тут стандарты? То, что вы описали в посте — архитектура вашего приложения, основанная на паттерне MVVM.
А с появлением статической типизации прелесть работы с «чистым» JavaScript не теряется?
Странное у вас представление о «чистом» языке. Ведь язык — это не только синтаксис, следуя которому мы пишем код, это ещё и определенная концепция, заложенная в язык. Разве я не прав?
Я не хочу сказать ничего плохого про TS, не подумайте…
Просто JS не предполагает таких возможностей в меру того, что он изначально спроектирован динамически типизированным. Это означает, что он никогда не будет поддерживать подобной TS типизации. Ошибочно говорить, что это хорошо или плохо, это просто иначе.
Ну не знаю, мне кажется довольно странной идея превращения динмически типизированного языка в статический(или около того).
А за «зеленость», я считаю, должны отвечать тесты.
Я согласен с asavin, при правильном подходе всё замечательно работает, это зависит лишь от навыков программистов. Я так понимаю, что вам ближе идеи тех языков, с которых вы начинали программировать, и их парадигмы программирования. Однако, не все начинали писать с Delphi или C. Лично я начинал с PHP, после которого начал заниматься JavaScript, и мне привычно то, что для вас кажется странным.
Но что касается сложности отладки, то на мой взгляд, предмет этой статьи — это тот недостающий кирпичик, которого нехватало JavaScript для полного отказа от разных корявых решений типа console.log и alert.
Спасибо, по комментариям выше я уже услышал ответ на свой первый вопрос. Просто я не ожидал, что вопрос обернется таким количеством негатива в свою сторону. Извините за оффтоп.
Планета, «которая рядом» непригодна для жизни человека на ней. Планета, которая «хрен знает где», многовероятно, пригодна.
Как по мне, то больший интерес должны вызывать планеты, которые мы сможем(или не сможем) колонизировать в будущем.
Мнение есть мнение, оно никого не оскорбляет, и правильное оно или нет, почему оно не должно иметь места на существование?
Мне нравится тенденция хабра — задал вопрос, а вместе с ответом получил минусы и слив кармы. Я так понимаю, теперь нельзя задавать вопросы по статье, можно только хвалить?
Мне интересно, с какой целью проводится данное исследование? Найти формы жизни? Тогда почему Энцелад, а не Глизе 581 g, ведь там жизнь намного более вероятна?
А вы не могли бы уточнить, какие именно операции Gulp не способен выполнить? К слову говоря, Gulp как раз использует ту вирт. файловую систему, о которой вы говорили выше.
Понимаете, я совершенно не против вашего подхода. Я абсолютно уверен, что в рамках вашего проекта это решение прекрасно работает. Дело лишь в том, что на мой взгляд, нельзя сказать, что для всех систем ваше решение является оптимальным, а сказанные вами слова
Система сборки не должна заниматься компилированием ресурсов
или
в dev моде вообще не должно быть никаких процессов сборки
являются слишком громкими.
В конце концов, мы здесь обсуждаем систему сборки Broccoli, а не разницу в подходах ;)
Я бы с удовольствием перенес наше общение в лс, чтобы оставить в этой ветке только сообщения, относящиеся к теме.
Скажите, а чем отличается server side компилирование Lessa от server sidе компилирования sassa
У меня были сомнения, что вы собираетесь компилировать LESS на фронте.
Я лишь предлагаю более чистую архитектуру, а не велосипед.) А вы выступаете за комбайн который делает все сразу, но при этом в конфиге настраиваете компиляцию ресурсов и боретесь с прочими не нужными вещами.
Почему же? Я выступаю за систему сборки, которая имеет, к примеру, 3 задачи: собрать dev, собрать production, повесить вотчер для инкрементальной сборки(для dev). Когда вы запускаете dev билд, у вас выполняется стандартный набор действий: А, Б, В. Когда вы запускаете production билд, у вас запускается dev билд(А, Б, В), а потом запускается еще Г, Д, Е. Если же запускать инкрементальную сборку, то мы видим следующее: в системе висит демон, который отслеживает изменения для опр. формата файлов в директориях проекта, и при каждом изменении файла, он собирает его, используя его зависимости и кладет в результирующую директорию.
На самом деле, мы говорим не о таких разных вещах. Просто, насколько я понимаю, у вас есть одно решение для dev сборок(на уровне обработок запроса пользователя) и другое решение для production сборок. Я же просто сторонник того, что любую сборку должен выполнять один и тот же инструмент, просто по разным сценариям. В этом есть и другой плюс: т.к. мы рассматриваем инструменты для frontend разработчика, то будет справедливо сказать, что большая часть javascript программистов не знают серверных ЯП, и/или не знакомы с настройкой nginx/apache, а это значит, что путь сборки, подобный тому, что вы предложили, будет на порядок сложнее, т.к. он требует доп. знаний, но очевидных преимуществ не несет: нам все равно нужна система для сборки production, верно?
Если я не ошибаюсь, то HttpHandlers — это ASP.NET решение, а веб-разработка, как вы понимаете, крутится не только вокруг него. Тем более, судя по всему, вы выполняете ту же задачу, которую выполняет система сборки, только делаете это своим велосипедом способом. И, я по-прежнему не понимаю, как вы будете компилировать SASS(а не less) и Haml.
А второе — (спорно, но важно) — в dev моде вообще не должно быть никаких процессов сборки
В таком случае, объясните мне пожалуйста, как вы будете собирать SASS, Haml?
Как вы считаете, оптимальнее каждый раз в режиме реального времени заново собирать все coffee файлы? Аналогичную задачу может решить инкрементальная сборка: ставите вотчер на coffee, после первой сборки он кеширует сохраненное состояние, а при сл. операции над каким-либо файлом, он выполнит сборку только для него. На моей, не особо мощной машине, это занимает 200 ms, а настройка решения занимает 5 минут, если разворачивать систему сборки с нуля. Аналогичное решение для компиляции coffee в js с последующим выполнением, я, признаться, не видел, и с трудом могу себе представить: в какой момент вы будете запускать компиляцию? Как вы будете избегать компиляции неизмененных файлов? Если вы в dev режиме не минифицируете файлы, то каким образом вы скомпилируете все файлы? Если же вы хотите компилировать не все файлы, а только по мере их использования, как вы это собираетесь делать? Приведите, пожалуйста, любой, пускай даже самый простой пример того, как это будет выглядеть. Предположим, у нас есть модуль А и модуль Б, они написаны на coffee. И есть точка входа в проект — index.html, из которой должен быть вызван модуль А, который зависит от модуля Б. Какое решение для «компиляции на лету» вы бы предложили? (я не стараюсь катить бочку, поймите правильно, я просто не вижу рационального пути решения этой задачи без системы сборки, или, как минимум, таск раннера а-ля Grunt).
Это упрощает разработку в разы — в developer tools у нас все файлы по отдельности, и только те которые используются в данном сценарии.
В чём состоит упрощение? В Chrome Dev Tools уже давно есть поддержка source maps, но, прошу заметить, я нигде не говорил, что при инкриментальной сборке проекта в dev режиме, вам требуется минифицировать файлы.
2.1. Отсутствие понимания идеологии шаблонов проектирования — это проблема квалификации программистов
2.2. При коллективной разработке на базе сформированной архитектуры вам всегда придется разбираться в ней. И самый простой способ это сделать — общение с архитектором этой системы, как вы и сказали выше. Так было, так есть, и так будет всегда
3. Если вы не были знакомы с этим шаблоном проектирования, то это совсем не означает, что ваш подход не основан на нём
Это означает, что за основу берется какой-то шаблон проектирования(MVC, например), но совсем не означает, что в вашей конечной архитектуре будет только модель, представление и контроллер(такое бывает только в очень маленьких проектах).
При чём тут стандарты? То, что вы описали в посте — архитектура вашего приложения, основанная на паттерне MVVM.
Странное у вас представление о «чистом» языке. Ведь язык — это не только синтаксис, следуя которому мы пишем код, это ещё и определенная концепция, заложенная в язык. Разве я не прав?
Просто JS не предполагает таких возможностей в меру того, что он изначально спроектирован динамически типизированным. Это означает, что он никогда не будет поддерживать подобной TS типизации. Ошибочно говорить, что это хорошо или плохо, это просто иначе.
По сути, вы можете использовать любой язык со статической типизацией, который транслируется в JavaScript. Рекомендую взглянуть на Dart
А за «зеленость», я считаю, должны отвечать тесты.
Но что касается сложности отладки, то на мой взгляд, предмет этой статьи — это тот недостающий кирпичик, которого нехватало JavaScript для полного отказа от разных корявых решений типа console.log и alert.
Как по мне, то больший интерес должны вызывать планеты, которые мы сможем(или не сможем) колонизировать в будущем.
Мнение есть мнение, оно никого не оскорбляет, и правильное оно или нет, почему оно не должно иметь места на существование?
В конце концов, мы здесь обсуждаем систему сборки Broccoli, а не разницу в подходах ;)
Я бы с удовольствием перенес наше общение в лс, чтобы оставить в этой ветке только сообщения, относящиеся к теме.
У меня были сомнения, что вы собираетесь компилировать LESS на фронте.
Почему же? Я выступаю за систему сборки, которая имеет, к примеру, 3 задачи: собрать dev, собрать production, повесить вотчер для инкрементальной сборки(для dev). Когда вы запускаете dev билд, у вас выполняется стандартный набор действий: А, Б, В. Когда вы запускаете production билд, у вас запускается dev билд(А, Б, В), а потом запускается еще Г, Д, Е. Если же запускать инкрементальную сборку, то мы видим следующее: в системе висит демон, который отслеживает изменения для опр. формата файлов в директориях проекта, и при каждом изменении файла, он собирает его, используя его зависимости и кладет в результирующую директорию.
На самом деле, мы говорим не о таких разных вещах. Просто, насколько я понимаю, у вас есть одно решение для dev сборок(на уровне обработок запроса пользователя) и другое решение для production сборок. Я же просто сторонник того, что любую сборку должен выполнять один и тот же инструмент, просто по разным сценариям. В этом есть и другой плюс: т.к. мы рассматриваем инструменты для frontend разработчика, то будет справедливо сказать, что большая часть javascript программистов не знают серверных ЯП, и/или не знакомы с настройкой nginx/apache, а это значит, что путь сборки, подобный тому, что вы предложили, будет на порядок сложнее, т.к. он требует доп. знаний, но очевидных преимуществ не несет: нам все равно нужна система для сборки production, верно?
велосипедомспособом. И, я по-прежнему не понимаю, как вы будете компилировать SASS(а не less) и Haml.В таком случае, объясните мне пожалуйста, как вы будете собирать SASS, Haml?
Как вы считаете, оптимальнее каждый раз в режиме реального времени заново собирать все coffee файлы? Аналогичную задачу может решить инкрементальная сборка: ставите вотчер на coffee, после первой сборки он кеширует сохраненное состояние, а при сл. операции над каким-либо файлом, он выполнит сборку только для него. На моей, не особо мощной машине, это занимает 200 ms, а настройка решения занимает 5 минут, если разворачивать систему сборки с нуля. Аналогичное решение для компиляции coffee в js с последующим выполнением, я, признаться, не видел, и с трудом могу себе представить: в какой момент вы будете запускать компиляцию? Как вы будете избегать компиляции неизмененных файлов? Если вы в dev режиме не минифицируете файлы, то каким образом вы скомпилируете все файлы? Если же вы хотите компилировать не все файлы, а только по мере их использования, как вы это собираетесь делать? Приведите, пожалуйста, любой, пускай даже самый простой пример того, как это будет выглядеть. Предположим, у нас есть модуль А и модуль Б, они написаны на coffee. И есть точка входа в проект — index.html, из которой должен быть вызван модуль А, который зависит от модуля Б. Какое решение для «компиляции на лету» вы бы предложили? (я не стараюсь катить бочку, поймите правильно, я просто не вижу рационального пути решения этой задачи без системы сборки, или, как минимум, таск раннера а-ля Grunt).
В чём состоит упрощение? В Chrome Dev Tools уже давно есть поддержка source maps, но, прошу заметить, я нигде не говорил, что при инкриментальной сборке проекта в dev режиме, вам требуется минифицировать файлы.
Гугл не один раз закрывал свои проекты, и лично я думаю, что Dart ждет такая же участь.