Google выпустила первую версию своего языка программирования Dart

>  Или что ты понимаешь под «самоубийством» на примере, скажем, Ruby on Rails?

Ruby on Rails разработан как переосмысление REST подхода php. Это шаг вперёд, но лишь один шаг. Да, ActiveRecord рулит. Но всё равно, в RoR задача первостепенной важности — генерация html’я на выходе, которая сводится к шаблонам и состыкованию кусков html’я. AJAX для Ruby on Rails, если по-хорошему, что-то инородное, потому что для него инороден javascript.

Писать веб-приложения используя непосредственно html — это примерно то же самое, что писать GUI приложение используя Xlib.

Я распишу поподробнее, как на мой взгляд должен выглядеть фреймворк.

1. Никакого html’я, вместо него библиотека виджетов. То есть, не тег table, а виджет Table, который мы создаём как объект, проставляем свойства, выдаём ему модель, которая будет работать как адаптер между Table и нашим внутренним представлением данных. Добавляем Table в общее дерево виджетов, вызываем для корневого виджета метод render. Этот самый table, уже умеет сортировать записи по разным столбцам, разбивать их на страницы, возможно он позволяет выделять одну или несколько записей. Возможно для этого он использует технологии AJAX. Как он это делает нам не интересно, мы можем даже не знать этого. Этот виджет может использовать тег table, а может и не использовать — это его личное дело. Всё что нам надо знать — это внешний API к Table.

2. Никакого SQL’я и прочих NoSQL’ей. Это всё тоже должно инкапсулироваться глубоко-глубоко. В идеале настолько глубоко, чтобы для нас был бы безболезненным переход не только с MySQL на PostreSQL, но так же и переход на что-нибудь типа BerkeleyDB. В идеале, фреймворк должен предлагать объектно-ориентированную базу данных. Умея использовать для постоянного хранения различные бэкэнды.

3. Никакого javascript’а. Все client-side коллбеки мы развешиваем на виджеты в качестве свойств, причём пишем их на том же языке, на котором и серверную часть. Это правда порождает проблемы: не раз в новостях о безопасности я натыкался на упоминание о случаях, когда web-приложение проверяло пару логин/пароль на стороне клиента, и как я понимаю, это прямое следствие подобного подхода, потому что в коде веб-приложения, клиентский код уже не отличается внешним видом от серверного, что может подтолкнуть к ошибке. Но ошибки ошибками, а это удобно. Потому что javascript генерируется в результате компиляции, и поэтому заведомо не содержит кучи глупых ошибок. В частности это гарантированно избавляет от XSS, поскольку код фреймворка, выводя в результате html-код, делает это компилируя внутреннее представление страницы, в котором скомпилированный клиентский код — это объект специального типа, который никак не может получиться «случайно».

4. Continuations. Мы описываем не страницы, а control-flow. Мы пишем приложение, используя подход близкий к подходам используемым при создании классического GUI-приложения. Например, continuations могут быть реализованы при помощи создания thread’ов операционной системы, на каждого клиента по thread’у, последовательные запросы клиента (AJAX запросы, переходы по ссылкам, и пр) обрабатываются одним и тем же thread’ом, и каждый thread работает ровно с одним клиентом. Использование thread’ов может быть весьма неэффективным, но дело в том, что возможны и другие способы добиться того же самого. Которые могут быть во-первых эффективнее, а во-вторых позволять сохранять такой «thread» в бд. Про thread’ы я начал разговор лишь в качестве примера, для того чтобы проще объяснить было.

Пользователю глубоко фиолетово на технологии на самом деле. Вот еЕсли дарт позволит написать такой мегакрутой сервис для обмена фотками котиков, который нельзя написать на JS, то да, это будет очень крутой рекламой.

Ээээм… Чего-же он медленный-то? Ну да, флоаты на нем лучше не решать. Но это из-за принятого в JS стандарта по плавучке… А вообще JS — компилируемый язык. Чего V8 и делает. И исполняет затем нативный код для архитектуры (ну есесно в песочнице). (кстати, получаемый код порой быстрее чем откомпилированный С++. И этот подход  используется очень широко. Тот-же LLVM)

Задачи компиляции, в данной ситуации сводятся к:

1. Проверка синтаксиса, типизации, возможно глупых ошибок, допустим типа if(a = 2): gcc на это выдаёт варнинг, предлагая либо заменить  a=2 на a==2, либо на (a=2). Примерно так же может поступать компилятор Dart’а.

2. Вообще задача сделать javascript код в серверном языке чем-нибудь отличным от строки. javascript — это код, пускай и клиентский, и хранить его строкой, со всей путаницей которую это порождает — глупость.

3. Совместимость с браузерами. Мы используем для написания клиент-сайд скриптов то, что удобно нам, даже если это не поддерживается браузерами, но и тем не менее этап компиляции позволяет нам работать с любым браузером, который умеет javascript.

4. Подчастую это позволяет малой кровью добиваться работоспособности AJAX-rich приложения в браузере не поддерживающем javascript: просто код, задуманный программистом как клиентский, выполняется на сервере, и клиенту высылается новая «версия» страницы.