Pull to refresh

Comments 12

Не очень понял смысл предложения, а точнее, его второй части: Для того, чтобы пользоваться персональным компьютером, вы вынуждены изучить намного больше, чем вообще хотите знать что происходит внутри него.

Можно увидеть эту фразу в оригинале?
Вряд ли оригинал фразы добавит что-то, что могло бы прояснить смысл. На самом деле, всё и так понятно. Нормальному пользователю совершенно не хочется знать, например, о том, что в компьютере есть оперативная память, а есть диск. Или о том, что любая информация на диске сохраняется в каких-то файлах. Гораздо естественней просто создавать в компьютере документы, не придумывая при этом никаких дополнительных названий для файлов, и не размышляя о том, в какой директории их сохранить. Ему хочется просто вводить текст в компьютер, а потом распечатать или отправить по почте. Или если пользователь нашёл/купил в сети музыку, то ему не хочется думать о том, что её нужно сначала скачать, затем найти место, куда она скачалась, после чего перелить на плеер. Ему хочется просто нажать кнопку «отправить на плеер» прямо там, где он нашёл музыку.
Конечно, можно :)
When you own a desktop computer, you end up learning a lot more than you wanted to know about what's happening inside it.

The Other Road Ahead
>Java-апплеты рассматривались как технология, которую все будут использовать для разработки серверных приложений.
Апплеты всегда были, и рассматривались как технология разработки клиентских приложений. И только их. И кстати, в оригинале server-based, и это не тоже самое.
Расшифруйте, пожалуйста.
Потому что я помню как они появились, и как тогда на русский их переводили как «приложеньица», потому что были очень легковесными — читай использовались как лёгкий фронтенд для технологии «клиент-сервер».
Смысл в том, что они должны были применяться только как интерфейс к серверным приложениям (в отрыве от них не имеют смысла — не считая всяких анимированных часиков и прочих поделок).
Так что апплеты — технология для [клиент-]серверных приложений.
Это совсем не означает, что они работают именно на сервере, а означает, что они не предназначены для разработки standalone приложений.
Апплеты никогда не были легковесными сами по себе. Единственное, чем они отличаются от обычного приложения — это запуск в браузерной песочнице. С ограничениями в правах. И с загрузкой jar как правило с сервера — т.е. технология доставки клиенту обновлений кода такая же, как для клиентских javascript приложений.

Да, именно server-based или клиент-серверных (причем это не одно и тоже), а не серверных — и это тоже две большие разницы. Они работают только на клиенте. И совершенно не обязаны с сервером общаться.

standalone? Почему бы и нет? Не предназначены — но могут в таком виде вполне использоваться.

Вспомните, что речь примерно про 1995, и скажите себе честно — а что, где-то еще была нормальная интерактивная 2D графика? canvas не было, WebGL и SVG насколько я помню — тоже. И File API еще не появился. И web socket не было тоже. И webworker тоже не было — javascript программы только недавно стали многопоточными.

Поэтому апплеты были (да и сейчас еще в значительной степени остаются) единственным средством разработки во многих случаях: когда нужна графика, когда нужен доступ к файлам клиента, когда нужен доступ к clipboard, когда нужно например шифрование — потому что шифрование на javascript это нонсенс, особенно 20 лет назад. Почему клиент-банки во множестве на апплетах? Потому что шифрование и электронная подпись.

