Здравствуйте, hrensgory, Вы писали:
H>16.01.2017 13:42, sr_dev пишет:
H>Давайте обменяемся опытом. У нас в яве на сервер-сайде отладка
С бэкендом всё так, да всё удобно
H>Вот появился у нас развесистый фронтенд, для примера на ангуляре, H>собираемый из кучи файлов (т.к. он реально развесистый) через gulp. H>Необходимо что-то изменить/проверить. Что делать? gulp build каждый раз H>запускать? Долго. Пробовали gulp watch — всё бы ничего, но на ряде машин H>под совершенно обычной вендой он выжирает весь ЦПУ. Ну и как уже отмечал H>коллега это ещё не всё — если у нас SPA, возможно придётся после F5 в H>браузере предварительно потыкать в кучу кнопок чтобы попасть в то место, H>которое нам интересно.
Сейчас у нас именно angular. Лично я делаю gulp build (вотч тормозит). Коллеги юзают gulp watch, может у них получше.
Всё правда, и f5 и куча кнопок. Но после gwt эти проблемы меня как то не достают особо.
Для отладки сборка без минифая. Отладка в браузере чаще всего (или webstorm, но тормозит).
Для разработки webstorm, достойнее для js ничего нет.
опа опа мы воюем с нато
любит хавать этот кал
путинская вата
16.01.2017 16:15, sr_dev пишет: > Но после gwt эти проблемы меня как то не > достают особо.
Пробовали очень давно GWT, отказались на этапе проб. Даже JSF на тот
момент оказался лучше.
> Для разработки webstorm, достойнее для js ничего нет.
Согласен ) Фронтендщики у нас тоже его используют.
Здравствуйте, Sharov, Вы писали:
HL>>>>Всё это говнище будет заменено чем-то новым и так же канет в лету, как и jQuery.
S>>>...без него ни один фреймворк не обходится...
I>>Это заблуждение.
S>Примеры.
Здравствуйте, hrensgory, Вы писали:
H>Вот появился у нас развесистый фронтенд, для примера на ангуляре, H>собираемый из кучи файлов (т.к. он реально развесистый) через gulp. H>Необходимо что-то изменить/проверить. Что делать? gulp build каждый раз H>запускать? Долго. Пробовали gulp watch — всё бы ничего, но на ряде машин H>под совершенно обычной вендой он выжирает весь ЦПУ. Ну и как уже отмечал H>коллега это ещё не всё — если у нас SPA, возможно придётся после F5 в H>браузере предварительно потыкать в кучу кнопок чтобы попасть в то место, H>которое нам интересно.
А при чем здесь развесистый фремвор, watch и винда ? Хот-релоад на клиенте не даёт особого профита — все равно каждый кейс надо прокликать _руками_. Это особенность любой клиентской разработки. На клиенте конская зависимость от нативного кода. Ну сделал ты фикс, что браузер вдруг DOM перестроит в соответствии с твоим фиксом ? Css перепарсится ? Картинки перерисуются ? Нет, это все надо перекликать руками.
Вообще даже на сервере хот-релоад дает далеко не в 100% кейсах. Когда ты нашел баг, состояние в большинстве случаев уже невалидное. Например была аутентификация с некорректным токеном, который взял и записался в базу, кеш и тд и тд. Как тут хот-релоад поможет ?
16.01.2017 22:12, Ikemefula пишет: > А при чем здесь развесистый фремвор, watch и винда ?
Притом, что между исправлением кода и нажатием F5 в браузере появился
новый этап, иногда достаточно длительный — билд "клиентского приложения"
(gulp build/gulp watch). Ещё очень недавно этого не было.
> Вообще даже на сервере хот-релоад дает далеко не в 100% кейсах. Когда ты > нашел баг, состояние в большинстве случаев уже невалидное. Например была > аутентификация с некорректным токеном, который взял и записался в базу, > кеш и тд и тд. Как тут хот-релоад поможет ?
Хот релоад исправляет код без необходимости перезагрузки приложения, для
того чтобы убедиться что мы всё правильно исправили — конечно же запрос
(или серию запросов) придётся повторить. В простых случаях это делается
прямо через браузер, если повторять надо значительно более одного раза —
мы применяем пакетный файл с последовательными вызовами curl или
запускаем скрипт jmeter. Есть наверняка и другие способы автоматизации.
Здравствуйте, hrensgory, Вы писали:
>> А при чем здесь развесистый фремвор, watch и винда ?
H>Притом, что между исправлением кода и нажатием F5 в браузере появился H>новый этап, иногда достаточно длительный — билд "клиентского приложения" H>(gulp build/gulp watch). Ещё очень недавно этого не было.
Разумеется. И причины не во фремворках, а в усложнении требований к UI. Фремворки — следствие этого усложнения.
H>Хот релоад исправляет код без необходимости перезагрузки приложения, для H>того чтобы убедиться что мы всё правильно исправили — конечно же запрос H>(или серию запросов) придётся повторить. В простых случаях это делается H>прямо через браузер, если повторять надо значительно более одного раза — H>мы применяем пакетный файл с последовательными вызовами curl или H>запускаем скрипт jmeter. Есть наверняка и другие способы автоматизации.
Если непонятно, еще раз — фронтенд хранит состояние в нативной части. Каким образом без перезагрузки приложения обновить это состояние ?
На сервере у тебя состояния по большому счету нет вообще. В браузере ровно наоборот — DOM/BOM и есть твоё состояние.
Каким чудом ты собираешься хот релоадом решать проблему нативных модулей ?
Собственно в браузере есть возможность патчить JS прямо на лету. Жмешь в хроме F12, выбираешь JS файл, патчишь его, сохраняешь, радуешься результату. Это твой любимый хот-релоад. Проблема в том, что в более менее серьезном приложении это не даёт эффекта, нисколько, никакого. На страничках где функционала около нуля, такой патч помогает,но ровно до тех пор, пока ты не завязан на состояние.
Как только изменения затрагивают состояние, упс, надо перегружать приложение. И такое было уже на чистом, ванильном жээсе когда еще ангуляра и реакта даже в планах не было.
17.01.2017 10:54, Ikemefula пишет:
> H>Притом, что между исправлением кода и нажатием F5 в браузере появился > H>новый этап, иногда достаточно длительный — билд "клиентского приложения" > H>(gulp build/gulp watch). Ещё очень недавно этого не было. > > Разумеется. И причины не во фремворках, а в усложнении требований к UI. > Фремворки — следствие этого усложнения.
По-моему такой зоопарк фронтенд фреймворков, который образовался сейчас
(о чем была статья на хабре "Каково оно учить JavaScript в 2016", с
которой и началось обсуждение) и частота смены "лидеров" в этой гонке
обуславливается скорее воплощением описанного ещё давно Дж. Спольски
принципа "огонь и движение" чем "усложнением требований к UI". Вот
оттуда цитатка подходящая:
"Подумайте об истории всевозможных стратегий доступа к данным,
разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET
— И все абсолютно новые! Может это было вызвано технологической
необходимостью? Может это результат некомпетентной группы
проектирования, которой необходимо придумывать по-новой доступ к данным
каждый чертов год? (Возможно, это в самом деле так.) Но конечный
результат — всего лишь огонь для прикрытия. Конкуренты не имеют никакого
другого выбора, кроме как тратить своё время, переписывая код под новые
библиотеки и поспевая за лидером — время, которое они не могут
использовать для создания новых возможностей."
> Если непонятно, еще раз — фронтенд хранит состояние в нативной части.
Я "фронтендом" в т.ч. занимаюсь со времен Netscape Navigator 2.0 и
мне-то это всё понятно ) Просто жалко кучи времени, которое тратится
программистами на разработку фронта в сравнении с разработкой бэка.
Здравствуйте, hrensgory, Вы писали:
>> Разумеется. И причины не во фремворках, а в усложнении требований к UI. >> Фремворки — следствие этого усложнения. H>По-моему такой зоопарк фронтенд фреймворков, который образовался сейчас H>(о чем была статья на хабре "Каково оно учить JavaScript в 2016", с H>которой и началось обсуждение) и частота смены "лидеров" в этой гонке H>обуславливается скорее воплощением описанного ещё давно Дж. Спольски H>принципа "огонь и движение" чем "усложнением требований к UI". Вот H>оттуда цитатка подходящая:
Ага, эдакий заговор. Все решили усложнять ради усложнения а юзеры радостно ведутся.
H>каждый чертов год? (Возможно, это в самом деле так.) Но конечный H>результат — всего лишь огонь для прикрытия. Конкуренты не имеют никакого H>другого выбора, кроме как тратить своё время, переписывая код под новые H>библиотеки и поспевая за лидером — время, которое они не могут H>использовать для создания новых возможностей."
Так и есть — заговор. Юзеру профита якобы нет, но он яростно отказыватся от работающих приложений и покупает лютое говно на новых технологиях
H>Я "фронтендом" в т.ч. занимаюсь со времен Netscape Navigator 2.0 и H>мне-то это всё понятно ) Просто жалко кучи времени, которое тратится H>программистами на разработку фронта в сравнении с разработкой бэка.
Оно и видно, что постишь конспироложество в исполнении Джоэля Спольски.
Здравствуйте, vsb, Вы писали:
vsb>Я немного покопался в современном JS. У меня примерно такие претензии (я с острова Java). vsb>1. Сложность сборки. Grunt. Очень низкоуровнево, проще шелл-скрипт написать. Одна радость — относительно кроссплатформенно. Gulp — хрен редьки не слаще. Только якобы более производительно. Где там производительность, я не знаю, оно собирает несложный JS-проект больше 30 секунд. vsb>3. Очень долгий цикл написал-собрал-проверил. В Java гораздо быстрее. С Hot Reload-ом всё очень плохо. Последний проект, в котором я участвовал, выглядел так: изменил 1 букву, 30 секунд пересобираешь проект
Попробуй webpack. В режиме watch он первый раз долго собирает-собирает, но последующие сборки при изменениях кода происходят очень быстро.
17.01.2017 16:04, Ikemefula пишет: > H>По-моему такой зоопарк фронтенд фреймворков, который образовался сейчас > H>(о чем была статья на хабре "Каково оно учить JavaScript в 2016", с > H>которой и началось обсуждение) и частота смены "лидеров" в этой гонке > H>обуславливается скорее воплощением описанного ещё давно Дж. Спольски > H>принципа "огонь и движение" чем "усложнением требований к UI". Вот > H>оттуда цитатка подходящая: > > Ага, эдакий заговор. Все решили усложнять ради усложнения а юзеры > радостно ведутся.
... > Так и есть — заговор. Юзеру профита якобы нет, но он яростно отказыватся > от работающих приложений и покупает лютое говно на новых технологиях
Юзера никто не спрашивает. Мне как "юзеру" непонятно — зачем сделали
несовместимый с первым Angular2 (а сейчас уже лепят Angular4), если
единственным серьезным недостатком первого был повсеместный two-way
binding, от которого стало возможно избавляться уже с версии, ЕМНИП,
1.3? Понятно же что сейчас куча библиотек, написанная под первый,
останется без поддержки и по мере выхода всё новых и новых версий
браузеров будет глючить всё больше и больше, что приведет к тому, что
приложения перестанут быть "работающими" и будут заменены по вашему
меткому замечанию "лютым говном на новых технологиях".
Ещё, кстати, совершенно непонятно почему бы не обеспечить, хотя бы в
Хроме и ИЕ (остальные быстро бы подтянулись) нативную поддержку
какого-нибудь более нормального чем JavaScript языка (TypeScript вполне
бы подошёл)?
> P.S. "ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET" — все эти > баззворды решают конкретные проблемы. Вот хороший ликбез:
99% процентов ПО не использует всерьёз никаких других датасорсов кроме
тех, к которым можно написать JDBC(ODBC) драйвер.
Здравствуйте, hrensgory, Вы писали:
>> Так и есть — заговор. Юзеру профита якобы нет, но он яростно отказыватся >> от работающих приложений и покупает лютое говно на новых технологиях
H>Юзера никто не спрашивает. Мне как "юзеру" непонятно — зачем сделали H>несовместимый с первым Angular2 (а сейчас уже лепят Angular4),
Ты реально считаешь, что юзер в курсе, на чем написан его любимый фейсбук ?
H>единственным серьезным недостатком первого был повсеместный two-way H>binding, от которого стало возможно избавляться уже с версии, ЕМНИП, H>1.3?
Вообще то первый ангуляр был крив буквально во всем. Слишком много текста и телодвижений для любой вещи.
Разработчики этого первого ангуляра так и не смогли внятно объяснить девелоперам все концепции.
Первый ангуляр это ООП поверх ООП на джаваскрипте. Изобретение модулей, классов, зависимостей и тд и тд.
Практически все разрабы, которые сталкиваются с Angular2, испытывают облегчение после первого. Люди без опыта фронтенда, джависты, дотнетчики, воспринимают Ангуляр2 как обычные ООП.
Кроме того, Ангуляр2 тупо быстрее, по скромной оценке — на порядок. Там где в первом надо оптимизировать дайджесты, во втором хватит тупого решения "в лоб", и работает быстрее чем первый со всеми оптимизациями.
H>останется без поддержки и по мере выхода всё новых и новых версий H>браузеров будет глючить всё больше и больше, что приведет к тому, что H>приложения перестанут быть "работающими" и будут заменены по вашему H>меткому замечанию "лютым говном на новых технологиях".
Ужос, если у юзера будет глючить фейсбук, он наверняка пойдет туда, где ничего не глючит. Правильно ?
Или ты думаешь фейсбук юзерам взятку даёт, шоб те к конкурентам не ходили ?
H>Ещё, кстати, совершенно непонятно почему бы не обеспечить, хотя бы в H>Хроме и ИЕ (остальные быстро бы подтянулись) нативную поддержку H>какого-нибудь более нормального чем JavaScript языка (TypeScript вполне H>бы подошёл)?
Уже давно идет к этому, только опенсорс он слишком медленный. Перед этим была компиляция. Сейчас проходим этап транспайлеров. Потиху вводится поддержка webassembly и тд и тд и тд.
H>99% процентов ПО не использует всерьёз никаких других датасорсов кроме H>тех, к которым можно написать JDBC(ODBC) драйвер.
Во первых, ты проспал документы. Эти вещи не имеют sql-интерфейса а изобрели их еще в семидесятых.
Во вторых, кроме odbc есть еще и технология OLE(OLE2, COM, ActiveX), и здесь собственно получаем внятный интерфейс поверх ODBC безо всякого паскудства.
Собственно, на чистом odbc никто всерьез ничего не писал, как ты говоришь "в 99% случаяв"
Здравствуйте, Ikemefula, Вы писали:
I>Кроме того, Ангуляр2 тупо быстрее, по скромной оценке — на порядок. Там где в первом надо оптимизировать дайджесты, во втором хватит тупого решения "в лоб", и работает быстрее чем первый со всеми оптимизациями.
А что лучше использовать angular2 или react? А то когда мне довелось писать простенький web ui для своего сервиса, я выбрал angular + kendoui. Это было года 2 назад. Что сейчас считается хорошим фреймворком? Чтобы mvc и вот это вот все.
Здравствуйте, Sharov, Вы писали:
S>А что лучше использовать angular2 или react? А то когда мне довелось писать простенький web ui для своего сервиса, я выбрал angular + kendoui. Это было года 2 назад. Что сейчас считается хорошим фреймворком? Чтобы mvc и вот это вот все.
Для старта лучше использовать более знакомый тебе инструмент. Если тащишься от функциональщины и прочих вещей, бери реакт с прибамбасами.
Если ты понимаешь и умеешь классическое ООП, статическую типизацию и тд, то тебе стоит взять Ангуляр2. Люди без опыта во фронтенде с ООП-бекграундом легко поднимают Ангуляр2. Вот первый ангуляр или реакт уже так легко не даются, судя по наблюдениям.
Здравствуйте, selkwind, Вы писали:
I>>Ага, эдакий заговор. Все решили усложнять ради усложнения а юзеры радостно ведутся.
S>Никакой не заговор, а просто графомания, типичная для лиц с шизоидными наклонностями, коих среди ИТшников валом.
В обсуждаемом примере баззворды появлялись как раз для решения новых проблем.
17.01.2017 18:36, Ikemefula пишет:
> H>Юзера никто не спрашивает. Мне как "юзеру" непонятно — зачем сделали > H>несовместимый с первым Angular2 (а сейчас уже лепят Angular4), > > Ты реально считаешь, что юзер в курсе, на чем написан его любимый фейсбук ?
Под "юзером" здесь имелся в виду "юзер" фреймворка, т.е.
фронтенд-разработчик.
> Вообще то первый ангуляр был крив буквально во всем. Слишком много > текста и телодвижений для любой вещи. > Разработчики этого первого ангуляра так и не смогли внятно объяснить > девелоперам все концепции. > Первый ангуляр это ООП поверх ООП на джаваскрипте. Изобретение модулей, > классов, зависимостей и тд и тд.
Ну не знаю, как-то слишком это уж пессимистично звучит, наблюдениями не
подтверждается. Наши фронтендщики его достаточно быстро освоили и
клепают на нем всякий энтерпрайз уверенно. Хотя писанины могло бы быть и
поменьше, это да.
Теперь вот второй осваиваем. Только сомневаемся — может надо четвёртый
сразу ) ?
> H>Ещё, кстати, совершенно непонятно почему бы не обеспечить, хотя бы в > H>Хроме и ИЕ (остальные быстро бы подтянулись) нативную поддержку > H>какого-нибудь более нормального чем JavaScript языка (TypeScript вполне > H>бы подошёл)? > > Уже давно идет к этому, только опенсорс он слишком медленный. Перед этим > была компиляция. Сейчас проходим этап транспайлеров. Потиху вводится > поддержка webassembly и тд и тд и тд.
Да вот куда-то оно не туда идёт по-моему. Применение транспайлеров
приводит к тому, что в браузере исполняется javascript, связь которого с
исходниками неочевидна. То есть по сути это такой GWT light edition —
пишем на одном языке, в браузере другой.
А что до webassembly — так по-моему более идиотской идеи ещё поискать.
Давайте выкосим из браузеров отработанные десятилетиями VM явы, флэша и
сильверлайта, а взамен напишем свою! А остальные пусть под неё пишут
биндинги своих языков. Прекрасная идея, что тут скажешь.
> H>99% процентов ПО не использует всерьёз никаких других датасорсов кроме > H>тех, к которым можно написать JDBC(ODBC) драйвер. > > Собственно, на чистом odbc никто всерьез ничего не писал, как ты > говоришь "в 99% случаяв"
Возможно, хотя это звучит странно. Я практически незнаком с миром винды,
а в той же яве все "надстройки" вроде JPA и подобных фреймворков
работают в конечном счёте именно через JDBC драйвера. И "чистый JDBC"
используется в больших приложениях нередко (хелловорды не рассматриваем
— там конечно и JPA за глаза хватит).
Ну да, взрослеет. И при этом продолжает в случае чего срать направо и налево в лог нечто типа "undefined is not a function" или там еще какой "MISMATCHED ANONYMOUS DEFINE() MODULES" безо всякой возможности пройтись дебаггером по обфусцированному коду с кучей promises & callbacks.
Здравствуйте, hrensgory, Вы писали:
>> Ты реально считаешь, что юзер в курсе, на чем написан его любимый фейсбук ?
H>Под "юзером" здесь имелся в виду "юзер" фреймворка, т.е. H>фронтенд-разработчик.
>> Первый ангуляр это ООП поверх ООП на джаваскрипте. Изобретение модулей, >> классов, зависимостей и тд и тд.
H>Ну не знаю, как-то слишком это уж пессимистично звучит, наблюдениями не H>подтверждается. Наши фронтендщики его достаточно быстро освоили и H>клепают на нем всякий энтерпрайз уверенно. Хотя писанины могло бы быть и H>поменьше, это да.
Фронтенды — быстро. А вот люди без опыта фронтенда осваивают с большим трудом.
С старом фронтенде изобретение ООП, модулей, классов, импорта-экспорта депенденсов встречалось повсеместно.
Но это в основном графомания и пережитки старого JS — поддержка языковых фич на уровне библиотеки.
package App
import dependency1
import dependency2
import dependency3
class Service {
public Service(dependency1 d1,dependency2 d2,dependency3 d3) {
...
}
}
Ничего не напоминает ? До кучи в Ангуляре1 смешали зависимости дизайн-тайм с зависимостями ран-тайм. Пока в голове разраба не сложится этот пазл, в ангуляре1 от него толку не будет.
ES6 и ТайпСкрипт прекращают эти глупости. Получается почти как в Jave, с той разницей, что язык чуть-чуть другой, ибо рантайм JS таки отличается от JVM.
H>Теперь вот второй осваиваем. Только сомневаемся — может надо четвёртый H>сразу ) ?
Не надо сомневаться — сейчас просто Ангуляр. Будут иногда ломающие изменения, но это лучше, чем один большой прыжок с 1 на 2.
>> Уже давно идет к этому, только опенсорс он слишком медленный. Перед этим >> была компиляция. Сейчас проходим этап транспайлеров. Потиху вводится >> поддержка webassembly и тд и тд и тд.
H>Да вот куда-то оно не туда идёт по-моему. Применение транспайлеров H>приводит к тому, что в браузере исполняется javascript, связь которого с H>исходниками неочевидна. То есть по сути это такой GWT light edition — H>пишем на одном языке, в браузере другой.
Причина в разнице рантайма JS и JVM. Так вот сложилось, что Java сама по себе тащит в языке зависимостей больше, чем поддерживается рантаймом JS.
Кроме того, обилие обычного JS позволяет легко проткнуть сразу все абстракции разом.
В браузере будет внятно работать только тот язык, который хорошо ложится на рантайм JS. Это, как ни странно, JS и С++ Со вторым, правда, проблем не избежать — сейчас, похоже, его уверенно знают только реликты из 80-90х.
H>А что до webassembly — так по-моему более идиотской идеи ещё поискать. H>Давайте выкосим из браузеров отработанные десятилетиями VM явы, флэша и H>сильверлайта, а взамен напишем свою! А остальные пусть под неё пишут H>биндинги своих языков. Прекрасная идея, что тут скажешь.
Идея правильная, но запоздалая. Изначально было такое понимание, что браузер идеален (IE6) и его только плагинами нужно обложить.
Собтсвенно не ясно, зачем пилить UI на джаве, если браузер сам обладает наилучшими возможностями в этом вопросе.
vm, флеш, сервелат зашли в тупик. Сервелат, Джава, Флеш это песочницы, не позволяют внятную интеграцию с другими частями сайта, имеют проблемы с перформансом, функциональностью, инсталяцией и тд и тд. Зачем юзеру пять дополнительных рантаймов для браузера, которые создают проблемы, если омжно обойтись родным браузером ?
Насколько я понимаю, нынешний тренд в браузерах — превращение движка в полноценную платформу, фактически как OS.
Здравствуйте, selkwind, Вы писали:
I>>Фронтенд стремительно взрослеет.
S>Ну да, взрослеет. И при этом продолжает в случае чего срать направо и налево в лог нечто типа "undefined is not a function" или там еще какой "MISMATCHED ANONYMOUS DEFINE() MODULES" безо всякой возможности пройтись дебаггером по обфусцированному коду с кучей promises & callbacks.
Это пример реликтового подхода к модулям на фронтенде.
Здравствуйте, Ikemefula, Вы писали:
I>В браузере будет внятно работать только тот язык, который хорошо ложится на рантайм JS. Это, как ни странно, JS и С++
Шо?! Почему на "рантайм js" не ложится java, но ложится c++?
опа опа мы воюем с нато
любит хавать этот кал
путинская вата
