IBM только что объявила о выпуске набора офисных программ IBM Lotus Symphony. Звучит как еще один вариант StarOffice (бесплатного пакета офисных прогамм от Sun Microsystems). Но я подозреваю, что они пытаются стереть из памяти изначальный вариант Lotus Symphony, который преподносится и пиарился чуть ли не меньше нового пришествия Христа, но в итоге оказался довольно блеклым.
В конце 80-х, Lotus попытался решить, что же делать дальше с их главным продуктом по работе с табличными данными и графикой — Lotus 1-2-3. Было 2 очевидных пути: первый, они могли просто добавить новую функциональность. Например, работу с текстом. Этот продукт был назван Symphony. Другой очевидной идеей было, создать программу, для работы с 3-хмерными таблицами. Так 1-2-3 стала версией 3.0.
Обе идеи быстр уперлись в серьезную проблему: старое ограничение памяти в DOS в 640К. IBM только начал выпускать компьютеры с чипами 80286, которые могли адресовать больше памяти, но Lotus не думал, что рынок достаточно широк для программного обеспечения, которое требовало компьютеров за 10 000$. Поэтому они ужимались и ужимались. Они потратили 18 месяцев, пытаясь заставить работать Lotus 1-2-3 в DOS-е с его ограничением в 640К оперативной памяти, и в конечном счете, после кучи потраченного времени, были вынуждены отказаться от функционала работы с 3-хмерными таблицами, чтобы подогнать свой продукт под ограничение оперативной памяти. В случае же Symphony, они просто отрубали функциональность налево и направо.
Ни одна из стратегий не оказалась правильной. К тому времени, когда Lotus 123 3.0 был выпущен, каждый имел 80386 процессор и 2М оперативной памяти. И Symphony имел несовременный механизм работы с таблицами и работы с текстом и некоторые другие устарелые вещи.
«Ну, хорошо, приятель,» скажете, Вы. «Кого волнуют какие-то старые программы?»
Но, дайте мне минуту, потому что история повторяет себя вновь и вновь, и умной стратегией является сделать ставку, что те же результаты повторятся снова.
С начала времен и до, скажем, 1989 года, программисты были очень озабочены проблемами производительности. Потому что, у компьютеров просто не было много памяти и высокой производительности процессора.
В поздние 90-е парочка компаний, включаю Microsoft и Apple, заметила (чуть раньше, чем все остальные) что закон Мура означает, что им не стоит уделять слишком много внимания производительности и экономии памяти… просто создавать хорошие продукты, и ждать появления железа, на котором все это будет работать. Microsoft впервые выпустил Excel для Windows, когда 80386-ые были слишком дороги для большинства пользователей, но они были терпеливы. Не дольше, чем через 2 года, вышли 80386SX, и каждый, кто был в состоянии позволить себе выделить 1500$ мог работать в Excel.
Как программист, говорю спасибо снижению цены на оперативную память. И количество циклов CPU удваивалось каждый год, у Вас появился выбор. Вы могли провести 6 месяцев, переписывая ваши внутренние циклы на Ассемблере или лучше 6 месяцев стучать на барабанах в рок-группе, и в том и в другом случае, ваша программа станет работать быстрее. Программисты на Ассемблере перестали пользоваться популярностью.
Так что теперь мы больше не заботимся слишком много об оптимизации и производительности.
Кроме одного момента: JavaScript, работающий на браузерах в Ajax приложениях. И с некоторых пор – это то направление, в котором двигаются почти все разработчики программного обеспечения, потому что это большое дело.
Многие из сегодняшних программистов Ajax имеют мегабайт, или даже больше кода на стороне клиента. В тоже время, это не оперативка или процессор создает ограничение: это время загрузки по ограниченному сетевому каналу, и время компиляции. В любом случае, Вам действительно придется ужиматься, чтобы создавать хорошие комплексные Ajax приложения.
Однако история, повторяется. Широкие интернет-каналы становятся все более дешевыми. Люди задумываются, как создать предварительно откомпилированный (precompiled) JavaScript.
Разработчики, кто вкладывает много времени в оптимизацию, уплотнение и убыстрение однажды проснутся и обнаружат, что усилия были потрачены впустую, или, по крайней мере, Вы можете сказать, что это «не дало им весомых преимуществ», если Вы из тех людей, которые говорят на языке экономистов.
Разработчики, кто не обращал внимания на производительность и предпочитали добавлять в свои приложения классные и удобные вещи, на долгой дистанции, будут иметь лучшие приложения.
Язык программирования C был изобретен с явной целью упростить переход приложений от одной инструкции к другой. И это позволило сделать огромный шаг вперд. Но не создало на 100% портируемый язык, так мы получили Java, который был даже более портируемым, чем C. Мммм…
Прямо сейчас есть огромная брешь в истории портируемости. И это – Таадааам! – клиентская сторона JavaScript, особенно DOM (объектная модель документа) в Веб-браузерах. Написание приложений, которые должны работать во всех существующих различных браузерах просто кошмар. Здесь нет альтернативы, кроме как полноценно тестировать в Firefox, IE6, IE7, Safari, and Opera, и знаете что? У меня нету времени, чтобы тестировать на Opera. Operа отсасывает. Стартапам нет пути на рынок браузеров.
И как же ситуация будет развиваться дальше? Ну хорошо, вы можете попытаться умолять Microsoft и Firefox быть более совместимыми. Удачи вам в этом. Вы можете следовать p-code/Java модели и создавать песочницы (sandbox) — надстройку над внутренней системой. Но это не лучший вариант. Песочницы медленные и отстойные, вот почему Java апплеты отмирают. Чтобы создать песочницу, ваш приговор – работать на 1/10 от скорости платформы, над которой вы создали надстройку. И ваша судьба в том, что вы никогда не сможете использовать функции, которые есть на одних платформах, но отсутствуют на других. (Я все еще жду хоть одного человека, кто мне покажет Java апплет для телефонов, который может получить доступ к какой-либо функции в телефоне, такой как камера, список контактов, SMS сообщения или GPS приемник).
Песочницы никогда не работали и они не работают и сейчас.
И что же будет дальше? Лидеры идут тем путем, который сработал в Bell Labs в 1978 году: построить программный язык, как C, который являлся бы портирумым и эффективным. Он должен компилироваться (compile down) в родной код (родной код, который был бы JavaScript и DOM) с различными бэкендами для различных платформ, где бы разработчики компилятора уже позаботились о производительности, и Вам бы уже не пришлось это делать. Такой язык будет иметь всю мощь чистого JavaScript с полным доступом к объектной модели документа (DOM). И он будет компилирован в родные языки IE и Firefox гибко и автоматически. И да, он войдет в Ваш CSS пугающим, но логичном способом, так, что Вам больше никогда не придется думать о несоответствиях разных браузеров при работе с CSS. Навсегда! О наслаждение, когда, наконец, наступит этот день.
Система IBM 360 использовала пользовательский интерфейс, называемый CICS, который вы все еще можете встретить в аэропорту, когда вы проходите проверочный контроль. Там 80 символов на 24 символа зеленый экран, и только текстовый режим естественно. Главная система (mainframe) отсылает клиенту форму (клиентом является 3270-й терминал). Терминал умный; он знает, как отобразить форму и предоставить Вам возможность ввести данные без взаимодействия с главной системой. Это было одной из причин, почему системы mainframe были намного более мощными, чем Unix: центральному процессору не приходилось управлять редактированием отдельных строк, это было доверено умному терминалу. (Если Вы не могли позволить себе установить умные терминалы для каждого, вы бы купили System/1 – миникомпьютер, который устанавливается между терминалами и главной системой и управляет процессом редактирования).
В любом случае, после того, как вы заполнили форму, вы нажимаете «Отправить», и ваш ответ отсылается на сервер для обработки. И затем сервер вам высылает следующую форму. И так далее и так далее.
Ужас. Как вы создадите текстовый процессор в среде такого типа? (Вы действительно не можете. И на самом деле никогда и не существовало приличного текстового процессора для таких систем).
Это был первый уровень. Он сообщался соответствует HTML фазе Интернета. HTML – это тот же CICS, только со шрифтами.
На втором уровне, каждый купи PC для своего рабочего стола, и конечно же, программисты смогли пихать текст в любое место экрана, куда они хотели и когда они этого хотели, и Вы действительно могли считать каждое нажатие клавиши от пользователя, когда он печатал. Таким образом, вы могли создавать отличные быстрые приложения, которым не нужно ждать, когда вы нажмете на кнопку «Отправить», прежде чем процессор мог начать обработку данных. Так, например, вы могли создать текстовый процессор, который автоматически заканчивал строку, сдвигая слова вниз, на следующую линию. Сразу же! О мой Бог. Вы можете так сделать?
Проблема на втором уровне была в том, что не было ясных стандартов пользовательского интерфейса… программисты имели слишком много гибкости, поэтому каждый писал своим способом, что создавало большие трудности. Если вы знали, как пользоваться программой X, вы так же использовали и программу Y. WordPerfect и Lotus 1-2-3 имели полностью различные системы меню, интерфейсы клавиатуры, и структуры команд. И о копирование данных между ним даже не стоял вопрос.
И это именно то, где мы находимся с использованием Ajax на сегодняшний день. Конечно, удобства намного больше, чем при первом поколении приложений DOS, потому что мы усвоили некоторые вещи с тех пор. Но Ajax приложения могут быть несовместимы и иметь много проблем, чтобы работать вместе – Вы не можете вырезать объект из одного Ajax приложения и вставить в другое, например. Поэтому, я не уверен, что вы сможете перенести картинку из Gmail во Flickr. Ну же, парни! Метод вырезать-вставить был изобретен 25 лет назад.
Третьей фазой с персональными компьютерами было Macintosh и Windows. Стандартный, согласующийся пользовательский интерфейс с такой функциональностью, как много окон на экране и буфер обмена, созданный так, чтобы приложения могли работать вместе. Мы получили потрясающее удобство использования и мощь от этих новых графических пользовательских интерфейсов, которые привели к очень быстрому распространению персональных компьютеров.
Так, что если история повторится вновь, мы можем ждать некоторой стандартизации в интерфейсах Ajax приложений, чтобы развитие сложилось таким же образом, каким оно сложилось, когда мы получили Microsoft Windows. Кто-то собирается написать SDK (Software Development Kit — пакет средств разработки), которую можно будет использовать, чтобы создавать мощные Ajax приложения с общим элементами пользовательского интерфейса, которые отлично работают вместе. И такая SDK завоюет умы большинства разработчиков и получит то же конкурентное преимущество, которое получила Microsoft, создав свой Windows с его API.
Если ты веб-разработчик, и ты не хочешь придерживаться стандартов SDK, которых придерживаются все остальные, ты будешь встречать все больше людей, которые не захотят использовать твое веб-приложение, потому что он не позволяет, знаешь ли, вырезать и вставить и не позволяет синхронизироваться с адресной книгой и не поддерживает еще какой-либо функционал, который мы будем иметь в 2010 году.
Вообразите, например, что вы – это Гуугл с Вашим GMail, и вы чувствуете нарастающее самодовольство. Но вскоре, кто-то, о ком вы никогда не слышали, некий начинающий стартапер, возможно, предпринимает смешные попытки распространить новую SDK, которая объединяет хороший портируемый язык программирования, который компилируется в JavaScript, и даже более того, огромную библиотеку Ajax-овых фишек. Не просто вырезать-и-вставить: классные увлекательные вещи, такие как синхронизация и управление идентификацией из единой точки (single-point identity management), так что вам не нужно сообщать Facebook и Twitter о том, что Вы делаете, вы можете просто осуществить вход через единую точку. И Вы смеетесь над ними, потому что новая SDK имеет пугающий размер в 232 мегабайта …232 мегабайта! Одного только JavaScript и требует 76 секунд только для того, чтобы загрузить страницу. И Ваше приложение, GMail не потеряет своих клиентов.
Но потом, когда вы видите на совеем гуугл-стуле в гуугл-плексе, попивая свой гуугл-чино и чувствуя надменность, надменность, надменность, новые версии браузеров выходят, которые поддерживают кэширование, скомпилированного JavaScript. И конечно новая SDK теперь действительно быстра. И Пол Грэхам дает им еще 6000 коробок лапши быстрого приготовления, чтобы питаться, так что они остаются в бизнесе еще на три года, чтобы улучшать начатое.
И ваши программисты говорят, что GMail слишком огромный и они не могут его портировать в эту тупую новую SDK. Им бы пришлось поменять каждую строку кода. Поэтому он должен быть полностью переписан, вся программная в беспоряде и содержит множество рекурсий и портируемый язык программирования содержит так много круглых скобок, что даже Гуугл не способен купить. Последняя строка почти каждой из функций содержит 3396 правых закрывающих круглых скобок. Вам нужно нанять специального редактора, чтобы сосчитать их.
Люди, использующий новую SDK уже разработали приличный текстовый процессор. И приличную систему работы с почтой. И убийственный Facebook/Twitter публикатор событий, который может синхронизоваться со всем, так что люди начали использовать его.
И пока вы не обращаете внимания, все начинают писать в новой SDK приложения, и они реально хороши, и, конечно же, бизнес, хочет только приложения, написанные на новой SDK. И все эти старомодные, примитивные Ajax приложения выглядят жалко и не могут даже осуществить операцию вырезать-вставить и синхронизовать и отлично взаимодействуют друг с другом. И GMail превращается в наследие прошлого. WordPerfect от электронной почты. И вы скажете вашим детям, как восхитительно вы себя чувствовали, когда получили 2Гб дискового пространства для хранения почты, а они будут смеяться над Вами.
Неправдоподобная сказка? Замените “Google Gmail”на “Lotus 1-2-3”. Новая SDK станет вторым пришествием Microsoft Windows. Это в точности как Lotus потерял контроль над рынком работы c табличными данными. И это произойдет снова в Web, потому что во всем этом та же самая динамика. Единственное, чего мы пока не знаем – это частностей, но это произойдет.
Эта статья появилась на домашней страничке Joel on Software. Здесь я выложил мой перевод.
Что скажете?
В конце 80-х, Lotus попытался решить, что же делать дальше с их главным продуктом по работе с табличными данными и графикой — Lotus 1-2-3. Было 2 очевидных пути: первый, они могли просто добавить новую функциональность. Например, работу с текстом. Этот продукт был назван Symphony. Другой очевидной идеей было, создать программу, для работы с 3-хмерными таблицами. Так 1-2-3 стала версией 3.0.
Обе идеи быстр уперлись в серьезную проблему: старое ограничение памяти в DOS в 640К. IBM только начал выпускать компьютеры с чипами 80286, которые могли адресовать больше памяти, но Lotus не думал, что рынок достаточно широк для программного обеспечения, которое требовало компьютеров за 10 000$. Поэтому они ужимались и ужимались. Они потратили 18 месяцев, пытаясь заставить работать Lotus 1-2-3 в DOS-е с его ограничением в 640К оперативной памяти, и в конечном счете, после кучи потраченного времени, были вынуждены отказаться от функционала работы с 3-хмерными таблицами, чтобы подогнать свой продукт под ограничение оперативной памяти. В случае же Symphony, они просто отрубали функциональность налево и направо.
Ни одна из стратегий не оказалась правильной. К тому времени, когда Lotus 123 3.0 был выпущен, каждый имел 80386 процессор и 2М оперативной памяти. И Symphony имел несовременный механизм работы с таблицами и работы с текстом и некоторые другие устарелые вещи.
«Ну, хорошо, приятель,» скажете, Вы. «Кого волнуют какие-то старые программы?»
Но, дайте мне минуту, потому что история повторяет себя вновь и вновь, и умной стратегией является сделать ставку, что те же результаты повторятся снова.
Ограничение памяти и мощности процессора.
С начала времен и до, скажем, 1989 года, программисты были очень озабочены проблемами производительности. Потому что, у компьютеров просто не было много памяти и высокой производительности процессора.
В поздние 90-е парочка компаний, включаю Microsoft и Apple, заметила (чуть раньше, чем все остальные) что закон Мура означает, что им не стоит уделять слишком много внимания производительности и экономии памяти… просто создавать хорошие продукты, и ждать появления железа, на котором все это будет работать. Microsoft впервые выпустил Excel для Windows, когда 80386-ые были слишком дороги для большинства пользователей, но они были терпеливы. Не дольше, чем через 2 года, вышли 80386SX, и каждый, кто был в состоянии позволить себе выделить 1500$ мог работать в Excel.
Как программист, говорю спасибо снижению цены на оперативную память. И количество циклов CPU удваивалось каждый год, у Вас появился выбор. Вы могли провести 6 месяцев, переписывая ваши внутренние циклы на Ассемблере или лучше 6 месяцев стучать на барабанах в рок-группе, и в том и в другом случае, ваша программа станет работать быстрее. Программисты на Ассемблере перестали пользоваться популярностью.
Так что теперь мы больше не заботимся слишком много об оптимизации и производительности.
Кроме одного момента: JavaScript, работающий на браузерах в Ajax приложениях. И с некоторых пор – это то направление, в котором двигаются почти все разработчики программного обеспечения, потому что это большое дело.
Многие из сегодняшних программистов Ajax имеют мегабайт, или даже больше кода на стороне клиента. В тоже время, это не оперативка или процессор создает ограничение: это время загрузки по ограниченному сетевому каналу, и время компиляции. В любом случае, Вам действительно придется ужиматься, чтобы создавать хорошие комплексные Ajax приложения.
Однако история, повторяется. Широкие интернет-каналы становятся все более дешевыми. Люди задумываются, как создать предварительно откомпилированный (precompiled) JavaScript.
Разработчики, кто вкладывает много времени в оптимизацию, уплотнение и убыстрение однажды проснутся и обнаружат, что усилия были потрачены впустую, или, по крайней мере, Вы можете сказать, что это «не дало им весомых преимуществ», если Вы из тех людей, которые говорят на языке экономистов.
Разработчики, кто не обращал внимания на производительность и предпочитали добавлять в свои приложения классные и удобные вещи, на долгой дистанции, будут иметь лучшие приложения.
Портируемый (portable) язык программирования.
Язык программирования C был изобретен с явной целью упростить переход приложений от одной инструкции к другой. И это позволило сделать огромный шаг вперд. Но не создало на 100% портируемый язык, так мы получили Java, который был даже более портируемым, чем C. Мммм…
Прямо сейчас есть огромная брешь в истории портируемости. И это – Таадааам! – клиентская сторона JavaScript, особенно DOM (объектная модель документа) в Веб-браузерах. Написание приложений, которые должны работать во всех существующих различных браузерах просто кошмар. Здесь нет альтернативы, кроме как полноценно тестировать в Firefox, IE6, IE7, Safari, and Opera, и знаете что? У меня нету времени, чтобы тестировать на Opera. Operа отсасывает. Стартапам нет пути на рынок браузеров.
И как же ситуация будет развиваться дальше? Ну хорошо, вы можете попытаться умолять Microsoft и Firefox быть более совместимыми. Удачи вам в этом. Вы можете следовать p-code/Java модели и создавать песочницы (sandbox) — надстройку над внутренней системой. Но это не лучший вариант. Песочницы медленные и отстойные, вот почему Java апплеты отмирают. Чтобы создать песочницу, ваш приговор – работать на 1/10 от скорости платформы, над которой вы создали надстройку. И ваша судьба в том, что вы никогда не сможете использовать функции, которые есть на одних платформах, но отсутствуют на других. (Я все еще жду хоть одного человека, кто мне покажет Java апплет для телефонов, который может получить доступ к какой-либо функции в телефоне, такой как камера, список контактов, SMS сообщения или GPS приемник).
Песочницы никогда не работали и они не работают и сейчас.
И что же будет дальше? Лидеры идут тем путем, который сработал в Bell Labs в 1978 году: построить программный язык, как C, который являлся бы портирумым и эффективным. Он должен компилироваться (compile down) в родной код (родной код, который был бы JavaScript и DOM) с различными бэкендами для различных платформ, где бы разработчики компилятора уже позаботились о производительности, и Вам бы уже не пришлось это делать. Такой язык будет иметь всю мощь чистого JavaScript с полным доступом к объектной модели документа (DOM). И он будет компилирован в родные языки IE и Firefox гибко и автоматически. И да, он войдет в Ваш CSS пугающим, но логичном способом, так, что Вам больше никогда не придется думать о несоответствиях разных браузеров при работе с CSS. Навсегда! О наслаждение, когда, наконец, наступит этот день.
Высокая интерактивность и стандарты пользовательских интерфейсов.
Система IBM 360 использовала пользовательский интерфейс, называемый CICS, который вы все еще можете встретить в аэропорту, когда вы проходите проверочный контроль. Там 80 символов на 24 символа зеленый экран, и только текстовый режим естественно. Главная система (mainframe) отсылает клиенту форму (клиентом является 3270-й терминал). Терминал умный; он знает, как отобразить форму и предоставить Вам возможность ввести данные без взаимодействия с главной системой. Это было одной из причин, почему системы mainframe были намного более мощными, чем Unix: центральному процессору не приходилось управлять редактированием отдельных строк, это было доверено умному терминалу. (Если Вы не могли позволить себе установить умные терминалы для каждого, вы бы купили System/1 – миникомпьютер, который устанавливается между терминалами и главной системой и управляет процессом редактирования).
В любом случае, после того, как вы заполнили форму, вы нажимаете «Отправить», и ваш ответ отсылается на сервер для обработки. И затем сервер вам высылает следующую форму. И так далее и так далее.
Ужас. Как вы создадите текстовый процессор в среде такого типа? (Вы действительно не можете. И на самом деле никогда и не существовало приличного текстового процессора для таких систем).
Это был первый уровень. Он сообщался соответствует HTML фазе Интернета. HTML – это тот же CICS, только со шрифтами.
На втором уровне, каждый купи PC для своего рабочего стола, и конечно же, программисты смогли пихать текст в любое место экрана, куда они хотели и когда они этого хотели, и Вы действительно могли считать каждое нажатие клавиши от пользователя, когда он печатал. Таким образом, вы могли создавать отличные быстрые приложения, которым не нужно ждать, когда вы нажмете на кнопку «Отправить», прежде чем процессор мог начать обработку данных. Так, например, вы могли создать текстовый процессор, который автоматически заканчивал строку, сдвигая слова вниз, на следующую линию. Сразу же! О мой Бог. Вы можете так сделать?
Проблема на втором уровне была в том, что не было ясных стандартов пользовательского интерфейса… программисты имели слишком много гибкости, поэтому каждый писал своим способом, что создавало большие трудности. Если вы знали, как пользоваться программой X, вы так же использовали и программу Y. WordPerfect и Lotus 1-2-3 имели полностью различные системы меню, интерфейсы клавиатуры, и структуры команд. И о копирование данных между ним даже не стоял вопрос.
И это именно то, где мы находимся с использованием Ajax на сегодняшний день. Конечно, удобства намного больше, чем при первом поколении приложений DOS, потому что мы усвоили некоторые вещи с тех пор. Но Ajax приложения могут быть несовместимы и иметь много проблем, чтобы работать вместе – Вы не можете вырезать объект из одного Ajax приложения и вставить в другое, например. Поэтому, я не уверен, что вы сможете перенести картинку из Gmail во Flickr. Ну же, парни! Метод вырезать-вставить был изобретен 25 лет назад.
Третьей фазой с персональными компьютерами было Macintosh и Windows. Стандартный, согласующийся пользовательский интерфейс с такой функциональностью, как много окон на экране и буфер обмена, созданный так, чтобы приложения могли работать вместе. Мы получили потрясающее удобство использования и мощь от этих новых графических пользовательских интерфейсов, которые привели к очень быстрому распространению персональных компьютеров.
Так, что если история повторится вновь, мы можем ждать некоторой стандартизации в интерфейсах Ajax приложений, чтобы развитие сложилось таким же образом, каким оно сложилось, когда мы получили Microsoft Windows. Кто-то собирается написать SDK (Software Development Kit — пакет средств разработки), которую можно будет использовать, чтобы создавать мощные Ajax приложения с общим элементами пользовательского интерфейса, которые отлично работают вместе. И такая SDK завоюет умы большинства разработчиков и получит то же конкурентное преимущество, которое получила Microsoft, создав свой Windows с его API.
Если ты веб-разработчик, и ты не хочешь придерживаться стандартов SDK, которых придерживаются все остальные, ты будешь встречать все больше людей, которые не захотят использовать твое веб-приложение, потому что он не позволяет, знаешь ли, вырезать и вставить и не позволяет синхронизироваться с адресной книгой и не поддерживает еще какой-либо функционал, который мы будем иметь в 2010 году.
Вообразите, например, что вы – это Гуугл с Вашим GMail, и вы чувствуете нарастающее самодовольство. Но вскоре, кто-то, о ком вы никогда не слышали, некий начинающий стартапер, возможно, предпринимает смешные попытки распространить новую SDK, которая объединяет хороший портируемый язык программирования, который компилируется в JavaScript, и даже более того, огромную библиотеку Ajax-овых фишек. Не просто вырезать-и-вставить: классные увлекательные вещи, такие как синхронизация и управление идентификацией из единой точки (single-point identity management), так что вам не нужно сообщать Facebook и Twitter о том, что Вы делаете, вы можете просто осуществить вход через единую точку. И Вы смеетесь над ними, потому что новая SDK имеет пугающий размер в 232 мегабайта …232 мегабайта! Одного только JavaScript и требует 76 секунд только для того, чтобы загрузить страницу. И Ваше приложение, GMail не потеряет своих клиентов.
Но потом, когда вы видите на совеем гуугл-стуле в гуугл-плексе, попивая свой гуугл-чино и чувствуя надменность, надменность, надменность, новые версии браузеров выходят, которые поддерживают кэширование, скомпилированного JavaScript. И конечно новая SDK теперь действительно быстра. И Пол Грэхам дает им еще 6000 коробок лапши быстрого приготовления, чтобы питаться, так что они остаются в бизнесе еще на три года, чтобы улучшать начатое.
И ваши программисты говорят, что GMail слишком огромный и они не могут его портировать в эту тупую новую SDK. Им бы пришлось поменять каждую строку кода. Поэтому он должен быть полностью переписан, вся программная в беспоряде и содержит множество рекурсий и портируемый язык программирования содержит так много круглых скобок, что даже Гуугл не способен купить. Последняя строка почти каждой из функций содержит 3396 правых закрывающих круглых скобок. Вам нужно нанять специального редактора, чтобы сосчитать их.
Люди, использующий новую SDK уже разработали приличный текстовый процессор. И приличную систему работы с почтой. И убийственный Facebook/Twitter публикатор событий, который может синхронизоваться со всем, так что люди начали использовать его.
И пока вы не обращаете внимания, все начинают писать в новой SDK приложения, и они реально хороши, и, конечно же, бизнес, хочет только приложения, написанные на новой SDK. И все эти старомодные, примитивные Ajax приложения выглядят жалко и не могут даже осуществить операцию вырезать-вставить и синхронизовать и отлично взаимодействуют друг с другом. И GMail превращается в наследие прошлого. WordPerfect от электронной почты. И вы скажете вашим детям, как восхитительно вы себя чувствовали, когда получили 2Гб дискового пространства для хранения почты, а они будут смеяться над Вами.
Неправдоподобная сказка? Замените “Google Gmail”на “Lotus 1-2-3”. Новая SDK станет вторым пришествием Microsoft Windows. Это в точности как Lotus потерял контроль над рынком работы c табличными данными. И это произойдет снова в Web, потому что во всем этом та же самая динамика. Единственное, чего мы пока не знаем – это частностей, но это произойдет.
Эта статья появилась на домашней страничке Joel on Software. Здесь я выложил мой перевод.
Что скажете?