Когда же инструментарий для веб разработки приблизится к уровню инструментов
для разработки нативных приложений — визуальный редактор WISYWIG
с возможностью легко подключать компоненты и визуально компоновать страницу.
Из компонентов хотелось бы использовать что-то посложнее Bootstrap,
например Semantic UI или компоненты Angular’а / React’а.
Но не Telerik/Infragistics и пр. тяжеловесные контролы.
Раскатал губу? )
Ну хорошо, пусть без WISYWIG редактора, ну хотя бы с
hot module replacement / live reloading, чтобы при правке html/css/js|ts сразу
был виден результат в браузере мгновенно и без лишних нажатий (даже сохранения файла).
Поискал что есть на эту тему и заметил, что для React’а инструменты получше —
есть действительно мгновенный live reloading, а вот Angular пару секунд минимум тормозит.
Проблема в размере Angular’а? Или это легко решается?
По поводу компонентов:
для Angular нашел только один репозиторий http://ngmodules.org/,
но несмотря на 2110 modules он довольно грустный.
У React’а есть https://js.coach, который заметно лучше, да еще и https://react.rocks/,
где можно поискать компонент сразу с визуальным предпросмотром.
Но все равно фрагментация жуткая и как эффективно с этим работать не представляю.
Просьба
Если кто-то нашел для себя продуктивный вариант (сравнимый по скорости с инструментами для нативной разработки),
то поделитесь, пожалуйста, буду ОЧЕНЬ признателен.
зы Пересмотрел более 30 инструментов на эту тему, самыми интересными из которых оказались Webflow, Axure, Vaadin,
но все даже близко не приближается к тому, что хотелось бы.
ззы Может быть WebAssembly поможет перенести xaml с его инструментами в браузер?
Здравствуйте, Keith, Вы писали:
K>Когда же инструментарий для веб разработки приблизится к уровню инструментов K>для разработки нативных приложений — визуальный редактор WISYWIG
У инструментов для нативной разработки, как только уровень возможностей лейаута приближается к HTML, так сразу начинаются проблемы с визифигом.
K>Ну хорошо, пусть без WISYWIG редактора, ну хотя бы с K>hot module replacement / live reloading, чтобы при правке html/css/js|ts сразу K>был виден результат в браузере мгновенно и без лишних нажатий (даже сохранения файла).
K>>Когда же инструментарий для веб разработки приблизится к уровню инструментов K>>для разработки нативных приложений — визуальный редактор WISYWIG НС>У инструментов для нативной разработки, как только уровень возможностей лейаута приближается к HTML, так сразу начинаются проблемы с визифигом.
Какие именно возможности HTML имеете ввиду?
Делал на WinForms весьма красиво, и размеры окон подстраивались под объем содержимого,
хотя снег, конечно, не падал на контролы )
K>>Ну хорошо, пусть без WISYWIG редактора, ну хотя бы с K>>hot module replacement / live reloading, чтобы при правке html/css/js|ts сразу K>>был виден результат в браузере мгновенно и без лишних нажатий (даже сохранения файла).
НС>Для VS давно уже есть, BrowserLink называется.
Хот-кей все же нужен и JS фреймворки не поддерживаются, только серверный рендеринг.
Здравствуйте, vdimas, Вы писали:
V>Web-приложения не нужны. V>Сейчас в мобильном секторе модно делать клиентов под веб сервисы. V>А мобильный сегмент сегодня задаёт тон.
Есть какие-нибудь цифры, которые это подтверждают?
По моим ощущениям веб побольше мобильной разработки, особенно учитывая,
что на веб технологиях можно и для мобил разрабатывать.
Здравствуйте, vdimas, Вы писали:
V>Больше не значит лучше. V>Современный браузер — плохая платформа для приложений. V>Просто отвратительная.
Согласен.
K>> что на веб технологиях можно и для мобил разрабатывать. V>Можно, но не нужно или самое элементарное, что можно сделать за вечер. V>Всё-таки, энергоэффективность в мобильной области не на последнем месте.
Вроде не все так уж плохо, по крайней мере для простых формочек, которых большинство.
K>> Вроде не все так уж плохо, по крайней мере для простых формочек, которых большинство.
V>Если эти формочки на HTML-технологиях, то это очень тяжело. V>Это целый браузер, считай, поднимается для работы минимального приложения.
Здравствуйте, Keith, Вы писали:
V>>Если эти формочки на HTML-технологиях, то это очень тяжело. V>>Это целый браузер, считай, поднимается для работы минимального приложения. K> В теории — да, но на практике нормально работает.
Здравствуйте, Keith, Вы писали:
K>для разработки нативных приложений — визуальный редактор WISYWIG
Адобовский Дримвивер, а также есть несколько (много) от небольших фирм.
Есть онлайн конструкторы, wix, LPTracker и другие подобные.
По быстроте и удобству мне они кажутся на порядок лучше нэйтивных GUI билдеров (акак формо-шлепов).
Видео демо якобы крутейшего Qt там чего-то какие-то убогие слайдеры — такие видео демки для html были примерно 10-15 лет назад
и то гораздо круче, красивее, тени, сияние, 3D эффекты, драг-н-дропы в работе, а не дизайне и тд. И это было много много лет назад.
Такие демки Qt когда их приводят в качестве док. что Qt круче html-js-css вызывают только смех.
С компонентами все Ок, гуглить полифил, шадоу дом и тд.
Верстка даже до появления несколько лет назад флекс-бок была быстра и удобна, адаптивна, резиновая и тд.
Сейчас еще и флуид грид и теперь html-js-css это уже "полиграфического" уровня дизайнерская система.
Грубо говоря поезд ушел и все эти гуи билдеры которые не перейдут на поддержку html просто вымрут, быстро, очень быстро,
ибо убоги и безнадежно отстали.
Про браузер и что его тяжело вообще не понял, браузеры всегда есть на всех мыслимых девайсах от десктопа до смартфонов.
В чем тут проблема то? :-o
Он скорее графический html редактор, но контролов для разработки
я не увидел.
L>а также есть несколько (много) от небольших фирм.
А что-то более приспособленное для кастомной разработки есть?
Чтобы накидать контролов и быстро описать логику связывающую контролы?
Еще бы это на angular/react....
L>Есть онлайн конструкторы, wix, LPTracker и другие подобные.
Это скорее шаблоны с возможностью их модификации.
И сложную кастомную логику туда никак не запихнуть, только лэндинг пейджи и пр.
L>По быстроте и удобству мне они кажутся на порядок лучше нэйтивных GUI билдеров (акак формо-шлепов).
В нативных формошлепах легко подключить произвольные контролы и легко сразу нафигачить логику и запустить.
В CMS редакторах типа Wordpress'а более менее удобно делать только статический контент, но не кастомную логику.
L>С компонентами все Ок, гуглить полифил, шадоу дом и тд.
Полифил — это вроде фичи браезера реализованные через js библиотеки?
А Shadow DOM — это техника для быстрой отрисовки UI.
Компонентов не нашел.
L>Грубо говоря поезд ушел и все эти гуи билдеры которые не перейдут на поддержку html просто вымрут, быстро, очень быстро, L>ибо убоги и безнадежно отстали. L>
Здравствуйте, Keith, Вы писали:
L>>Адобовский Дримвивер
K> Он скорее графический html редактор, но контролов для разработки K> я не увидел.
в 99% мне надо кнопки, красивые или наоборот плоские, т.е. скинированные под заказчика
они там есть, инпут, чек боксы, слайдеры — все есть.
Резиновая верстка нэйтивная или под бутстрап — есть. Картинки, слайды, галереи — есть
медиа плеер, есть, таблицы — есть... графики чарты -есть. В принципе набор больше или сопоставим
с Дельфиским и кроме того все сразу из коробки со скинами через css.
K> Еще бы это на angular/react....
в настоящий момент имхо эти уродцы дублируют и не полностью нэйтивные возможности DOM-css-html-js
Нафига они вообще нужны ума не приложу, мертвая ветвь эволюции...
L>>Есть онлайн конструкторы, wix, LPTracker и другие подобные.
K> Это скорее шаблоны с возможностью их модификации.
вы их не видели — это полноценные конструкторы от 0 до оплаты кредиткой товаров и работающие воронки продаж
прямо из коробки с аналитикой и я.вебмастер и собственной системой трекинга даже телефоов и оф-лайн продаж
короче могучие всеобъемлющие системы...(для среднего бизнеса самое оно)
L>>По быстроте и удобству мне они кажутся на порядок лучше нэйтивных GUI билдеров (акак формо-шлепов).
K> В нативных формошлепах легко подключить произвольные контролы и легко сразу нафигачить логику и запустить. K> В CMS редакторах типа Wordpress'а более менее удобно делать только статический контент, но не кастомную логику.
L>>С компонентами все Ок, гуглить полифил, шадоу дом и тд.
K> Полифил — это вроде фичи браезера реализованные через js библиотеки?
нет,это для компонентов.
K> А Shadow DOM — это техника для быстрой отрисовки UI.
нет, это инкапсуляция — следующая ступень после ифрайма на которых и так можно почти все.
я как бы несколько радикализирую чтобы интересней дискутировать...
но в принципе да... html типа покрывает все потребности в построении ГУИ с большим запасом
все остальное как-то не есть уже необходимость...
если бы вместо хамл был хтмл то все стало бы намного круче и удобней...
а про хамл никто бы уже через месяц не вспомнил...
и еще одно большое преимущество — много дизайнеров — не програмеро
но могут сделать отличный дизайн на html адаптивный резиновый красивый живой и тд
т.е. разделение труда — программер это программер, а дизайне это дизайнер
а на хамле что-то и не слышал про дизайнеров таких, все программеры сами...
ну и если нет худ. образование соответственно убогость ГУИ
типа нарисуют в Qt четрые тонких красных полоски на черном фоне
и начинают на форумах постить СМОТРИ КАК КРУТО НА Qt можно !!!
L>в 99% мне надо кнопки, красивые или наоборот плоские, т.е. скинированные под заказчика L>они там есть, инпут, чек боксы, слайдеры — все есть.
Autocomplete тот же или mutli-select (как для тэгов) найти не просто
и не каждая реализация имеет идентификатор для выбранного элемента.
Master — Detail нет.
L>Резиновая верстка нэйтивная или под бутстрап — есть. Картинки, слайды, галереи — есть L>медиа плеер, есть, таблицы — есть... графики чарты -есть. В принципе набор больше или сопоставим L>с Дельфиским и кроме того все сразу из коробки со скинами через css.
Проблема в том, что результат работы DW нельзя сразу использовать в разработке, нужно
такщит это в какой-то вреймворк, параллельно раскладывая по частям.
Этой работы могло бы не быть.
K>> Еще бы это на angular/react.... L>в настоящий момент имхо эти уродцы дублируют и не полностью нэйтивные возможности DOM-css-html-js L>Нафига они вообще нужны ума не приложу, мертвая ветвь эволюции...
Каков ваш набор инструментов для разработки в веб?
L>>>Есть онлайн конструкторы, wix, LPTracker и другие подобные. K>> Это скорее шаблоны с возможностью их модификации. L>вы их не видели — это полноценные конструкторы от 0 до оплаты кредиткой товаров и работающие воронки продаж
Видел. Это просто управление контентом + модули, которые закрывают типовыю сценарии.
Кастомное приложение на них не сделать, тем более большое.
L>прямо из коробки с аналитикой и я.вебмастер и собственной системой трекинга даже телефоов и оф-лайн продаж L>короче могучие всеобъемлющие системы...(для среднего бизнеса самое оно)
Для определенных категорий бизнеса — да.
Меня интересует разработка полностью кастомного софта, а не закрытие потребностей разных видов бизнеса.
L>>>По быстроте и удобству мне они кажутся на порядок лучше нэйтивных GUI билдеров (акак формо-шлепов).
Они закрывают более узкие потребности.
Вот скажем если я хочу разрабатывать решения для компаний типа Uber или хитровыдуманную ERP, то
на CMS это будет явно сложнее чем с нуля написать кастомный софт.
K>> Полифил — это вроде фичи браезера реализованные через js библиотеки? L>нет,это для компонентов.
Т.е. типа компонента, который инкапслирует в себе html+css+js.
Не вижел большой распростаннености этого подхода, есть же компоненты как в Angular/React,
причем ангуляровский формат вроде одобрен в основной спеке HTML vNext.
L>я как бы несколько радикализирую чтобы интересней дискутировать...
L>но в принципе да... html типа покрывает все потребности в построении ГУИ с большим запасом
HTML+CSS+JS покрывает даже больше чем нужно и в этом тоже может быть проблема.
Разработка приложения для iOS например занимает меньше ресурсов, чем разработка для web.
Потому что нет двух людей — дизайнера и верстальщика.
Это не только сокращает стоимость, но и кол-во, часто не простых, коммуникаций.
L>все остальное как-то не есть уже необходимость... L>если бы вместо хамл был хтмл то все стало бы намного круче и удобней...
Не согласен, думаю все было бы запутанней и дороже.
L>а про хамл никто бы уже через месяц не вспомнил...
Xaml не идеален, но он хорошо инкапсулирует графический элемент с его логикой,
остается только написать код, обрабатывающий UI и приложение готово в тот же день.
А вот задизайнить, сверстать, разобрать верстку и засунуть в фреймворк занимает
катастрофически больше времени.
L>и еще одно большое преимущество — много дизайнеров — не програмеро L>но могут сделать отличный дизайн на html адаптивный резиновый красивый живой и тд
Много людей, которые готовы решить проблемы, которых в нативной разработке нет )
Нативные приложения может не так круты как веб в том, чтобы в окне приложения шел
снег и красиво ложился на контролы, но это не оправдывает стоимость и сроки, на мой взгляд.
Time to market у нативных приложений сильно выше.
L>т.е. разделение труда — программер это программер, а дизайне это дизайнер L>а на хамле что-то и не слышал про дизайнеров таких, все программеры сами... L>ну и если нет худ. образование соответственно убогость ГУИ
Лучше сдандартный UI, но быстро созданное приложение с работающим функционалом за 30% цены,
чем очень красивый UI но позже и в три раза дороже.
Стандартный UI кстати не сложно сделать резиновым и даже красивым, если потратить немного больше времени.
Красота понятие относительное, однако большинство приложений для iOS и MacOS сложно
назвать некрасивыми, хотя дизайнер и верстальщик в процессе не учавствуют.
K> Xaml не идеален, но он хорошо инкапсулирует графический элемент с его логикой, K> остается только написать код, обрабатывающий UI и приложение готово в тот же день. K> А вот задизайнить, сверстать, разобрать верстку и засунуть в фреймворк занимает K> катастрофически больше времени.
ерунду глаголишь, просты ты не верстал, верстается на флексбоксах и флуид гридах
быстро и очень качественно, есть формошлепы — например адобовский ДримВивер,
ну или ЛПГенератор, тут уже счет идет на минуты если не секунды и все готово и работает.
K> Лучше сдандартный UI, но быстро созданное приложение с работающим функционалом за 30% цены, K> чем очень красивый UI но позже и в три раза дороже.
На сторе плохой гуи не пройдет мождерацию, потому там нормальный дизайн — это обязательно.
В гугле — убогий интерфейс не сможет выбиться среди тысяч аналогов, так что там если надо успех то дизайн это тоже обязательный элемент
Это не дорого — дизайнеров толковых миллионы, конкуренция у них зверская, многие ТОЛКОВЫЕ готовы работать бесплатно
для набора траста-рейтинга и тд на биржах заказов типа фриланса или фивера. Такая дикая конкуренция программерам и не снилась.
Вообщем нормальный дизайн это сейчас НЕ дорого из-за конкурентной среды.
На маке-ай-фоне-андроиде-виндах НЕТ дизайна в нативных гую потому что они плоские.
Но вот следующий шаг уже сделанный гуглом — материальный дизайн, пока мало кто его умеет делать,
это уже сложнее, там уже пропорции, баланс цветов, мутации и другие сугубо дизайнерские фишки имеются.
Читайте доки, имхо там дешевле многократно нанять толкового дизайнера с портфолио в материальном дизайне
чем пытаться самому не имея художественного образования или не будучи прирожденным талантом самоучкой в дизайне.
K> Проблема в том, что результат работы DW нельзя сразу использовать в разработке, нужно K> такщит это в какой-то вреймворк, параллельно раскладывая по частям. K> Этой работы могло бы не быть.
ничего не понял, у нас в фирме делают так, дизайнер выкатывает проект ДВ, резиновый т.к. ориентировка на мобилы,
я навешиваю логику в JS. Все готово, и сразу работает. ПРо фрейм-ворки не слыхал, мне не нужны.
(схему-тз для дизайнера выдает наш архитектор, которому инфа идет от заказчика и тех. менеджера проекта,
серверный программер — да, если нужно согласованно делаем)
K> Каков ваш набор инструментов для разработки в веб?
Мой набор сегодня = html+js и готовый гуи от нашего дизайнера (html+css).
при наличии shadow dom, флекс бокс и флуид-грид и современном js всякая разумная необходимость в каких-то фрейморках полностью отпала.
Верстал.
L>верстается на флексбоксах и флуид гридах L>быстро и очень качественно,
А контролы? Не так чтобы искать по интернетам и помтом просовывать css + js,
а с визуальным предпросмотром и подключением с Drag'n'Drop?
L>есть формошлепы — например адобовский ДримВивер,
И один и тот же компонент на всех страницах один и правится в одном месте?
И можно сразу к странице логику писать?
L>ну или ЛПГенератор, тут уже счет идет на минуты если не секунды и все готово и работает.
Я говорю про кастомную разработку, а не лэндинги, где логики вообще нет.
И не про CMS, где тоже логики нет.
K>> Лучше сдандартный UI, но быстро созданное приложение с работающим функционалом за 30% цены, K>> чем очень красивый UI но позже и в три раза дороже. L>На сторе плохой гуи не пройдет мождерацию, потому там нормальный дизайн — это обязательно.
В AppStore все из стандартных элементов и проблем с красотой нет.
L>Это не дорого — дизайнеров толковых миллионы, конкуренция у них зверская, многие ТОЛКОВЫЕ готовы работать бесплатно L>для набора траста-рейтинга и тд на биржах заказов типа фриланса или фивера. Такая дикая конкуренция программерам и не снилась. L>Вообщем нормальный дизайн это сейчас НЕ дорого из-за конкурентной среды.
Ну да, дизайнят бесплатно, верстают беслпатно и все качественно.
И объяснять никому ничего не надо — все телепаты делают отлично с первого раза.
)
L>На маке-ай-фоне-андроиде-виндах НЕТ дизайна в нативных гую потому что они плоские.
Что значит плоские? Нативные контролы могут быть любые.
L>Но вот следующий шаг уже сделанный гуглом — материальный дизайн, пока мало кто его умеет делать,
Вот он как раз плоский и его минималистичность только гуглу подходит и то не везде.
Чуть посложнее контролов уже нет.
L>это уже сложнее, там уже пропорции, баланс цветов, мутации и другие сугубо дизайнерские фишки имеются.
Это все дело вкуса, мне материальный дизайн не очень.
L>Читайте доки, имхо там дешевле многократно нанять толкового дизайнера с портфолио в материальном дизайне L>чем пытаться самому не имея художественного образования или не будучи прирожденным талантом самоучкой в дизайне.
Для нативной разработки можно взять стандартные контролы и выглядеть они будут очень хорошо.
Это если iOS/MacOS. Да и для винды отлично все в этом плане. Про андройд не знаю.
K>> Каков ваш набор инструментов для разработки в веб? L>Мой набор сегодня = html+js и готовый гуи от нашего дизайнера (html+css).
От дизайнера обычно дизайн, а верстка от верстальщика.
Это два дополнительных человека с нормальными зарплатами и под. проблемами в комуникациях.
Меню, подвал и прочие общие блоик не выделяете?
Если их надо поправить, то это на всех страницах надо делать?
L>при наличии shadow dom, флекс бокс и флуид-грид и современном js всякая разумная необходимость в каких-то фрейморках полностью отпала.
Что такое shadow dom? Нагуглить прикладного описания не смог.
K> а с визуальным предпросмотром и подключением с Drag'n'Drop?
Дримвивер видел?
K> И один и тот же компонент на всех страницах один и правится в одном месте? K> И можно сразу к странице логику писать?
так это из коробки в html-js-css-shadow-dom
L>>ну или ЛПГенератор, тут уже счет идет на минуты если не секунды и все готово и работает.
K> Я говорю про кастомную разработку, а не лэндинги, где логики вообще нет. K> И не про CMS, где тоже логики нет.
тогда проясни, а что ты имеешь ввиду — игры?
K> В AppStore все из стандартных элементов и проблем с красотой нет.
не согласен, по опыту, четкий дизайнерский гуи у нас давал 100 кратный прирост по загрузкам без изменения логики.
K> Что значит плоские? Нативные контролы могут быть любые.
ха-ха читай гайд-лайны эпла. Кратко — могут, но не должны, так как модераторы могут одобрить, но не должны!
K> Это все дело вкуса, мне материальный дизайн не очень.
твое мнение — ноль, важно мнение модераторов и главное юзеров.
Они любят в том числе и под действием пропаганды мат. дизайна гуглом.
Значит надо делать.
K>> а с визуальным предпросмотром и подключением с Drag'n'Drop? L>Дримвивер видел?
Видел.
Ограниченный набор компонентов.
Не в курсе правда можно ли там делать кастомный элемент,
на всех страницах его использовать и менять в одном месте.
Наверное можно...
K>> И один и тот же компонент на всех страницах один и правится в одном месте? K>> И можно сразу к странице логику писать? L>так это из коробки в html-js-css-shadow-dom
Т.е. диззайнер-верстальщик сразу на компоненты нарезает?
И остается только JS писать?
L>тогда проясни, а что ты имеешь ввиду — игры?
Автоматизация бизнеса.
Такси, банки, финансовые приложения, покупка билетов (тренспорт или ивенты).
Любое приложение с произвольной не тривиальной логикой.
K>> В AppStore все из стандартных элементов и проблем с красотой нет. L>не согласен, по опыту, четкий дизайнерский гуи у нас давал 100 кратный прирост по загрузкам без изменения логики.
Я не говорю, что хороший дизайн не влияет на загрузки.
Полуголые женские тела дадут 1000 кратный прирост.
На нативных платформах с дизайном все проще, никто не ждет чтобы "снег шел".
Зато разработка значительно быстрее.
Даже в вашем случае если дизайнер и верстальщик один, то это в два раза больше людей,
т.е. в два раза дороже и примерно в два раза дольше делать.
K>> Что значит плоские? Нативные контролы могут быть любые. L>ха-ха читай гайд-лайны эпла. Кратко — могут, но не должны, так как модераторы могут одобрить, но не должны!
Разных наборов элементов полно на любой вкус.
Венегрет конечно апле не пропустит, но если в едином стиле, то хоть выпуклые с тенями и пр.
K>> Это все дело вкуса, мне материальный дизайн не очень. L>твое мнение — ноль, важно мнение модераторов и главное юзеров. L>Они любят в том числе и под действием пропаганды мат. дизайна гуглом. L>Значит надо делать.
K>> От дизайнера обычно дизайн, а верстка от верстальщика. L>нет, сейчас можно на хид хантере найти НЕдорогих дизайнеров прекрасно владеющими резиновой версткой.
K>>Когда же инструментарий для веб разработки приблизится к уровню инструментов K>>для разработки нативных приложений CS>Пример этих "нативных приложений"?
Здравствуйте, koenig, Вы писали:
L>>при наличии shadow dom, флекс бокс и флуид-грид и современном js всякая разумная необходимость в каких-то фрейморках полностью отпала.
K>подождите-ка, что у вас за клиенты такие прекрасные, что только браузерами в которых shadow dom доступен пользуются? я тоже таких хочу
K>>подождите-ка, что у вас за клиенты такие прекрасные, что только браузерами в которых shadow dom доступен пользуются? я тоже таких хочу
L>https://caniuse.com/#search=shadow%20dom L>Хром скачать установить соглашаются даже продавцы в М-Видео
завидую белой завистью
для меня задепрекейтить всё старее 11 эксплорера — несбыточная мечта
Здравствуйте, Keith, Вы писали:
K>Когда же инструментарий для веб разработки приблизится к уровню инструментов K>для разработки нативных приложений — визуальный редактор WISYWIG K>с возможностью легко подключать компоненты и визуально компоновать страницу.
когда это произойдёт, тогда ты сразу же пойдёшь на мороз. а на твоё место наймут индуса-фрилансера или студента с горящими глазами. за тарелку риса. или супа.
или зарплата твоя станет такая, что будет хватать только на доширак. а что? такую работу любой сможет делать.
M>когда это произойдёт, тогда ты сразу же пойдёшь на мороз. а на твоё место наймут индуса-фрилансера или студента с горящими глазами. за тарелку риса. или супа. M>или зарплата твоя станет такая, что будет хватать только на доширак. а что? такую работу любой сможет делать.
Здравствуйте, Keith, Вы писали:
M>>когда это произойдёт, тогда ты сразу же пойдёшь на мороз. а на твоё место наймут индуса-фрилансера или студента с горящими глазами. за тарелку риса. или супа. M>>или зарплата твоя станет такая, что будет хватать только на доширак. а что? такую работу любой сможет делать.
K>В нативной разработке платят нормально.
потому там и платят нормально, что тебе нужно решать проблемы, которые ты описал.
M>>>когда это произойдёт, тогда ты сразу же пойдёшь на мороз. а на твоё место наймут индуса-фрилансера или студента с горящими глазами. за тарелку риса. или супа. M>>>или зарплата твоя станет такая, что будет хватать только на доширак. а что? такую работу любой сможет делать.
K>>В нативной разработке платят нормально.
M>потому там и платят нормально, что тебе нужно решать проблемы, которые ты описал.
Ничего не понял. Я говорил про проблемы инструментов разработки под веб, в сравнении с нативными.
Вы сказали, что в если в вебе будет так же легко, как в нативных, то там будут демпинговать стунденты-индусы за рис (как-будто не демпингуют).
Я сказал, что в нативной хоть и нет проблем веба, но платят нормально.
K>Ничего не понял. Я говорил про проблемы инструментов разработки под веб, в сравнении с нативными. K>Вы сказали, что в если в вебе будет так же легко, как в нативных, то там будут демпинговать стунденты-индусы за рис (как-будто не демпингуют). K>Я сказал, что в нативной хоть и нет проблем веба, но платят нормально.
я сказал, что где бы ни стало легко, там станет так же мало денег и много голодных студентов.
W>>http://unigui.com W>>очень хвалят. очень просто все делается. компонентный подход.
TL>Для дотнета бы asp.net mvc.
Вчера наткнулся на http://ext.net/
Частично должно облегчить работу для тех, кто плохо верстает и платить верстальщику не хочет.
Правда произвольной красоты не будет и с кастомизацией, наверняка, не просто, как в любых компонентах...
Сам в продакшене не использовал, продаю за что купил.
Здравствуйте, Keith, Вы писали:
vsb>>Хз, нативная разработка лет на 10 отстала от веба. Посмотри на популярность react native, хотя бы.
K>В чем отстала?
В вебе изменение это нулевая задержка. Поменял, обновил — всё работает. Есть много инструментов, которые вообще изменения патчат на лету: изменил, в соседнем окошке браузера изменения тут же применились без перезапуска приложения. В iOS изменил, нажал компиляцию, попил чаю, оно перекомпилировалось, запустил, оно приложение с нуля запустило, нажал 10 кнопок на стрёмном симуляторе, наконец-то пришёл к этому экрану. Ещё оно может упасть фиг знает откуда с каким-то левым стектрейсом, потому что где-то там память испортилось, у нас же нэйтив.
K>Если визуально, то посмотрите WPF и iOS — приятные интерфейсы.
Я говорю с точки зрения разработчика. С точки зрения дизайнера вообще плевать, любой интерфейс рисуется из бордеров, бэкграундов, теней и прочих примитивов, тут разницы нет. Разве что в вебе современные технологии лэйаута приятней нативных, тот же флексбокс гораздо удобней iOS-овских констрейнтов.
vsb>>>Хз, нативная разработка лет на 10 отстала от веба. Посмотри на популярность react native, хотя бы. K>>В чем отстала? vsb>В вебе изменение это нулевая задержка. Поменял, обновил — всё работает. vsb>Есть много инструментов, которые вообще изменения патчат на лету: изменил, в соседнем окошке браузера изменения тут же применились без перезапуска приложения.
В WPF это сделали.
vsb>В iOS изменил, нажал компиляцию, попил чаю, оно перекомпилировалось, запустил, оно приложение с нуля запустило, нажал 10 кнопок на стрёмном симуляторе, наконец-то пришёл к этому экрану.
Swift может интерпретироваться, на сколько я понимаю.
vsb>Ещё оно может упасть фиг знает откуда с каким-то левым стектрейсом, потому что где-то там память испортилось, у нас же нэйтив.
Крайне редкое происшествие, в отличие от "variable is undefined".
Отладка js в браузере гораздо неудобней, чем в IDE.
И раз уж про это речь, то отладка внутренних ошибок angular/react/др. фреймворком и библиотек то еще удовольствие.
vsb>Разве что в вебе современные технологии лэйаута приятней нативных, тот же флексбокс гораздо удобней iOS-овских констрейнтов.
Насчет iOS'вских не скажу, но вот WinForm'овские такие же простые.
Здравствуйте, Keith, Вы писали:
vsb>>Есть много инструментов, которые вообще изменения патчат на лету: изменил, в соседнем окошке браузера изменения тут же применились без перезапуска приложения. K>В WPF это сделали.
А в Qt? Gtk? Cocoa? Cocoa Touch?
vsb>>В iOS изменил, нажал компиляцию, попил чаю, оно перекомпилировалось, запустил, оно приложение с нуля запустило, нажал 10 кнопок на стрёмном симуляторе, наконец-то пришёл к этому экрану.
K>Swift может интерпретироваться, на сколько я понимаю.
Вряд ли, это компилируемый язык, причём довольно медленно компилируемый.
vsb>>Ещё оно может упасть фиг знает откуда с каким-то левым стектрейсом, потому что где-то там память испортилось, у нас же нэйтив.
K>Крайне редкое происшествие, в отличие от "variable is undefined".
Как раз это редкое проишествие, его любой линтер отлавливает на стадии печатанья кода.
K>Отладка js в браузере гораздо неудобней, чем в IDE.
Почему? Я считаю, что наоборот. Банальный просмотр DOM со всеми пропертями в живом приложении, я такого кроме браузера нигде не видел.
K>И раз уж про это речь, то отладка внутренних ошибок angular/react/др. фреймворком и библиотек то еще удовольствие.
А отладка внутренних ошибок аналогичных нативных фреймворков приятней?
vsb>>Разве что в вебе современные технологии лэйаута приятней нативных, тот же флексбокс гораздо удобней iOS-овских констрейнтов.
K>Насчет iOS'вских не скажу, но вот WinForm'овские такие же простые.
K>Видимо это вопрос опыта и вкуса — кому что ближе.
Про C# я почти ничего не знаю, когда-то немного писал кода без GUI, может там мекка, но с Gtk/C, Qt/C++, WinAPI/C++, iOS, macOS могу сравнивать, веб считаю удобней. У нативных приложений есть свои плюсы: большая предсказуемость, меньшее потребление памяти, но в плане удобства они проигрывают.
Здравствуйте, vsb, Вы писали:
K>>Swift может интерпретироваться, на сколько я понимаю. vsb>Вряд ли, это компилируемый язык, причём довольно медленно компилируемый.
Вообще то существуют (и даже активно используются в некоторых узких областях) интерпретаторы даже C++. ))) Это так, безотносительно вашей дискуссии... )
K>>И раз уж про это речь, то отладка внутренних ошибок angular/react/др. фреймворком и библиотек то еще удовольствие. vsb>А отладка внутренних ошибок аналогичных нативных фреймворков приятней?
Нативные/ненативные — это всё не принципиально. А вот язык со статический или динамической типизацией — тут разница вполне себе есть. Языки с динамической типизацией несут в себе несколько дополнительных классов потенциальных ошибок.
vsb>Про C# я почти ничего не знаю, когда-то немного писал кода без GUI, может там мекка, но с Gtk/C, Qt/C++, WinAPI/C++, iOS, macOS могу сравнивать, веб считаю удобней. У нативных приложений есть свои плюсы: большая предсказуемость, меньшее потребление памяти, но в плане удобства они проигрывают.
Под удобством, ты, как я понимаю, подразумеваешь удобство разработки, правильно?
Здравствуйте, alex_public, Вы писали:
_>Вообще то существуют (и даже активно используются в некоторых узких областях) интерпретаторы даже C++. ))) Это так, безотносительно вашей дискуссии... )
Это понятно, но мы же говорим про реальные и доступные средства разработки, а не про теоретические концепиции. В случае iOS это Xcode, в котором я не видел ничего, похожего на live reload.
_>Нативные/ненативные — это всё не принципиально. А вот язык со статический или динамической типизацией — тут разница вполне себе есть. Языки с динамической типизацией несут в себе несколько дополнительных классов потенциальных ошибок.
При желании для веба можно писать и на языках со статической типизацией: typescript (на нём вроде angular написан и он рекомендуется для написания приложений на нём), flow (это уже для React) и некоторые менее популярные варианты.
vsb>>Про C# я почти ничего не знаю, когда-то немного писал кода без GUI, может там мекка, но с Gtk/C, Qt/C++, WinAPI/C++, iOS, macOS могу сравнивать, веб считаю удобней. У нативных приложений есть свои плюсы: большая предсказуемость, меньшее потребление памяти, но в плане удобства они проигрывают.
_>Под удобством, ты, как я понимаю, подразумеваешь удобство разработки, правильно?
Конечно, в плане удобства использования всё зависит от качества реализации, а не от платформы. Популярные приложения вроде Discord это хорошо показывают, хоть и написано на JavaScript, хоть и представляет собой тупо WebView, однако же на практике он удобней кучи нативных аналогов, что народ ценит и перебирается на него.
Здравствуйте, vsb, Вы писали:
_>>Вообще то существуют (и даже активно используются в некоторых узких областях) интерпретаторы даже C++. ))) Это так, безотносительно вашей дискуссии... ) vsb>Это понятно, но мы же говорим про реальные и доступные средства разработки, а не про теоретические концепиции. В случае iOS это Xcode, в котором я не видел ничего, похожего на live reload.
Я же говорю, эта моя фраза была не в контексте вашей дискуссии про разработку GUI, а просто я не мог пропустить твоё высказывание типа "компилируемый, да ещё и долго — значит не может быть интерпретатора". Да, и кстати интерпретатор C++ — это совсем не теоретическая концепция, а вполне себе рабочий инструмент и часть известного и важного фреймворка: https://root.cern.ch/cling.
_>>Нативные/ненативные — это всё не принципиально. А вот язык со статический или динамической типизацией — тут разница вполне себе есть. Языки с динамической типизацией несут в себе несколько дополнительных классов потенциальных ошибок. vsb>При желании для веба можно писать и на языках со статической типизацией: typescript (на нём вроде angular написан и он рекомендуется для написания приложений на нём), flow (это уже для React) и некоторые менее популярные варианты.
Да, typescript — это аргумент. Хотя я бы назвал его языком с полустатической типизацией (всё же опциональность указания типов действует на многих программистов расслабляюще).
_>>Под удобством, ты, как я понимаю, подразумеваешь удобство разработки, правильно? vsb>Конечно, в плане удобства использования всё зависит от качества реализации, а не от платформы. Популярные приложения вроде Discord это хорошо показывают, хоть и написано на JavaScript, хоть и представляет собой тупо WebView, однако же на практике он удобней кучи нативных аналогов, что народ ценит и перебирается на него.
На мой взгляд, если говорить об удобстве разработки GUI, то тут всё (кроме веб'а — там априори только одна часть) делится на две принципиальные части: нам требуется GUI использующий стандартные окна и контролы платформы или же нам нужно что-то оригинальное под это конкретное приложение (условно говоря круглые кнопки раскрашенные в горошек). В первом случае при использование фреймворков базирующийся (как wxWidgets) или эмулирующих (как Qt) стандартные окна и контролы платформы мы получим результат (а особенно если использовать удобный визуальный редактор) гораздо быстрее, чем при использование вариаций на тему HTML. Если же нам требуется второй вариант (т.е. некий оригинальный GUI), то сделать его на HTML или его родственниках видимо будет быстрее. Это лично моя оценка, на основание опыта работы с разными фреймворками на разных платформах.
Здравствуйте, alex_public, Вы писали:
vsb>>При желании для веба можно писать и на языках со статической типизацией: typescript (на нём вроде angular написан и он рекомендуется для написания приложений на нём), flow (это уже для React) и некоторые менее популярные варианты.
_>Да, typescript — это аргумент. Хотя я бы назвал его языком с полустатической типизацией (всё же опциональность указания типов действует на многих программистов расслабляюще).
А dynamic в C# это не полустатическая типизация? Я считаю, что статическая типизация это не какой-то идол, которому надо молиться (иначе весь мир давно бы писал на Haskell, который эту типизацию возвёл в абсолют), а инструмент, который иногда к месту, а иногда мешает (тогда мы юзаем Object и кастуем к нужному типу, если говорить в терминологии Java).
_>>>Под удобством, ты, как я понимаю, подразумеваешь удобство разработки, правильно? vsb>>Конечно, в плане удобства использования всё зависит от качества реализации, а не от платформы. Популярные приложения вроде Discord это хорошо показывают, хоть и написано на JavaScript, хоть и представляет собой тупо WebView, однако же на практике он удобней кучи нативных аналогов, что народ ценит и перебирается на него.
_>На мой взгляд, если говорить об удобстве разработки GUI, то тут всё (кроме веб'а — там априори только одна часть) делится на две принципиальные части: нам требуется GUI использующий стандартные окна и контролы платформы или же нам нужно что-то оригинальное под это конкретное приложение (условно говоря круглые кнопки раскрашенные в горошек). В первом случае при использование фреймворков базирующийся (как wxWidgets) или эмулирующих (как Qt) стандартные окна и контролы платформы мы получим результат (а особенно если использовать удобный визуальный редактор) гораздо быстрее, чем при использование вариаций на тему HTML. Если же нам требуется второй вариант (т.е. некий оригинальный GUI), то сделать его на HTML или его родственниках видимо будет быстрее. Это лично моя оценка, на основание опыта работы с разными фреймворками на разных платформах.
Согласен, но тут вопрос — какой GUI нужен на практике? Что такое стандартные контролы платформы? В последнее время дизайнеры диктуют, какие контролы должны быть в приложении. Когда-то давно был WinAPI и его встроенные классы окон, вроде как они стандартные. Но самый популярный плеер всех времён и народов WinAMP наплевал на эти стандарты и ему это не помешало (туда же ICQ, например). Потом Microsoft наплевал на эти стандарты, выпустив в очередном офисе аляповатый интерфейс. Сейчас в Windows 10 вообще мешанина интерфейсов из 90-х, 2000-х и 2015-х. В Linux никаких стандартов никогда и не было. macOS держит марку, но это скорее исключение. На мобильных платформах вообще разброд и шатание. Что такое стандартный контрол кнопки в iOS? Надпись синим цветом? Какой-то абсолютно минимальный набор стандартных контролов в виде табов есть, но там настолько примитивный дизайн, что его можно реплицировать на HTML+CSS за пару часов. Поэтому да, если нам нужен дизайн корпоративного приложения из 90-х с WinAPI-шными кнопочками и textedit-ами, HTML может и не подойти (хотя я почему-то не сомневаюсь, что при желании качественную библиотеку стилей найти будет недолго), но судя по всему в основном все лепят что-то нестандартное.
_>>На мой взгляд, если говорить об удобстве разработки GUI, то тут всё (кроме веб'а — там априори только одна часть) делится на две принципиальные части: нам требуется GUI использующий стандартные окна и контролы платформы или же нам нужно что-то оригинальное под это конкретное приложение (условно говоря круглые кнопки раскрашенные в горошек). В первом случае при использование фреймворков базирующийся (как wxWidgets) или эмулирующих (как Qt) стандартные окна и контролы платформы мы получим результат (а особенно если использовать удобный визуальный редактор) гораздо быстрее, чем при использование вариаций на тему HTML. Если же нам требуется второй вариант (т.е. некий оригинальный GUI), то сделать его на HTML или его родственниках видимо будет быстрее. Это лично моя оценка, на основание опыта работы с разными фреймворками на разных платформах.
vsb>Согласен, но тут вопрос — какой GUI нужен на практике? Что такое стандартные контролы платформы? В последнее время дизайнеры диктуют, какие контролы должны быть в приложении. Когда-то давно был WinAPI и его встроенные классы окон, вроде как они стандартные. Но самый популярный плеер всех времён и народов WinAMP наплевал на эти стандарты и ему это не помешало (туда же ICQ, например). Потом Microsoft наплевал на эти стандарты, выпустив в очередном офисе аляповатый интерфейс. Сейчас в Windows 10 вообще мешанина интерфейсов из 90-х, 2000-х и 2015-х. В Linux никаких стандартов никогда и не было. macOS держит марку, но это скорее исключение. На мобильных платформах вообще разброд и шатание. Что такое стандартный контрол кнопки в iOS? Надпись синим цветом? Какой-то абсолютно минимальный набор стандартных контролов в виде табов есть, но там настолько примитивный дизайн, что его можно реплицировать на HTML+CSS за пару часов. Поэтому да, если нам нужен дизайн корпоративного приложения из 90-х с WinAPI-шными кнопочками и textedit-ами, HTML может и не подойти (хотя я почему-то не сомневаюсь, что при желании качественную библиотеку стилей найти будет недолго), но судя по всему в основном все лепят что-то нестандартное.
В вебе, минимальный порог входа в создание приложения — это оплата работы дизайна и верстки в дополненеие к программированию.
В связи с этим же разработчики не могут так быстро нафигачить прототип на коленке.
Попадаются те, кто может сделать сразу все, но скорее в виде исключения, если нужно сделать что-то сложнее Bootstrap'а.
Получается, что при разработке веб-приложения длительность итерации работы с интерфейсом дольше и меньше наглядность (править текст), чем в нативной разработке (мышкой в интрефейсе).
Зато работа с кодом наоборот — в вебе в основном быстрая в работе интерпретация (и отностельно медленная в выполнении), а в нативной — компиляция долгая (но в проде быстрее).
— Веб победит как инструмент дефолтной разработкии (кроме вопросов перформанса и секьюрити),
если появится инструмент для удобного редактирования интерфейсов с возможностью создания кастомных контролов
как в виде группировки и обвязки логикой стандратных примитивных контролов, так и новых примитивных контролов.
— Нейтив победит, если решит проблему click-once обновления, станет кроссплатформенным
и сделает код интерпретируемым (при этом он может быть типизированным).
Задача веба кажется проще, но что-то таких инструментов до сих пор не появилось.
(подозреваю, что проблема в поддержке балагана браузеров)
На место единого кроссплатформенного решения сейчас всерьез претендует Xamarin.
Успехи довольно впечатляющие — .net кроссплатформенный (даже часы и телевизоры) и интерпретируемый,
редактор мгновенно перерисовывает изменения UI и логики прямо в режиме отладки.
На сколько далеко оно уедет в реализации и как будет тормозить и глючить — посмотрим через пару лет.
Здравствуйте, vsb, Вы писали:
_>>Да, typescript — это аргумент. Хотя я бы назвал его языком с полустатической типизацией (всё же опциональность указания типов действует на многих программистов расслабляюще). vsb>А dynamic в C# это не полустатическая типизация? Я считаю, что статическая типизация это не какой-то идол, которому надо молиться (иначе весь мир давно бы писал на Haskell, который эту типизацию возвёл в абсолют), а инструмент, который иногда к месту, а иногда мешает (тогда мы юзаем Object и кастуем к нужному типу, если говорить в терминологии Java).
Dynamic в C# и т.п. средства стирания типов, существующие во многих языках со статической типизацией (начиная с древнего void* в C), и это совсем другое. Они не меняют вид декларации в языке, а всего лишь указывают специальный тип, с которым кстати ещё и обычно сложнее работать. Т.е. существование такой возможности совсем не провоцирует программиста ставить её везде, где только можно.
_>>На мой взгляд, если говорить об удобстве разработки GUI, то тут всё (кроме веб'а — там априори только одна часть) делится на две принципиальные части: нам требуется GUI использующий стандартные окна и контролы платформы или же нам нужно что-то оригинальное под это конкретное приложение (условно говоря круглые кнопки раскрашенные в горошек). В первом случае при использование фреймворков базирующийся (как wxWidgets) или эмулирующих (как Qt) стандартные окна и контролы платформы мы получим результат (а особенно если использовать удобный визуальный редактор) гораздо быстрее, чем при использование вариаций на тему HTML. Если же нам требуется второй вариант (т.е. некий оригинальный GUI), то сделать его на HTML или его родственниках видимо будет быстрее. Это лично моя оценка, на основание опыта работы с разными фреймворками на разных платформах. vsb>Согласен, но тут вопрос — какой GUI нужен на практике? Что такое стандартные контролы платформы? В последнее время дизайнеры диктуют, какие контролы должны быть в приложении.
Ну это у кого как. )
vsb>Когда-то давно был WinAPI и его встроенные классы окон, вроде как они стандартные. Но самый популярный плеер всех времён и народов WinAMP наплевал на эти стандарты и ему это не помешало (туда же ICQ, например). Потом Microsoft наплевал на эти стандарты, выпустив в очередном офисе аляповатый интерфейс. Сейчас в Windows 10 вообще мешанина интерфейсов из 90-х, 2000-х и 2015-х.
Я поэтому и написал, что до сих пор оба эти "лагеря" существуют и процветают.
vsb>В Linux никаких стандартов никогда и не было.
Это не верная формулировка. Скорее можно говорить о существование нескольких конкурирующих стандартов. Причём с некоторым небольшим преимущством одного из них (Gnome).
vsb>macOS держит марку, но это скорее исключение. На мобильных платформах вообще разброд и шатание.
Опять же нет. Стандартные стили в дизайне под мобильные платформы вполне определены и стандартизованы даже в виде специальные гайдов.
vsb>Что такое стандартный контрол кнопки в iOS? Надпись синим цветом? Какой-то абсолютно минимальный набор стандартных контролов в виде табов есть, но там настолько примитивный дизайн, что его можно реплицировать на HTML+CSS за пару часов.
Только не забудь сделать так, чтобы ещё на каждой из платформ (где запускается твоё приложение) оно поддерживало местный (пускай и примитивный) дизайн. ))) Нативные GUI фреймворки это без проблем реализуют...
vsb>Поэтому да, если нам нужен дизайн корпоративного приложения из 90-х с WinAPI-шными кнопочками и textedit-ами, HTML может и не подойти (хотя я почему-то не сомневаюсь, что при желании качественную библиотеку стилей найти будет недолго), но судя по всему в основном все лепят что-то нестандартное.
Если мы говорим о ПО для обычных пользователей (не для проф. использования), то оно сейчас собственно только под мобильные платформы и имеет смысл. )))
если Микрософт их купит, как Xamrin, то может получиться кросс-платформенный view engine.
Если на нем завести Prism, то потенциально сможет конкурировать с html/css/js.
Здравствуйте, Keith, Вы писали:
K>Просьба K>Если кто-то нашел для себя продуктивный вариант (сравнимый по скорости с инструментами для нативной разработки), K>то поделитесь, пожалуйста, буду ОЧЕНЬ признателен.
Мне для удобства и скорости работы достаточно не трогать CSS и Javascript — поэтому использую Bootstrap и IntercoolerJS, со всем остальным справляется ASP.NET MVC и Visual Studio.
Здравствуйте, alex_public, Вы писали:
> В последнее время дизайнеры диктуют, какие контролы должны быть в приложении.
это правильно, если дизайнер толковый. с художественным образованием, то 100% правильно.
технари-программеры явно переоценивают себя, возомнив себя художниками...
также они культивируют совершенно бредовый невообразимый тезис что программа
должна выглядеть по разному на разных ОС, это является запредельным бредом.
За это надо расстреливать. нет, сжигать живьем. Тут я 100% на стороне дизайнеров
Никаких нативных контролов — за такие слова надо вводить уголовную ответственность.
Здравствуйте, loginx, Вы писали:
>> В последнее время дизайнеры диктуют, какие контролы должны быть в приложении. L>это правильно, если дизайнер толковый. с художественным образованием, то 100% правильно. L>технари-программеры явно переоценивают себя, возомнив себя художниками... L>также они культивируют совершенно бредовый невообразимый тезис что программа L>должна выглядеть по разному на разных ОС, это является запредельным бредом. L>За это надо расстреливать. нет, сжигать живьем. Тут я 100% на стороне дизайнеров L>Никаких нативных контролов — за такие слова надо вводить уголовную ответственность.
Ты похоже что-то напутал. Безусловно, что придумывающий свой дизайн программист — это крайне плохая идея. Но как раз в том то и дело, что при использование стандартных системных контролов программист не придумывает свой дизайн, а использует созданный профессиональными дизайнерами (из Microsoft, Google, Apple и т.п.), которые обычно (только попрошу не вспоминать последний "metro" дизайн от MS ) на голову лучше "шедевров" доморощенных дизайнеров.
) на голову лучше "шедевров" доморощенных дизайнеров.
