Оберон-клуб «ВЄДАsoft»

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

А в обратную сторону? У нас есть объекты JS, которые мы не создали и не контролируем (хотя бы document). Как работать с ними из Оберона? Работать наверняка можно, но никакого преимущества по сравнению с работой с ними же из JS не получим. Поскольку Оберон может обещать, что у такого-то RECORD-а всегда есть поле с таким-то именем, а в JS такой гарантии нет.

Тогда они могут дать выигрыш, соединяя надёжность статического контроля типов и быстроту безтиповой системы. Если целевая платформа динаимически типизированная с неотключаемыми проверками, как JS, производительность будет ограничена. Именно это я имел в виду, говоря о сомнительности. А вот строить динамический язык поверх статического вполне имеет смысл.

Идея работы с OberonJS вместо JS как раз в том и заключается, что бы исключить все эти проблемы из-за бардака с объектами JS. Чем меньше приходится иметь дела с мусором, тем легче поддерживать порядок в системе.

Допустим, можно выкинуть все библиотеки, начиная с jQuery. Но DOM-то нельзя выкинуть. С ним как?

Смотрите примеры https://models.molpit.org/model/49

Для jQuery при желании можно сделать обёртку. Веселовский (valexey) делал обёртку для Processing.
DOM -- это же по сути древовидная структура данных, в чём проблема наколбасить необходимые типы, что бы иметь строго-типизированную работу с DOM? Нужно иметь лишь время и желание...

Хотя это не самый лучший пример для DOM. Надо у Владислава спросить.
Мне DOM как-то не особо нужен был, больше работал с холстом и рисованием.

Я в подобные вещи на лиспе наигрался и убедился в их неэффективности. Если этот же код записан в файле .js, то на него можно поставить брекпойнт, а компилятор может оптимизировать файл целиком, найдя в нём ошибки. Если же код генерируется мелкими порциями на лету, и я написал innerHtml вместо innerHTML, то, во-первых, это место сложно найти. Если выпало исключение, то истинный исходник определить сложно. И это будет работать медленнее. Т.е., да, сделать так можно и работать так можно, но плюсы Оберона будут перекрыты минусами связки. Если не использовать DOM, а рисовать на холсте - тогда может быть.

В том, что объект DOM - это не Record, он по-другому устроен. Преимущества Оберона здесь не проявятся, надёжности при работе с DOM не добавится. Максимум, можно отобразить обязательно существующие функции и поля документа на записи Оберона. Но пользователь всегда может что-то добавить, и это уже не будет подвергнуто статическому контроля. Т.е. получается, что преимуществами статической типизации Оберона можно будет воспользоваться только при написании библиотек, которые тягать придётся всё равно из JS. Я не говорю, что это не имеет смысла, но нужно понимать, что область применения такого решения ограничена.