Комментарии 167
Учетная система на базе 1С в принципе не предназначена для таких нагрузок, которые выносит nginx.
Есть подтвержденные данные о таких нагрузках? На чем основывается ваше утверждение?
Он примитивный сервер статики. Все сложное-умное nginx передает для обработки в другие подсистемы (как говорят англоязычные — «в верхний поток»)
Кластер 1С — это типичный сервер приложений.
Нагрузку которую способен держать многомудрый сервер приложений НА ПОРЯДКИ меньше нагрузки, которую способен держать простейший сервер статики.
На порядки, Карл!!! На порядки.
Не нужно никаких подтвержденных данных, пошевелить мозгами нужно.
Nginx не сервер приложений, но и Apache им тоже, фактически, не является. Он значится как web-сервер. А возможность запуска приложений внутри web-сервера, на мой взгляд, немного устарела (это было здорово лет 12-15 назад). Отдельный сервер приложений является лучшим решением. Для меня в более правильной связкой выглядит: web-сервер -> сервер приложения -> приложение (nginx -> php-fpm -> скрипты, nginx -> uwsgi -> скрипты).
Поэтому и есть желание что бы была прямая связь: nginx -> 1C. Через модуль ли к nginx'у или через отдельный сервер приложений (коим, по сути, является Кластер 1С) не имеет значения.
Скорее уже скоро нужно будет отказываться от обычного клиента в пользу веб-клиента и прогрессивных приложений.
Вот есть склад, на складе старый комп — франкеншейн, собранный айтишниками «из того что было». На этот комп прилетают сборочные накладные. Старшой по складу их печатает, отдаёт не самым высокоинтеллектуальным подчинённым собирать, потом помечает в системе галочками «собрано» и «отгружено». Всё.
Вот за чем на этом компе браузер и вообще интернет? Чтобы порнуху смотрели и в одноклассниках зависали вместо работы?
Скажите пожалуйста, а когда 1С начнёт работать с Apache HTTP актуальной версии? 2.0 уже фиг где найдёшь, 2.2 тоже уже устарел.
Если у вас SaaS решение для мелкого бизнеса и невысокий уровень владения ИТ конечных пользователей, то это создает некоторые проблемы. Они боятся устанавливать что-либо :)
— периодические проблемы отображения списков
— с передачей файлов побольше 1 мб проблемы
— в apache столкнулись с проблемой работы web-сервисов, пришлось откатится на IIS
— в apache столкнулись с проблемой работы web-сервисов, пришлось откатится на IIS
А что были за проблемы?
Что касается apache, былв проблема с форматом веб-сервиса в том случае если не использовалась сериализация, а просто передавался в веб-сервис на 1С простой String.
На новых платформах не проверяли (и на новом Апаче тоже), у нас Apache пока что табу.
В основном Apache глючил при работе синхронизации с мобильной платформой. Только перешли на IIS сразу все стабилизировалось.
Что касается мобильного приложения на очень рады выходу 8.3.9, но есть один серьезный баг, который не получается победить, а именно, не обновляется мобильная платформа, если запускать отладку с платформы в windows, хотя в 8.3.7 — 8.3.8 это работало и это было ПРЕКРАСНО, а теперь приходится по 100 раз в день пересобирать приложение.
Основная проблема была в работе с файлами и с упрошенными типами данных
Сила 1С как раз в разумном ограничении инструментария разработчика бизнес-приложения.
Ну а если все же нужна вся мощь — есть технология внешних компонентов.
По теме вопрос — на сенсорных экранах прокрутка в динамических списках пальцами работает? Что бы не новомодными кнопками внизу списка листать — а нативненько)
ИМХО разработчикам бизнес-приложений «вся мощь современных языков» скорее вредит, чем помогает.
К сожалению, эта мысль очень сильно укоренилась в 1С, и сама по себе тоталитарна, уж простите. Ведь таким образом, вы решаете за разработчика, что ему будет лучше с одной стороны, но при этом утверждать, что выражении x++ хуже чем x = x + 1, никак нельзя.
Прикладное программирование, конечно, не имеет дело с регистрами процессора или прямой работой с памятью, но оно от этого не перестало быть программированием, мы просто решаем другие задачи.
Я думаю сильно не ошибусь, но уже более 10 лет язык 1С не развивается. Наверное, нет ни одной типовой конфигурации 1С, где кол-во строк кода было бы меньше 100 тысяч. И к чему приводит эта «простота»? Загляните в модуля, посмотрите, что там происходит, многословные префиксы и суффиксы, ни к чему не обязывающие попытки описания интерфейсов через #Область, имена общих модулей и идентификаторов длиною под 100 символов (Пример: ЭлектронныйДокументооборотСКонтролирующимиОрганамиОбновлениеИнформационнойБазы), огромные процедуры с кучей параметров, проверки внутри проверок.
Развитие языка как раз для того и нужно, чтобы писать код было проще, но почему в 1С решили, что чтобы писать код проще – нужно остановить развитие языка, просто непонятно.
Армия разработчиков 1С почти всегда голосует против нововведений по очень простой причине:
1) не хочу никого обидеть, но разработчиков на 1С как таковых не так уж и много, подавляющее большинство, занимается доработками уже созданных решений
2) Люди устали, они просто только-только свыклись с управляемыми форми, тока поняли, как переделывать всё под асинхронность, тока-тока нащупали стабильные релизы, а тут какие-то умники заряжают про интерфейсы, классы и другое в 1С. Многим, когда 500 рыл в базе, звонки каждую минуту и другой головняк, подобные заявления кажутся «несерьёзными».
Никто не говорит про ООП, но ребята, ёлы-палы, давайте что-то делать с языком, хотя бы начать с namespace-ов каких-то, ну это же уже не дело.
Но только встроенные (написанные разработчиками платформы) объекты.
И их кастомизация разработчиками прикладных решений под конкретную задачу.
Еще есть внешние объекты — технология внешних компонент и COM-объекты.
https://github.com/grumagargler
там три репозитория, с тестером, и самими тестами
Петр — ознакомтесь на досуге с тем, как изменилось отношение евангелистов (да и всего) MS к «айтишникам» вообще и разработчикам в частности за последние 5 лет. Очень надеюсь, что это ваше (или того кто придет вам на смену) будущее.
По делу:
1. Нужен git в разработке. Убогое хранилище с кучей костылей в придачу (сорри тем кто их вынужден делать) при разработке даже небольших проектов — это издевательство.
2. Внедрите, наконец-то, разработанный умными людьми (вместо вас) xUnit в типовые и покройте типовые тестами (что сейчас уже умные люди делают вместо вас). Глядишь не придется отзывать релизы на следующий день, а у выходящих не будет висеть по 200 только призванных вами ошибок.
А потом поговорим про «что вредит, а что помогает».
Ну и начните наконец-то работать с нами (с комьюнити) вместо утверждений, что все что вы делаете — делается для нашего же блага. Понятно, что приятнее проводить время в ресторанах с ЛПР, но внедрять и пилить все это нам, а не им.
По вашим рассказам про работу с Платформой мы понимаем, что вы знаете КАК ВЕСТИ разработку. Ужас же со средствами разработки и состоянием типовых создает жуткий когнитивный диссонанс. Пора это вам в 1С признать и что-то с этим сделать.
Есть различные наборы тестов, в т.ч. и для типовых.
Жаль, что для типовых конфигураций тестов еще маловато, похоже, и они не выносятся в общий доступ для возможности их расширения всей сетью партнеров и пользователей.
Жаль, что для типовых конфигураций тестов еще маловато, похоже, и они не выносятся в общий доступ для возможности их расширения всей сетью партнеров и пользователей.
Я очень ценю, что делает 1С, но позволю себе немного жесткой критики.
После продолжительного использования сценарного тестирования своей разработки, есть основание серьёзно задуматься на счет глубины проработки таких тестов в самой 1С. Другими словами — качество, а не количество этих тестов.
В объекте ТестируемоеПриложение, были ошибки (и частично еще остались), которые делали практически невозможным анализ ошибок клиента тестирования. И это выявляется сразу, при прогоне тестов, почему этого не заметили внутри 1С — я думаю потому что разработчик сценарного тестирования (конфигурации) не не был осведомлен о проблеме.
Давайте на чистоту, Петр пишет, что сценарное тестирование проводится, но при этом:
1. Когда я на партнерсах спросил разработчика конфигурации сценарное тестирование 3, используется ли эта разработка внутри 1С, я получил ответ — спросите у разработчиков.
2. Собственный опыт разработки тестов, не раз выявлял ошибки в платформе. Вопрос: почему внутри 1С, их сценарные тесты для типовых конфигураций проходят?
Я думаю, как минимум, на заметку 1С нужно взять то, какого качества эти тесты, что они проводят (я про типовые конфигурации). Например, даже в последней 8.3.9, если тестом заполнять табличную часть у которой последняя колонка автовыбор незаполненного — платформа начинает забивать табличную часть новыми строками, пока не завершит работу аварийно, нет возможности проверить ошибки, выдаваемые в модальных окнах, нет возможности нажимать на ссылки в декорациях, что, например, делает невозможным прогон тестов объектов, где это используется (например, в ERP2 справочник Виды номенклатуры, там невозможно нажать на Тип номенклатуры).
Вот и застряла мысль, вроде как тесты делаются, но насколько они качественные? Очень хочу ошибаться, но видимо все эти тесты сделаны на базе записи прокликиваний на коротких дистанциях.
Всегда нужно помнить, что никакое тестирование не найдет 100% ошибок :(
Возможно, что часть сценариев просто не попадалась специалистам 1С, как бы странно это не звучало :)
Я 3 или 4 года назад спрашивал у разработчика конфигурации сценарное тестирование для УФ (тогда еще был прототип, помнится), используются ли тесты сценарного тестирования в типовых конфигурациях, получил аналогичный ответ :)
На счет Ванессы, к сожалению принцип записи тестов там такой же, как в сценарном тестировании, поэтому я и мои коллеги довольно сдержанно относимся к этому продукту.
Если у вас есть возможность продемонстрировать, на примере ERP2 (демо), создание теста за часа три-четыре: Приход / Расход / Оплата, с анализом/проверкой проводок каждого документа, формированием/проверкой отчетов и затем переиспользование этого теста для организации другой цепи сценария, с другими товарами/услугами/валютой/контрагентами внутри, тогда это бы полностью закрыло все вопросы, говорю честно, не только для меня, но и для многочисленных 1С программистов. Из всего, что я видел по ванессе, выступления и другие ролики, содержат по большей части методику и технику развертывания.
У системы Тестер, с которой вы наверняка знакомы, очень мало инструментов по формированию отчетов по результатам тестирования, и других аналитических возможностей с дружественным интерфейсом, но с одной задачей он справляется хорошо — возможность быстро и коллективном режиме создавать тесты, не только как описал заказчик в тех задании, но и насколько качественно хочет это сделать сам разработчик или руководитель тестирования, покрывая всевозможные отклонения, нажатие кнопок, которые могут генерировать или задавать лишние вопросы и другое. На своей практике, именно этот момент мы считаем ключевым, и именно прогон таких тестов не раз показывал наличие ошибок в платформе.
Но самое важное из всего сказанного я вижу здесь:
показанный вами сценарий с оплатой мы делали за 40 минут для ERP 2 и Бухгалтерии 3.0, но на мой взгляд это совсем не показатель.
Вот именно в этом месте я думаю наши точки зрения и расходятся, потому что это как раз и показатель, и это очень важно. Видимо, у нас разная выборка проблем. Стандарты, методики, терминология – это всё полезная информация. А вот ситуация, что в часы не вкладывают тестирование, это факт, который практически никак не подвержен изменениям под влиянием вышеуказанных знаний. Расшифрую: вы сколько угодно долго можете убеждать программиста пилящего обработку для инфостарта (выражения взято из ваших роликов) что тестирование – это эффективно, и ему воздастся за это, но в тоже самое время, утверждаете, что время потраченное на разработку теста – не показатель. Я против той точки зрения, что 1с-программисты такие вот «тёмные» люди, стандартов не читавшие, а вот если прочтут, то спустится на них озарение.
И совершенно неважно, как вы называете руководителя тестирования, QA-инженером или еще как-то, но если инструментарий не позволяет делать работу эффективно, все остальные процессы становятся неинтересными.
У вас есть много роликов и по часу, и по полтора. Если есть возможность сделать ролик на 40 минут, где в реальном времени создаётся указанный мной выше библиотечный тест – вы сделаете большой шаг навстречу обычному программисту.
P.S. Спасибо за мою положительную оценку. Компанию ТехноНиколь я не знаю.
Затем отправлять их на git.
Получать с git.
И загружать эти объекты в конфигурацию.
Это уже давно как реализовано.
Git и загрузка-выгрузка в файлы тут не при чем
То есть для ДД это можно, а для других объектов 1С это нельзя (в том числе и объектов ВК).
О замыканиях не просит только ленивый. Опять же в управляемых формах серверный и клиентский код можно писать в одном модуле. И это прекрасно, но еще было бы эффективнее вызывать серверный код в виде замыкания, где бы захватывались переменные метода. Это бы значительно сократило время написания.
значение=ВызватьСерверныйМетод({ код который выполняется на сервере})
Ну и про свои чаяния про .Net Core в 1С промолчу
Как и эти
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II
1С, Linux, Excel, Word, OpenXML, ADO, Net Core
Которые есть и на этой площадке Мои публикации
К моему огромному сожалению интеграция с .Net Core 1C не нужно. А вот например Samsung вполне использует Tizen C# API reference
На мой взгляд:
— % таких разработчиков невелик
— львиная доля 1С-разработчиков решает прикладные задачи клиентов с минимальной технической морокой. Собственно за это и спасибо 1С
«львиная доля 1С-разработчиков решает прикладные задачи клиентов с минимальной технической морокой.» имеется в виду очевидно минимальные задачки типа бухгалтеру отчетик налабать видимо… Это да… Никаких проблем и git с тестами не нужен. Но там кто-то (не 1С ли) решил с SAP конкурировать. Хотя может только по размерам бюджетов и сопутствующим им вещам :-)
Хотя, по-хорошему, это тема для отдельной большой статьи.
Как мне кажется, вопрос развития (а значит усложнения) средств разработки — это еще и вопрос экономики. Сейчас порог вхождения в мир «программирования на 1С» довольно низок. Есть куча стажеров/студентов/фрилансеров, которые поддерживают чьи-то базы на минимальном техническом уровне (обработку написать, реквизит добавить и т.д.). Это не хорошо и не плохо, это просто как есть, такова потребность рынка и 1С с партнерами ее удовлетворяет.
Усложнение средств разработки, усложнение языка и т.д. может привести к повышению порога вхождения, что в конечном итоге приведет к тому, что в профессии будут оставаться только люди более высокого уровня, а время на подготовку таких специалистов вырастет. В конечном итоге это приведет к удорожанию стоимости (а рынок 1С-ников и так подогрет не слабо) таких специалистов и сокращению их численности.
А этого 1С, подозреваю, допускать не хотела бы. Не говоря уж о бизнесе.
Понимаю, что это лишь один из возможных сценариев, но он кажется мне правдоподобным.
С другой стороны, я помню баттхерт от введения управляемых форм и как долго люди привыкали к ним. Думаю, введение существенных изменений в средства разработки 1С будет не болезненнее, чем переход на УФ,
До сих пор в эксплуатации огромное количество автоматизированных систем, созданных на предыдущей версии 1С — на v7, которая появилась еще в конце прошлого века.
Бизнесу (клиентам 1С) нужно решение проблем, а не модные фичи ради фич.
Проблема решается? Ну и зачем тогда тратить огромные деньги все переписывая.
Фичи языков не нужны в 1С.
Потому что то, что в других языках программисты решают самостоятельным написание кучи кода — в 1С решает платформа. И программисту остается просто выбрать нужную фичу (объект) для решения проблемы и чуть-чуть ее кастомизировать.
А не писать с нуля как это принято в других языках.
В 1С 7.7 ой как не хватало множественных табличных частей и до сих пор это тормозит достаточно сильно, хотя это можно реализовать на других объектах. И это не модная фича ради фичи, которая появилась в 8.х
Все почти так, но очень часто возникают проблемы и иного рода, если бы был инструмент, то можно было бы их решить без «костылей» в виде внешних компонент и каких-то скриптов на питоне.
У 1С узкоспециализированный язык (и узкоспециализированный runtime и система объектов/классов), предназначенный для решения вполне конкретных задач.
Замечу — для весьма быстрого решения.
Никакие там «современные мощные языки» и рядом не лежали по скорости разработке в той сфере, для которой 1С и предназначена.
А для нестандартных вещей — есть COM-объекты, технологии внешних компонент и web-сервисов и пр. Да в конце концов есть HTTP. Вы можете написать сторонний софт и общаться с ним по REST API.
https://habrahabr.ru/company/1c/blog/308420/
Миллионами методов 1С сие умеет.
По приведенной ссылке — баг, исправим.
Но проблема, вообще-то, не в информации на сайте, а в том, что внедренцы предлагают именно УПП — возможно потому, что ERP они не знают в достаточной степени, ну и потому что ERP заметно дороже.
Более того, при правильной настройке PostgreSQL под железо сервера, на 2 предприятиях тест Гилева выполняется быстрее, чем в MS SQL (на том же железе!)
По приведенной ссылке имеется фактологическая ошибка.
Ваше утверждение о том, что 1С: Предприятие не поддерживает работу с PostgreSQL — это только ваше утверждение. Почему мифические внедренцы предлагают УПП и MS SQL — это отдельный вопрос. Радикально простой ответ на этот вопрос звучит так: эти внедренцы ничего другого не знают. Подозреваю, что мир не монохромен, и правильный ответ не так радикален.
Предлагается все-таки не разбрасываться абстрактными утверждениями (их много и у вас и у меня), а быть несколько более конструктивными. Если есть проблемы с PostgreSQL — пишите в поддержку: эти ошибки будут анализироваться и исправляться.
Представители 1С иногда заявляют публично, что Линукс не интересует клиентов, процент внедрений на нем очень мал. Да потому и мал, что внедренцы отказываются ставить на него 1С. По некомпетентности ли, или из-за реальных проблем — вам лучше судить.
Представители 1С иногда заявляют публично, что Линукс не интересует клиентов, процент внедрений на нем очень мал
И прямо есть ссылки на такие заявления представителей 1С?
Да потому и мал, что внедренцы отказываются ставить на него 1С.
Да вроде не отказываются. Судя по партнерскому форуму — Линукс используется достаточно часто.
УПП сейчас нами особо не развивается, его сменил ERP.
Ну а по части «сыроватости» — пользователями 1С:ERP стали более 1300 компаний, продукт вполне зрелый.
А так уже лет 8 занимаюсь допиливанием УПП для нужд различных производств (от упаковки кофе до совхозов, молокозаводов и т.д.) и не скажу, что она тоже не была сыроватой… Так и помрет…
2) Есть ли смысл такой миграции? Какие преимущества?
3) Когда планируете завершить жизненный цикл и поддержку УПП 1.3?
Заранее спасибо за ответы.
1) Насколько реально мигрировать с УПП 1.3 на ERP 2.0 с переносом всех данных?
Обычно мигрируют, перенося не всю информацию, а остатки и нормативно-справочную информацию. В составе 1С:ERP есть инструменты для переноса. Вот здесь есть информация по этому поводу, см. доклады с мероприятия «Телеконференция „Новые возможности для бизнеса — переход с 1С: УПП на 1С:ERP“»
2) Есть ли смысл такой миграции? Какие преимущества?
УПП больше не развивается, делаются только изменения для поддержки текущего законодательства и исправление найденных ошибок.
3) Когда планируете завершить жизненный цикл и поддержку УПП 1.3?
Официального решения пока нет, но предупредим за 3 года о снятии с поддержки.
Одна из групп задач для команды разработки веб-клиента – это дальнейшее развитие функциональности. Функциональность веб-клиента должна быть идентична функциональности тонкого клиента
А можно по подробней (может не понял из статьи?), о текущих отличиях функциональности тонкого клиента и веб-клиента?
И тогда полностью отвязываемся от дизайна 1С.
И немного оффтопик: какие планы насчет ПолеHTMLДокумента под Linuх? А под Windows — IE на все времена?
одинесники очередной раз рассказывают, как ониИсточник: Кто на Хабре не забанен, спросите у 1С – когда они выкинут IE из платформы?летают в космоспилят тонких и веб-клиентов, с последующим их тестированием.
Пока они там еще теплые, спросите их – сколько они еще собираются жевать говно мамонтаиспользовать ИЕ в ПолеHTMLДокумента?
Почему нельзя было пойти по стопам SAP DYNPRO и реализовать внутри конфигуратора возможность наклепать собственных форм на java/javacript? Или почему нельзя пойти по стопам собственных разработчиков мобильной платформы, которые сначала тоже решили сделать десктопную копию интерфейса, а потом поняли, что облажались и реализовали отдельный интерфейс по мобильным стандартам?
Во-вторых, некоторые десктопные решения просто-таки на ура воспринялись незнакомой с 1С публикой. В частности, вкладочный интерфейс страницы.
В-третьих, это все-таки не сайт. Чтобы сделать публичный сайт, придется выдать немереную сумму денег за одни только лицензии. А вот в качестве личного кабинета партнера — очень даже подходит.
Перед тем как делать «универсальный интерфейс» для браузера и для полноценного клиента — 1С реализовала специальный webоподобный интерфейс на десктопе.
Старый, классический десктопный — тоже остался доступен (не для веба, разумеется).
Они добровольно отказываются от своей силы, от специализации на вполне конкретных прикладных вещах, где программисты могли бы много времени экономить.
В 1С все сделано правильно. Несколько секунд — и у вас есть и структура БД, и формы для записи-чтения работают автоматически.
А вообще, хорошей практикой считается именно отключение автозаполнения для кнопочек, а произвольная иерархия — это проблема выбранного вами архитектурного решения, тут стоит подумать о другой реализации.
Управляемая форма представляет из себя xml файлик с описанием. И он либо составляется платформой автоматически, либо по тому конструктору, в котором все переопределено вами. Поведение исполнения программы не зависит от описания того как расположены кнопочки на форме. Потому не понимаю почему это может «тормозить» да еще и «естественно». И, заметьте, ни одной строчки кода)
А тут все просто, требуется в этих формах давать выбор иерархии, возможность перемещения, удаления и прочих стандартных команд, но поведение так просто не переопределить… В общем это вылилось в несколько тысяч строк кода формы, и еще пару десятков тысяч строк в общих модулях (ну там еще специфичный функционал правда дополнительно реализован) Это в дополнение к тому что чатсть приходится дублировать в другие формы где требуется работа с этими иерархиями.
Но тем не менее каждый при своем мнении останется, редко когда кто то кого то переубеждает в спорах в интернете. Вы, как я понимаю, так и продолжите стоять на том что язык следует максимально упрощать, я по прежнему буду считать что возможность создавать объекты например как это реализовано в js (ни разу не писал на нем, но на википедии примеры посмотрел), возможность использовать функции первого класса, замыкания (для обработки оповещения и перехода на сервер например) и тому подобные вещи только добавят удобства и больше возможностей по написанию хорошо структурированного и лаконичного кода.
Управляемая форма представляет из себя xml файлик с описанием. И он либо составляется платформой автоматически, либо по тому конструктору, в котором все переопределено вами. Поведение исполнения программы не зависит от описания того как расположены кнопочки на форме. Потому не понимаю почему это может «тормозить» да еще и «естественно». И, заметьте, ни одной строчки кода)
Уделите еще внимание оптимизации работы с БД, создание кучи временных таблиц, на каждый чих обращение к БД. Научитесь кешировать запросы, и использовать хранимые процедуры и все возможности современных серверов БД. Реализовать это не так трудно было бы желание.
Вообще если брать конфигурацию под вашу систему и под веб приложение выполняющее те же задачи, то можно сильно удивиться, что приложение написанное под веб работает быстрей и на меньших ресурсах. Поэтому иногда проще либо написать самому либо взять готовую ERP систему или CRM систему написанную на PHP, PYTHON.
Единственный неоспоримый плюс вашей системы это система отчетов. Это так на вскидку.
А еще ваша система не умеет HTTP2.0, SFTP, Network Share и тд…
У меня складывается мнение, что вы живете в каменном веке, и реализовываете свой беклог по задачам 15 летней давности.
Но нужно и похвалить специалистов: в новых релизах то, что некрасиво выглядит в конфигураторе, тонком и толстом клиентах под Linux, нормально отображается в web-клиенте.
Также интересно, почему отказались от поддержки на тонком клиенте таблицы значений и дерева значений? Выход конечно есть — массив со структурами, но все-таки почему?
Если написать по технологии Native API, то будет работать и там.
Старые компоненты писанные на технологии СОМ в линухах работать естественно не будут. Новый писанные с помощью Native API будут. Не вижу обмана, это прописано в документации к платформе.
Не знаю о каких внешних компонентах вы ведете речь, а имею ввиду вот это: Глава 34. Внешние компоненты
Я понимаю, что это был 2006 год. Но сейчас вроде
Asm.js стал ещё быстрее
Например, после компиляции кода C++ в Asm.js с помощью компилятора Emscripten раньше потеря производительности была примерно двукратной, теперь же код Asm.js медленнее нативной программы не более чем в полтора раза.
Про веб-клиент 1С