А теперь перечитайте фразу Грэма про апплеты, и вдумайтесь, чем он хвастает? Тем что клиент-серверных приложений у них не было, а были только серверные. Вот вы серьезно думаете, что это достижение? По-моему, это просто глупость.
Перечитал.
Server-based — это синоним «клиент-серверные с тонким клиентом».
Java-апплеты были придуманы для клиента потолще, но всё равно в клиент-серверной парадигме.
Иначе проще скачать приложение (любым способом и протоколом) и запустить как обычное Java-приложение.
Апплеты за очень редким исключением запускались из браузера и из его процесса, что было их недостатком в случае апплета с собственным окном — пользователи закрывали браузер после запуска апплета, и апплет закрывался вместе с ним.
В этой статье Грэм продвигает Server-based computing в противопоставление standalone приложениям. Из всех его доводов это прозрачно видно. Что касается апплетов в этом разрезе, то история с практической стороны показала какое место они получили в компьютерной индустрии.
История с практической стороны показала, что даже сейчас, в 2016, те вещи, которые я перечислил, вызывают большие проблемы при разработке в стандартной web-парадигме. А тогда реальных альтернатив не было вообще (если не считать flash).

>Грэм продвигает Server-based computing в противопоставление standalone приложениям
И при этом несет чушь о технологиях, которые знает плохо. Это его не извиняет ни разу. «Проще дойти до логического конца и запускать программы на сервере» — проще по сравнению с чем? Понимаете, если вы скажем гугль, и пишете поисковик — то вам и javascript-то не особо нужен. У вас серверное приложение by design.

А если вы банк, и вам скажем нужна на клиенте ЭЦП, то у вас и сегодня, 20 лет спустя, будет очень немного реальных альтернатив тем же апплетам.
Разве Вы читали не внимательно?
Грэм как раз не делал ненужных обобщений — он явно указал, что есть приложения, которые не стоит делать server-based.
А чего Вы так за апплеты-то переживаете?
О них он вроде бы тоже ничего крамольного не сказал.
А может это вы читали невнимательно? У меня как раз создается (субъективное, разумеется, но вполне устойчивое впечатление), что он сплошь и рядом делает ненужные обобщения. А пытаясь критиковать альтернативные решения, допускает явные ляпы. Вот, обратите внимание:

>С приложением на сервере вы можете делать доработки почти так же, как в программе, которую вы пишете для себя. Вы >выпускаете версии как последовательность поэтапных изменений вместо внезапного большого взрыва. Обычно компания, >производящая десктопное ПО, может выпустить одну или две версии за год. Для Viaweb мы часто делали три-пять версий в день.
Что, простите? При чем тут сервер vs desktop? Во-первых, на сегодня это давно устарело, потому что многие вполне настольные приложения легко обновляются с любой частотой. А во-вторых, возможность выпуска версий часто и понемногу — вовсе не особенность серверных приложений. Это особенность бизнеса компании. Опять же — если вы гугль или yahoo, и выпускаете десять версий своего поисковика или карт в день — это никого не волнует, в первую очередь потому, что вы никому ничего не обязаны. Вы как раз и пишете «как для себя». Только это не ваше достижение ни разу, и хвастаться тут нечем.

Ничего крамольного про апплеты? Да он написал так, как будто серверные и клиент-серверные приложения взаимозаменяемы, и мы можем выбрать что захотим. Что совсем не так. Это и есть еще одно ненужное и неправильное обобщение.
Скажите, пожалуйста, что такое, в Вашем понимании, серверное приложение?
И чем оно отличается от клиент-серверного.
А вам с какой целью нужна эта классификация? Что вас в моих формулировках смущает?

Я вполне явные примеры приводил — вот если вы пишете интернет банк, как вы собрались делать его чисто серверным? Без логики и кода на клиенте, без ЭЦП на клиенте, без доступа к файлам клиента?

Когда в качестве примера того, к чему нужно стремиться, приводится почта, мне становится смешно. Это текст 2001 года? Так прошло уже лет 15, а покажите мне сегодня, хотя бы две нормальные реализации веб почты, где есть нормальное вменяемое шифрование end-to-end?

>Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус
Да-да. Слыхали. Опять же, сегодня в 2016 году это выглядит смешно. На сегодня браузер является как раз одной из основных дыр в системе безопасности любой ОС. Потому что практика показала, что чисто серверные приложения, без логики на клиенте, без javascript, java или flash, почти никому не нужны. А когда все это появляется — браузер становится плохо защищенным.
Sign up to leave a comment.