Я бы просил рассказывать на уровне архитектуры приложения. Давайте на примере todomvc:polymer немного скажу что именно меня смущает:
Напрямую к вэб компонентам это не относится, но у приложения нет никакой файловой структуры — `/elements/td-input.html` и `/elements/td-todos.html` лежат на одном уровне, хотя это концептуально разные вещи. Но я привык работать с компонентами так, что о построении приложения можно уже многое сказать лишь взглянув на файловую систему — и это не мало важно.
Структура компонент — `/elements/*.html` — Правда предлагаете в одном файле писать html, javasctipt и css? Ну я так делать точно не согласен. Если все импортировать по отдельности, то как быть сo сборкой и со `scoped styles`. Сборщиком замещать этот `import` непосредственно всеми стилями? Решение, но таким образом мы раздуваем конечный html файл.
В примере, меня смущает ещё следующее — <link rel="import" href="td-item.html">. Entry point при загрузки компоненты это его шаблон? Для меня более логичное другое поведение, когда мы подключаем контроллер, а он уже сам регистрируется в системе, подгружает нужный шаблон, и как зависимости другие контроллеры, которые в свою очередь делают тоже самое. А вот инициализация уже происходит через шаблон, когда встречается определённый тэг.
`polymer-localstorage` и `td-model` — где же разделение приложения на business logic layer и ui layer. Я не хочу выделять всё через ui компоненты. Посмотрев в `polymer-localstorage` и увидев `display:none` чуть не поперхнулся — в data access layer ребята используют css стили. Ну ладно там со `слоями приложения`, но посмотрите как они это ещё связывают. Передают id `localstorage` компоненты в `td-model` и связывают через document.querySelector — нет никакой композиции, никаких внедрений зависимостей.
Это только то, что касается базовых вещей. Но наверное это просто пример так ужасно создан и все можно сделать по другому.
> Какой-нибудь шибанутый (простите) вебмастер может залихватски сделать что-нибудь вроде footer :last-child
Вот именно, что всегда говорят о разных уровнях вэба. Есть сайт портфолио, или gmail подобное приложение. В последнем я очень сомневаюсь, что будет ситуация когда `шибанутый вэбмастер`, потому что это совсем разного уровня приложения и зачастую разного уровня люди их делают.
И разумеется, я с вами о shadow dom согласен — это здорово. Но подобный аргумент удивил :)
Вэб компоненты крутые, в силу того, что шаблон проектирования `Компонент` очень классный и никак не наоборот. И для построения большого вэб приложения им одним «сыт» не будешь. В этой шумихе все, как и вы — огромный акцент делают на `third-party components` — как бы — «подключил и забыл». Но имея также огромный опыт работы с компонентами я пришел к выводу, что очень сложно сделать универсальный компонент. Поэтому мы будем все равно преимущественно иметь «локальные» компоненты, и только несколько вендорных. В силу этого и разговор нужно вести в этом направлении. Как Вэб компоненты помогают структурировать приложение, как выглядит сборка приложения, какие паттерны скрыты в Компоненте (инкапсуляция html, css конечно же одна из самых классных, что я вижу) и прочее.
:) У меня наоборот — всё кроме 3его пункта ... А вот про гитхаб вы не правы — выкладывать никогда не рано!
PS: Не пропустите ещё одно хорошее начинание по `jquery` теме — Kimbo
Статья маркетинговая, на самом деле никакого чуда в таком подходе нет. Ребята взяли не оптимизированное к подобному тесту Бэкбон приложение и наделали шумихи. Для интереса, я сравнил с фреймворком который используем Atma — разница лишь в ~50мс при создании, а всё остальное (удаление и изменения состояния) моментально. И то, этот 50мс `оверхэд` из за множества биндингов, а не из-за ДОМ рэндеринга. К тому же, если в ОМ добавлять `таски` до >2000 то лаги становятся довольно ощутимые.
Вау, магия. И есть много других способов писать в… минутки-минутку… input stream, ведь это всего лишь обёртка над streambuf. Поэтому «write to» тривиально как с программной стороны, так и со стороны пользователя, поэтому Чаку здесь делать нечего.
Ну как же. «can write to» может любой нормальный человек, например, обычной клавиатурой писать в input stream reader. А вот читать соостветственно может только сама программа. )
Есть очень много архитектурных решений для построения сайтов. И это при том, что само значение `сайт` уже давно утратило свою однозначность. Это начиная от простых статичных landing page до 'тяжёлых' приложений на подобии gmail, а также всевозможных гибридных приложений. Поэтому «четкое разделение на клиент-сервер» существует только в рамках выбранных технологий и выбранной архитектуры.
Я, к удивлению, ещё не встречался со звеном «верстальщик» поэтому такая цепь мне не привычна в рамках толстого клиента. Если мы взглянем на другие технологии — Desktop: WPF с xaml, Qt с qml, JavaFX. Mobile: iOS/Android. Есть ли где нибудь в цепи разработке звено `верстальщик`? Я же снова и там с ним не встречался.
Возможно раньше, когда был ещё IE6 и сайты было более менее статичны вёрстка занимала отдельное большое место. Сейчас же, как уже говорил, я сталкиваюсь только с тем, что UI создает frontend developer ( web designer -> frontend webdeveloper -> backend webdeveloper — database dev)
То есть, вы работали только с html шаблонизаторами и ничего другого не видели в реальных проэктах, и при этом утверждаете мол «ничего лучшего чистого html нету»? Вам самим не кажется, что это попахивает фанатизмом?
Пример с процессом создания шаблона конечно хорошо аргументирует вашу позицию, но это узкий взгляд на вэб разработку. Вы здесь как-то очень определённо разделяете людей на верстальщик и программист (хотя проработав много лет в германии, я до сих пор не знаю, как по-немецки будет «верстальщик»). Возможно такое разделение уместно лишь, например, при создании небольших web порталов с php бэкендом и тонким клиентом. Когда же у нас толстый клиент, а это большинство десктопных, мобилных и браузерных приложений, то созданием бизнес логики и ui занимаются программисты — и процесс создания приложения соответственно делится на модули и компоненты, которые в свою очередь могут занимать разные слои — как и business logic layer, так и ui layer.
И даже если у вас есть люди которые только `верстают` — почему бы им не дать возможность создавать макеты непосредственно с `haml` например, таким образом и им проще будет, и программистам легче шаблоны редактировать. Я к тому, что любой другой шаблонизатор также легко вписывается в представленный вами процесс создания шаблонов.
Пожалуйста воспринимайте нашу дискуссия как дружескую беседу, и да простит нас автор за этот оффтоп.
Что-то вы всё перемешали — «шаблонизаторы», «такие штуки». Такая штука — это как бы и есть шаблонизатор. А вы наверное имели ввиду html-синтаксис. Так есть же много других шаблонизаторов, которые также абстрагируются от html, и которые даже прижились. И есть мнение, что люди продолжают использовать html, только потому, что не «распробовали на вкус» более удобные и продуктивные синтаксисы.
А мне, напротив, нравится сложившаяся ситуация) Здесь царит своя эко-система — что-то рождается, что-то уходит в небытие, прям естественный отбор во всей своей красе. Главное, что все преследуют одну цель — улучшить и упростить. Одним удаётся лучше, другим хуже. Но комментарии подобные выше изложенному, есть и будут всегда. Человек привык держатся за свою систему ценностей и всё новое принимает в штыки, но такая позиция проигрышная, как для человека в частности, так и для быстрой эволюции системы в целом.
> в продакшене на Windows.
А в чем проблема? С iisnode у нас всё прекрасно работает — отличная паралельная работа с IIS, который занимается статикой и даже другими WCF сервисами в приложении.
Будем ждать, код у них действительно качественный, интересно посмотреть как они все реализуют. Предложенный вариант умельцев лишь генерирует статические файлы из страниц сервера. Выход конечно, но не совсем оптимальный.
Верно, всё как вы описали — при инициализации передается дом и модели которые десериализуются из json, поэтому компоненты далее работают, как будто они сами рэндерили шаблон на клиенте. А про дальнейший рэндеринг — это я имел ввиду, к примеру, если у нас есть компонент из списка каких-то данных записей — EntryItem — у него свой шаблон, свои события, прочее, ну вы понимаете. И вот в рантайме добавляется новая запись и нам не нужно рендерить её на сервере, передали json и отрэндерили уже на клиенте.
Да, именно о невозможности сделать вовсе без сервера. Скажем на случай, если уже имеется derbyjs вэб приложения, но клиент захотел ещё мобильное приложение. Вот и интересно, как сложно переделать под phonegap. Я читал, они собирались как-то избавится от этого ограничения, но или уже сделали или нет, не знаю.
К сожалению про ангуляр не скажу, мы используем кое что получше :) У нас свой фрэймворк который «возводит в абсолют» компоненты — все шаблоны компонент-ориентированые, вот там мы и используем все прелести рендеринга на сервере или на клиенте. С примерами и документацией не густо, но вот пример лишь клиентской части — todomvc, а здесь простой правда и старенький, но гибридный подход.
Действительно, дерби замечательный фреймворк, единственное только что смущает, они через чур привязываются к бэкенду — будет не очень просто переделать под stand-alone приложение, скажем для phonegap. Или я ошибаюсь?
/elements/td-input.html` и `/elements/td-todos.html` лежат на одном уровне, хотя это концептуально разные вещи. Но я привык работать с компонентами так, что о построении приложения можно уже многое сказать лишь взглянув на файловую систему — и это не мало важно./elements/*.html` — Правда предлагаете в одном файле писать html, javasctipt и css? Ну я так делать точно не согласен. Если все импортировать по отдельности, то как быть сo сборкой и со `scoped styles`. Сборщиком замещать этот `import` непосредственно всеми стилями? Решение, но таким образом мы раздуваем конечный html файл.В примере, меня смущает ещё следующее —
<link rel="import" href="td-item.html">. Entry point при загрузки компоненты это его шаблон? Для меня более логичное другое поведение, когда мы подключаем контроллер, а он уже сам регистрируется в системе, подгружает нужный шаблон, и как зависимости другие контроллеры, которые в свою очередь делают тоже самое. А вот инициализация уже происходит через шаблон, когда встречается определённый тэг.display:none` чуть не поперхнулся — в data access layer ребята используют css стили. Ну ладно там со `слоями приложения`, но посмотрите как они это ещё связывают. Передают id `localstorage` компоненты в `td-model` и связывают черезdocument.querySelector— нет никакой композиции, никаких внедрений зависимостей.Это только то, что касается базовых вещей. Но наверное это просто пример так ужасно создан и все можно сделать по другому.
Вот именно, что всегда говорят о разных уровнях вэба. Есть сайт портфолио, или gmail подобное приложение. В последнем я очень сомневаюсь, что будет ситуация когда `шибанутый вэбмастер`, потому что это совсем разного уровня приложения и зачастую разного уровня люди их делают.
И разумеется, я с вами о shadow dom согласен — это здорово. Но подобный аргумент удивил :)
Не забывайте про метод PATCH. Вами описанная проблема с `setUserCity` не актуальна.
PS: Не пропустите ещё одно хорошее начинание по `jquery` теме — Kimbo
Вау, магия. И есть много других способов писать в… минутки-минутку… input stream, ведь это всего лишь обёртка над
streambuf. Поэтому «write to» тривиально как с программной стороны, так и со стороны пользователя, поэтому Чаку здесь делать нечего.Я, к удивлению, ещё не встречался со звеном «верстальщик» поэтому такая цепь мне не привычна в рамках толстого клиента. Если мы взглянем на другие технологии — Desktop: WPF с xaml, Qt с qml, JavaFX. Mobile: iOS/Android. Есть ли где нибудь в цепи разработке звено `верстальщик`? Я же снова и там с ним не встречался.
Возможно раньше, когда был ещё IE6 и сайты было более менее статичны вёрстка занимала отдельное большое место. Сейчас же, как уже говорил, я сталкиваюсь только с тем, что UI создает frontend developer ( web designer -> frontend webdeveloper -> backend webdeveloper — database dev)
То есть, вы работали только с html шаблонизаторами и ничего другого не видели в реальных проэктах, и при этом утверждаете мол «ничего лучшего чистого html нету»? Вам самим не кажется, что это попахивает фанатизмом?
Пример с процессом создания шаблона конечно хорошо аргументирует вашу позицию, но это узкий взгляд на вэб разработку. Вы здесь как-то очень определённо разделяете людей на верстальщик и программист (хотя проработав много лет в германии, я до сих пор не знаю, как по-немецки будет «верстальщик»). Возможно такое разделение уместно лишь, например, при создании небольших web порталов с php бэкендом и тонким клиентом. Когда же у нас толстый клиент, а это большинство десктопных, мобилных и браузерных приложений, то созданием бизнес логики и ui занимаются программисты — и процесс создания приложения соответственно делится на модули и компоненты, которые в свою очередь могут занимать разные слои — как и business logic layer, так и ui layer.
И даже если у вас есть люди которые только `верстают` — почему бы им не дать возможность создавать макеты непосредственно с `haml` например, таким образом и им проще будет, и программистам легче шаблоны редактировать. Я к тому, что любой другой шаблонизатор также легко вписывается в представленный вами процесс создания шаблонов.
Пожалуйста воспринимайте нашу дискуссия как дружескую беседу, и да простит нас автор за этот оффтоп.
А в чем проблема? С iisnode у нас всё прекрасно работает — отличная паралельная работа с IIS, который занимается статикой и даже другими WCF сервисами в приложении.