Ну, согласитесь, что это лишь один фактор из многих. Причем непонятно какой по важности — зависит от жизненного цикла вашего проекта. И чрезвычайно сложно оцениваемый.
Ну вот вам реальный пример — был у меня проект, лет пять назад. UI — где-то на уровне вашего по сложности. Огромные формы, сложные зависимости, нетривиальные компоненты. В качестве одного из инструментов предлагался Flex. Аргументы против были именно в этом духе — технология мол не будет поддерживаться. Пять лет прошло. Тот проект давно в могиле — в том числе потому, что на выбранной другой технологии его просто не получилось сделать. Flex никуда не делся. А сколько javascript фреймворков за эти пять лет померли и были забыты?
>Я увидел что реакт — в продакшене на куче крутых сайтов. FB
Вы не представляете, как это местами смешно выглядит. Не, правда.
Я не про ваш выбор вовсе — я про аргументы типа, что «это в продакшн у FB». Я с трудом могу вспомнить более глючное, плохо продуманное, менее предсказуемое приложение, чем FB. И да, я не про компоненты вовсе, а просто о том, что FB в качестве примера для других — это мягко говоря не довод.
Кроме всего прочего, у вас действительно достаточно сложный UI, какого у FB не встретишь. И другие технологии в основе.
А вам с какой целью нужна эта классификация? Что вас в моих формулировках смущает?
Я вполне явные примеры приводил — вот если вы пишете интернет банк, как вы собрались делать его чисто серверным? Без логики и кода на клиенте, без ЭЦП на клиенте, без доступа к файлам клиента?
Когда в качестве примера того, к чему нужно стремиться, приводится почта, мне становится смешно. Это текст 2001 года? Так прошло уже лет 15, а покажите мне сегодня, хотя бы две нормальные реализации веб почты, где есть нормальное вменяемое шифрование end-to-end?
>Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус
Да-да. Слыхали. Опять же, сегодня в 2016 году это выглядит смешно. На сегодня браузер является как раз одной из основных дыр в системе безопасности любой ОС. Потому что практика показала, что чисто серверные приложения, без логики на клиенте, без javascript, java или flash, почти никому не нужны. А когда все это появляется — браузер становится плохо защищенным.
А может это вы читали невнимательно? У меня как раз создается (субъективное, разумеется, но вполне устойчивое впечатление), что он сплошь и рядом делает ненужные обобщения. А пытаясь критиковать альтернативные решения, допускает явные ляпы. Вот, обратите внимание:
>С приложением на сервере вы можете делать доработки почти так же, как в программе, которую вы пишете для себя. Вы >выпускаете версии как последовательность поэтапных изменений вместо внезапного большого взрыва. Обычно компания, >производящая десктопное ПО, может выпустить одну или две версии за год. Для Viaweb мы часто делали три-пять версий в день.
Что, простите? При чем тут сервер vs desktop? Во-первых, на сегодня это давно устарело, потому что многие вполне настольные приложения легко обновляются с любой частотой. А во-вторых, возможность выпуска версий часто и понемногу — вовсе не особенность серверных приложений. Это особенность бизнеса компании. Опять же — если вы гугль или yahoo, и выпускаете десять версий своего поисковика или карт в день — это никого не волнует, в первую очередь потому, что вы никому ничего не обязаны. Вы как раз и пишете «как для себя». Только это не ваше достижение ни разу, и хвастаться тут нечем.
Ничего крамольного про апплеты? Да он написал так, как будто серверные и клиент-серверные приложения взаимозаменяемы, и мы можем выбрать что захотим. Что совсем не так. Это и есть еще одно ненужное и неправильное обобщение.
История с практической стороны показала, что даже сейчас, в 2016, те вещи, которые я перечислил, вызывают большие проблемы при разработке в стандартной web-парадигме. А тогда реальных альтернатив не было вообще (если не считать flash).
>Грэм продвигает Server-based computing в противопоставление standalone приложениям
И при этом несет чушь о технологиях, которые знает плохо. Это его не извиняет ни разу. «Проще дойти до логического конца и запускать программы на сервере» — проще по сравнению с чем? Понимаете, если вы скажем гугль, и пишете поисковик — то вам и javascript-то не особо нужен. У вас серверное приложение by design.
А если вы банк, и вам скажем нужна на клиенте ЭЦП, то у вас и сегодня, 20 лет спустя, будет очень немного реальных альтернатив тем же апплетам.
Апплеты никогда не были легковесными сами по себе. Единственное, чем они отличаются от обычного приложения — это запуск в браузерной песочнице. С ограничениями в правах. И с загрузкой jar как правило с сервера — т.е. технология доставки клиенту обновлений кода такая же, как для клиентских javascript приложений.
Да, именно server-based или клиент-серверных (причем это не одно и тоже), а не серверных — и это тоже две большие разницы. Они работают только на клиенте. И совершенно не обязаны с сервером общаться.
standalone? Почему бы и нет? Не предназначены — но могут в таком виде вполне использоваться.
Вспомните, что речь примерно про 1995, и скажите себе честно — а что, где-то еще была нормальная интерактивная 2D графика? canvas не было, WebGL и SVG насколько я помню — тоже. И File API еще не появился. И web socket не было тоже. И webworker тоже не было — javascript программы только недавно стали многопоточными.
Поэтому апплеты были (да и сейчас еще в значительной степени остаются) единственным средством разработки во многих случаях: когда нужна графика, когда нужен доступ к файлам клиента, когда нужен доступ к clipboard, когда нужно например шифрование — потому что шифрование на javascript это нонсенс, особенно 20 лет назад. Почему клиент-банки во множестве на апплетах? Потому что шифрование и электронная подпись.
А теперь перечитайте фразу Грэма про апплеты, и вдумайтесь, чем он хвастает? Тем что клиент-серверных приложений у них не было, а были только серверные. Вот вы серьезно думаете, что это достижение? По-моему, это просто глупость.
>Java-апплеты рассматривались как технология, которую все будут использовать для разработки серверных приложений.
Апплеты всегда были, и рассматривались как технология разработки клиентских приложений. И только их. И кстати, в оригинале server-based, и это не тоже самое.
В том, что вы не можете писать нормальные функции. В том, что нет нормальной обработки ошибок. В том, что нет нормальных структур данных.
И это все совсем не к синтаксису претензии. Хотя он тоже тот еще… недавно у нас в проекте забыли кавычку где-то на 20 строке. Упало на строке 89, перед этим выполнив предыдущие 88. Шикарный синтаксис, который не защищает от пропуска закрывающей кавычки, не правда ли?
Чисто практический опыт показывает, что переписывание (там где это можно) с bash на нормальный язык, сокращает объем примерно в три раза, сохраняя или увеличивая читаемость кода. Да хоть на python или perl. Я пробовал на groovy. На что угодно — только не bash и это семейство (ksh в общем туда же, плюс-минус).
Прекрасно понимаю, что избавиться от всего добра, которое на нем написано, вряд ли возможно, тем не менее совершенно непонятно, ради чего его защищать? По сегодняшним меркам он архаичный весь, от и до.
Минуя печать? А что, по вашему книги в электронном виде пишутся быстрее? По-моему они уже все лет 20 как пишутся в текстовом процессоре. Безо всяких исключений. И время очевидно уходит именно на написание, а уж точно не на печать. Я думаю на нормальную книгу нужно хотя бы полгода.
Безалаберность? Да просто нормальные авторы понимают, что такого рода книги никому не нужны (я не говорю обо всех их видах). Их устаревание до момента выхода в свет всем очевидно. Реально живут только книги по продукту, которые пишутся и развиваются в виде wiki сразу, и обновляются постоянно. А печатную форму приобретают просто путем применения другого форматирования.
Узкопрофильные книги имеют свойство устаревать мгновенно. Обычно еще до выхода в свет. А типичный случай — когда в момент выхода книга описывает версию продукта, которой года три. По тем продуктам, на которых я лично сегодня работаю, одна книга вышла в 2010, а второе ее издание начато в 2015 — и не написано. Так вы какими книгами предлагаете пользоваться — не напечатанными (т.е. в сущности, все равно интернетом), или устаревшими лет на 5?
>И это работает! А 95% людей, услышав слово webservice, полезли бы в JEE.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
>к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.
>Ваши аргументы сводятся к вашему личному опыту сравнения с решениями, написанными по-ходу неквалифицированными программистами. И Вы делаете вывод, что виновато отсутствие JEE. Отчасти, конечно, Вы правы.
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
Слушайте, ну не надо утрировать. Я вам могу еще раз повторить — у меня было с десяток вполне успешных проектов сравнительно разного размера, и нигде, повторяю — нигде выбор JavaEE не был основан на том, что дядя купил Weblogic. Его выбрали разработчики. А поскольку проекты были успешные — то выбор был правилен.
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.
Ну, с ant проще перевести на что угодно. Реальные проблемы в сборке обычно начинаются тогда, когда у нас в проекте кучка зависимостей, как внешних, так и внутренних, которые обновляются время от времени, и надо следить за их версиями, их совместимостью и т.п.
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).
Стандартный ответ — вы обобщаете свой ограниченный опыт на всех, и делаете ошибку. Нет, не JTA вовсе. А скорее управляемость кода в целом, как при разработке, так и в эксплуатации. В самом широком смысле.
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
Гм. Вот знаете, у нас в соседнем проекте оказывается собирали все maven второй версии. Я уже забыл, когда у меня он был, лет семь наверное прошло с тех пор. При этом оно а) работает б) с тем же репозиторием в) разницы в pom.xml нет никакой. Инструменту 10 лет, он используется, и все довольны.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.
Ктож вас-то заставляет монолитное писать? Кстати, если в проекте нет контейнера — то с модульностью там обычно все еще хуже, чем когда он есть. А все без исключения виденные мной лично попытки заменить Java EE своим велосипедом как правило были намного хуже — впрочем, я это и сегодня живьем наблюдаю. Какой только фигни там не встретишь.
Ну вот вам реальный пример — был у меня проект, лет пять назад. UI — где-то на уровне вашего по сложности. Огромные формы, сложные зависимости, нетривиальные компоненты. В качестве одного из инструментов предлагался Flex. Аргументы против были именно в этом духе — технология мол не будет поддерживаться. Пять лет прошло. Тот проект давно в могиле — в том числе потому, что на выбранной другой технологии его просто не получилось сделать. Flex никуда не делся. А сколько javascript фреймворков за эти пять лет померли и были забыты?
Вы не представляете, как это местами смешно выглядит. Не, правда.
Я не про ваш выбор вовсе — я про аргументы типа, что «это в продакшн у FB». Я с трудом могу вспомнить более глючное, плохо продуманное, менее предсказуемое приложение, чем FB. И да, я не про компоненты вовсе, а просто о том, что FB в качестве примера для других — это мягко говоря не довод.
Кроме всего прочего, у вас действительно достаточно сложный UI, какого у FB не встретишь. И другие технологии в основе.
Я вполне явные примеры приводил — вот если вы пишете интернет банк, как вы собрались делать его чисто серверным? Без логики и кода на клиенте, без ЭЦП на клиенте, без доступа к файлам клиента?
Когда в качестве примера того, к чему нужно стремиться, приводится почта, мне становится смешно. Это текст 2001 года? Так прошло уже лет 15, а покажите мне сегодня, хотя бы две нормальные реализации веб почты, где есть нормальное вменяемое шифрование end-to-end?
>Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус
Да-да. Слыхали. Опять же, сегодня в 2016 году это выглядит смешно. На сегодня браузер является как раз одной из основных дыр в системе безопасности любой ОС. Потому что практика показала, что чисто серверные приложения, без логики на клиенте, без javascript, java или flash, почти никому не нужны. А когда все это появляется — браузер становится плохо защищенным.
>С приложением на сервере вы можете делать доработки почти так же, как в программе, которую вы пишете для себя. Вы >выпускаете версии как последовательность поэтапных изменений вместо внезапного большого взрыва. Обычно компания, >производящая десктопное ПО, может выпустить одну или две версии за год. Для Viaweb мы часто делали три-пять версий в день.
Что, простите? При чем тут сервер vs desktop? Во-первых, на сегодня это давно устарело, потому что многие вполне настольные приложения легко обновляются с любой частотой. А во-вторых, возможность выпуска версий часто и понемногу — вовсе не особенность серверных приложений. Это особенность бизнеса компании. Опять же — если вы гугль или yahoo, и выпускаете десять версий своего поисковика или карт в день — это никого не волнует, в первую очередь потому, что вы никому ничего не обязаны. Вы как раз и пишете «как для себя». Только это не ваше достижение ни разу, и хвастаться тут нечем.
Ничего крамольного про апплеты? Да он написал так, как будто серверные и клиент-серверные приложения взаимозаменяемы, и мы можем выбрать что захотим. Что совсем не так. Это и есть еще одно ненужное и неправильное обобщение.
>Грэм продвигает Server-based computing в противопоставление standalone приложениям
И при этом несет чушь о технологиях, которые знает плохо. Это его не извиняет ни разу. «Проще дойти до логического конца и запускать программы на сервере» — проще по сравнению с чем? Понимаете, если вы скажем гугль, и пишете поисковик — то вам и javascript-то не особо нужен. У вас серверное приложение by design.
А если вы банк, и вам скажем нужна на клиенте ЭЦП, то у вас и сегодня, 20 лет спустя, будет очень немного реальных альтернатив тем же апплетам.
Да, именно server-based или клиент-серверных (причем это не одно и тоже), а не серверных — и это тоже две большие разницы. Они работают только на клиенте. И совершенно не обязаны с сервером общаться.
standalone? Почему бы и нет? Не предназначены — но могут в таком виде вполне использоваться.
Вспомните, что речь примерно про 1995, и скажите себе честно — а что, где-то еще была нормальная интерактивная 2D графика? canvas не было, WebGL и SVG насколько я помню — тоже. И File API еще не появился. И web socket не было тоже. И webworker тоже не было — javascript программы только недавно стали многопоточными.
Поэтому апплеты были (да и сейчас еще в значительной степени остаются) единственным средством разработки во многих случаях: когда нужна графика, когда нужен доступ к файлам клиента, когда нужен доступ к clipboard, когда нужно например шифрование — потому что шифрование на javascript это нонсенс, особенно 20 лет назад. Почему клиент-банки во множестве на апплетах? Потому что шифрование и электронная подпись.
А теперь перечитайте фразу Грэма про апплеты, и вдумайтесь, чем он хвастает? Тем что клиент-серверных приложений у них не было, а были только серверные. Вот вы серьезно думаете, что это достижение? По-моему, это просто глупость.
Апплеты всегда были, и рассматривались как технология разработки клиентских приложений. И только их. И кстати, в оригинале server-based, и это не тоже самое.
И это все совсем не к синтаксису претензии. Хотя он тоже тот еще… недавно у нас в проекте забыли кавычку где-то на 20 строке. Упало на строке 89, перед этим выполнив предыдущие 88. Шикарный синтаксис, который не защищает от пропуска закрывающей кавычки, не правда ли?
Чисто практический опыт показывает, что переписывание (там где это можно) с bash на нормальный язык, сокращает объем примерно в три раза, сохраняя или увеличивая читаемость кода. Да хоть на python или perl. Я пробовал на groovy. На что угодно — только не bash и это семейство (ksh в общем туда же, плюс-минус).
Прекрасно понимаю, что избавиться от всего добра, которое на нем написано, вряд ли возможно, тем не менее совершенно непонятно, ради чего его защищать? По сегодняшним меркам он архаичный весь, от и до.
Безалаберность? Да просто нормальные авторы понимают, что такого рода книги никому не нужны (я не говорю обо всех их видах). Их устаревание до момента выхода в свет всем очевидно. Реально живут только книги по продукту, которые пишутся и развиваются в виде wiki сразу, и обновляются постоянно. А печатную форму приобретают просто путем применения другого форматирования.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.
Java 7, извините. С весны прошлого года.
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.