• UI движок Sciter идет в Open Source — кампания на Kickstarter
    +1
    Я в это не верю.


    Ну вера это дело такое конечно.

    Так-то Sciter он есть, и пробовать его никая религия не запрещает.
    Писал я его сам.

    Начинался Sciter еще в EverNote когда мы делали идею Стёпы Пачикова. Это вот вся EverNote команда в 2002-2003 году:

    image

  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    Давай исходники уже


    Где? Не вижу…
  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    Погоди, но так мы сравниваем слона с мухой.


    Сравнивать можно. И webkit парсит HTML и показывает его с CSS.
    Также и Sciter, парсит HTML и показывает его с CSS. В своей версии и только те СSS фичи что для UI нужны.
    Например эта вот дискуссия:
    image
    Видно что что-то в CSS не поддерживается, тем не менее содержимое ты видишь.

    Фенечка в том что я могу Sciter доделать до уровня WebKit, но WebKit до уровня Sciter не дотянется никогда по многим причинам.
  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    мы рвём всех

    rendering speed (в два раза примерно), loading times (раз в 5-10), memory consumption (в 3-6 раз), какие-то функции вообще не сравнимы — нет аналогов в WebKit — не с чем сравнивать.
  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    В части desktop UI касающейся Sciter (H-SMILE core) лучше чем WebKit.
    Например отрендерить DOM элемент в popup окне:
    image
    WebKit не умеет в принципе. Или вот HTML в круглом окне:
    image
    WebKit тоже не умеет.

    Но части поддержки Web standards WebKit лучше. Просто в Sciter какие-то механизмы сделаны истоически по другому, например flexbox: terrainformatica.com/w3/flex-layout/flex-vs-flexbox.htm

    Все базовые конструкции HTML5 в Sciter имплементированы. Я кстати участвовал в разработке HTML5 в W3C как invited expert.

    А вообще осталось всего три движка которые умеют HTML/CSS более менее полно: WebKit, Gecko и h-smile core (движок Sciter)
  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    Ты спросил про бенчмарки.

    Бенчмарк это измерение какой-то конкретной функциональности, какой в данном контексте?

    Производительность UI это комплексная метрика.

    Скажем VSCode (сделан на ElectronJS) при старте запускает как минимум 4 процесса (даже не потока). Один исполняет HTML/CSS/JS, второй рендерит на экран + RPC между этим всем. Понятно что single process Sublime Text будет быстрее. И это так и есть.

    То же самое и с Sciter который делает всё то же что и ElectronJS только в 10 раз меньше. Какие-то операции тоже в разы быстрее — рисование в DirectX напрямую в Sciter например.

  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    уж сильно выборочно вы отвечаете на вопросы.


    Да вроде на все вопросы ответил. Или нет?

    автор хочет сделать нормальных JS, для закрытого проекта


    Не делаю я JS. В смысле вообще. Я сделал Sciter Script для Sciter — он жил, живет и будет жить в Sciter Engine. В Sciter.JS будет использоваться стандарный JS с плюшками ( например native JSX как во взрослом Sciter и т.д. )
  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    Почему не взять QuickJS?


    Потому что script там примерно 15% объема — остальное custom HTML/CSS rendering engine c DirectX, OpenGL, Vulkan graphic backends.

    Sciter это HTML/CSS/tiscript — desktop UI engine.
    Sciter.JS HTML/CSS/javascript — desktop UI engine — ElectronJS replacement, только в 10 меньше и для все платформ WinLinMac+Mobiles.

    В качестве JavaScript могут использоваться в Sciter.JS как QuickJS++ (с моими патчами) так и V8.

    озвученных денег, по моему опыту, не хватит ни на что.


    Это так. Но есть еще сущесвующие customers как я уже сказал которые платят за подписку.
  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    Парни, нужны деньги, оказалось, что бизнес на этом движке UI не нужен особо никому.


    Далеко от реальной ситуации. Вот актуальные customers которые используют Sciter: sciter.com/#customers
  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    Бенчмарки где?


    Бенчмарки чего именно? Не ясно.

    Ну вот скажем есть Sublime, а есть VSCode. Какие бенчмарки будут?

  • UI движок Sciter идет в Open Source — кампания на Kickstarter
    0
    Почему трижды?

    Sciter.JS планируется как BSD. Денег с BSD я не ожидаю. Вообще donation ware на таких проектах не работает.

    kickstarter campaign, он на разработку именно Sciter.JS. Там нужны будут люди — как минимум еще два разработчика.
    На сам Sciter денег лично мне вполне себе хватает от коммерческих пользователей. Открытие исходников самого Sciter это просто доп. мотивация для тех кому именно оно надо.

  • Разрабатываем свой браузер с нуля. Часть первая: HTML
    0
    Вы читали спецификацию HTML?


    Более того, я (в том числе) её писал. Как Invited Expert @ W3C HTML5 WG и WHATWG.

    Ты наверное не понял что я имею ввиду. Скажем у тебя есть HTML в кодировке UTF-8 на входе. Т.е. 50% твоего текста это ASCII. Зачем эти 50% вообще куда-то конвертировать?

    Тебе нужно конвертировать содержимое text nodes. И некоторых атрибутов. И только. Зачем дурную работу делать?

    А код я привел выше. Еще раз: www.codeproject.com/Articles/14076/Fast-and-Compact-HTML-XML-Scanner-Tokenizer

  • Разрабатываем свой браузер с нуля. Часть первая: HTML
    0
    токенизатор принимает на вход юникод символы


    А зачем всё переводить в Unicode?

    50% (условно) в HTML именно markup. Зачем эти 50% через конвертор-то гонять?

    Как-то это не согласуется с заявленной целью «самый быстрый HTML-парсер c DOM.»

  • Разрабатываем свой браузер с нуля. Часть первая: HTML
    0
    «но данный проект именно на Си.»

    Не ясна модель встраивания в другие языки. Поэтому и вопросы.
    Если бы ты (можно без «вы»?) определил изначально периметр встраивания (API другими словами) то было бы наверное более понятно что оно такое будет.

    Скажем весь Sciter API это вот эта структура github.com/c-smile/sciter-sdk/blob/master/include/sciter-x-api.h — там реально 40 функций (DOM related).
    Это чистые C functions хотя написаны на C++. И то на чем они написаны вообще никого не волнует. И не должно. Далеко не все «структуры» вообще могут быть выставлены наружу. Это банально опасно. Только контролируемый периметр.

    «есть чёткое понимание как всё делать»

    У меня было это состояние лет так 14 назад. И более того был реальный опыт создания WYSIWYG редакторов что близко к HTML (и там и там DOM, parsing и всё такое). Реальность как всегда оказалась несколько далека от изначальной теории.

    Как я понимаю до слов harfbuzz (и вообще RTL), writing script itemizer and shaper, и прочая ты еще не добрался. (сужу по описанной структуре parser. Кому нужны эти «Character token» и что это вообще?)

    «я вообще ещё не говорил о рисовалке.» и "… дерева отрисовки. Все расчеты, перерасчёты и так далее."

    Ну да, теоретически ты можешь рассчитать положение примитивных прямоугольных блоков, но для glyph positioning придется учитывать такие вещи как ClearType и другие механизмы которые доступны на конкретных платформах и которые являются частью rendering механизма. Это суровая практика, сиречь необходимость. Без понятия архитектуры rendering с самого начала и как те glyphs оказываются в GPU памяти что-то практическое сделать невозможно.

    И еще, я ни в коем случае не хочу тут рисовать картину маслом «Умерщвление прекрасной гипотезы мерзким фактом». Можно написать HTML/CSS/script engine и одному, собственно sciter есть тому подтверждение. Но нужно изначально определить «а user кто?». Для чего это всё? Т.е. почему проект который сейчас использует WebKit или Sciter должен перейти на твой движок?

    Если это для того чтобы сделать что-то типа HTML-to-PDF утилиты, то это одно. Для UI же… С его анимациями и рисованием на 4K мониторе full screen и c 60 FPS это совсем другое — как минимум layout engine должен взаимодействовать с rendering engine чтобы получать вектора glyphs и прочая. DrawText примитивы уже не работают на таких потоках данных и скоростях.

    И еще по поводу языка. Sciter написан на «C c классами» по большому счету. Ибо это удобно — т.е. позволяет быстрее и что главное надежнее писать. (Sciter примерно 100 тыс LOC). Это всё важно для one-man-project. А Mozilla вообще пилит Rust для того чтобы писать Servo — ручное управление памятью для проектов такого масштаба даже для них оказалось суровой задачей.

    И по поводу Open Source. Не советую обольщаться на эту тему.
    Есть два типа проектов: небольшие утилиты и что-то типа Electron. Первые имеют смысл для Open Source. Вторые же… Ну вот реально никого не парит что там внутри — реально количество людей которые лезут в детали WebKit или Gecko исчисляется десятками на всём шарике. И вот собственно и вся аудитория для open-sourse-ности проектов такого уровня. Тем более в свете последних скандалов с NPM ( в Microsoft Visual Code пролезла закладка которая тырит Bitcoins ) народ оченно печально настроен.

    То что мы видим в OpenSource это верхушка айсберга. Реально же 90% софта это проекты по месту — внутренних IT отделов компаний. Да и те же китайцы. Любят они OpenSource. Но вот не знаю ни одного OS проекта финансируемого ими. Нет таких. Не потому что они такие-сякие, а потому что через их firewall такие платежи не сделать. Да и вообще поток статей типа FOSS is free as in toilet в последнее время оптимизма никак не внушает.

  • Разрабатываем свой браузер с нуля. Часть первая: HTML
    0
    Вот это вот парсер www.codeproject.com/Articles/14076/Fast-and-Compact-HTML-XML-Scanner-Tokenizer используется в моем Sciter (https://sciter.com). По тестам на то время это был самый быстрый вариант.

    Из отличительных черт — не аллоцирует память в процессе работы. В смысле вообще. Классический finite state automata — pull parser.
  • Разрабатываем свой браузер с нуля. Часть первая: HTML
    0
    «Они» это я лично, т.е. без ансамбля.

    История создания Sciter: sciter.com/10-years-road-to-sciter

    «обрезанную версию движка для интерфейсов»

    Не сказал бы что обрезанная ибо HTML5 и CSS3 (избранные модули) поддерживаются практически в полном объеме.

    Вот «полноценный движок на Си» сделать действительно крайне сложно. С это не тот язык на котором такие вещи удобно писать.

    И желание «встраивать в любой язык программирования» тоже вызывает вопросы.
    Сейчас Sciter встраиваем в C/C++, C#, Rust, Python и Go. и написан на C++. Embedding API тот, да, plain C ибо другой альтернативы нет.

    Но на самом деле встраивание в язык это дело десятое. Вот встраивание в существующие десктоп системы и графику это важно.

    Сейчас Sciter может работать на Windows (XP … 10) c Direct2D/DirectWrite (DirectX), Skia (OpenGL) и GDI+ (прости мя сирого, хоспидя). На Mac — CoreGraphics и OpenGL(Skia), Linux/GTK (cairo или Skia). На подходе Andorid (OpenGL) и iOS (CoreGraphics или OpenGL).

    Skia и Direct2D это C++ и только. Ибо Skia можно интегрировать только в исходниках а это С++. А Direct2D это IUnknown со товарищи, т.е. C++ опять же.

    Без Skia и Direct2D (т.е. hardware acceleration) делать rendering engine можно и не начинать. 4K мониторы это наше все теперь. А на них только H/W acceleration — других опций и нет.

  • Скажи «нет» Electron! Пишем быстрое десктопное приложение на JavaFX
    0
    Да, вот было бы интересно увидеть приложение аналогичное Sciter Notes на JavaFX:
    image
    У меня это заняло два месяца этим летом.

  • Visual Studio Code отнимает 13% ресурсов CPU из-за мерцания курсора
    0
    Именно процессов, cм: https://github.com/Microsoft/vscode/issues/5856
  • Visual Studio Code отнимает 13% ресурсов CPU из-за мерцания курсора
    +3
    Они меряли на MacOS а там Activity Monitor сообщает загрузку одного ядра. Т.е. процесс в AM может показывать и 200% если два ядра занимает.

    Т.е. если привести это число к методике Windows (100% — загрузка всех ядер) то будет 1.5-3% что в общем согласуется с реальными цифрами.

    Вот цифры на W10:

    image

    (там правда VS Code создает 6 процессов на это бедное окно, показан только rendering process)

    Вот для сравнения Sciter c тем же Skia backend который использует Электрон.

    Используется аналогичная по сложности структура экрана — редактор с подсветкой.

    image

    И для сравнения тот-же Sciter но c Direct2D backend:

    image
  • Важные аспекты работы браузера для разработчиков. Часть 1
    0
    Вот это «А display:inline указывает, что ширина прямоугольника...» смысла не имеет. У display:inline нет прямоугольника (border box в технических терминах). Элемент с display:inline содержащий текст это коллекция отдельных glyph boxes.
  • Важные аспекты работы браузера для разработчиков. Часть 1
    0
    Скажем есть такой markup:

    <div>Привет Вася</div> 
    


    Этот div не содержит блочных элементов поэтому он будет представлен как TextBlockCntr ( или TextBlockRenderer ):

    <TextBlockCntr> 
       Привет Вася
    </TextBlockCntr>
    
    


    А вот этот markup

    <div>
           Привет Вася
            <p>Ты крут!</p>
    </div> 
    


    будет нормализован в rendering tree как

    <VerticalFlowBlockCntr>
      <TextBlockCntr>Привет Вася</TextBlockCntr>
      <TextBlockCntr>Ты крут!</TextBlockCntr>
    </VerticalFlowBlockCntr>
    


    Где первый TextBlockCntr выше это т.н. anonymous paragraph
  • Важные аспекты работы браузера для разработчиков. Часть 1
    +1
    Надо отметить что иметь отдельное RenderingTree совсем не обязательно.

    В Sciter например DOM element содержит как список DOM nodes так и layout controller — список дочерних объектов для размещения и отображения. У параграфа свой text layout controller, а у div, который содержит блочные элементы, — block vertical layout controller. У таблиц — свой и т.д. Такая архитектура более компактна помимо всего прочего.
  • Что браузеры делают с вашим JavaScript-кодом: об оптимизациях в JS-движках на примере V8
    0
    Про Python и его производительность.

    Когда кто-то реально упирается в его производительность то пишут native extension. NumPy как пример.
    То же происходит и в JS когда он работает в среде node.js. В обоих случаях есть относительно простой механизм встраивания native code.

    Собственно я про это и говорю. Ну не надо писать ray tracers в JS. Гораздо продуктивнее было бы иметь возможность встраивания чего-то что лучше ложится на регистры и архитектуру CPU.

  • Что браузеры делают с вашим JavaScript-кодом: об оптимизациях в JS-движках на примере V8
    0
    В JS скорость парсинга одинаково важна как и скорость исполнения. Скорость eval() опять же. Т.е. баланс — должной оптимизации и скорости сборки того же C или C++ не добиться — дорого во всех смыслах.

    По идее JS в UI это клей связывающий выход одной native функции со входом другой. Т.е. в принципе JS это язык описания event routing / dispatching. Смысла JITить какой-нибудь click event handler немного если он срабатывает ровно один раз за время жизни страницы. А вот парсить их надо быстро.

    Понятно что в условиях browser sandbox JS это единственная опция написать какой-нибудь ray tracer. Но вот эта единственность и есть основная проблема.

    Представляется что гораздо эффективнее было бы иметь тот же embedded С например или вообще абстрактную bytecode VM типа JavaVM которую можно кормить compiled bytecodes + удобный interop из JS с этим хозяйством.

    Т.е. путь того же Python — простой bytecode interpreter + удобная возможность встраивания native (или тех же bytecodes близких к native) для функций которым нужен CPU на 100%.

    Как-то такое решение представляется более грамотным с инженерной точки зрения.

    А так… создавать чисто интерпретирумый язык по своей изначальной природе, а потом героически преодолевать его интерпретирумость…
  • Что браузеры делают с вашим JavaScript-кодом: об оптимизациях в JS-движках на примере V8
    0
    А какой смысл в таких глубоких оптимизациях в JS? Ну понятно что какие-нибудь базовые и дешевые jump-to-jump или peephole делать можно и должно, но трансляция JS в native code представляется overkill. Вычиcлительная модель и типы данных как-то совсем далеки от модели и типов native code.

    Не знаю как кому, но мне вот представляется что гораздо продуктивнее было бы иметь возможность сделать что-то типа inline C или Dart islands в JS:

    "C" int ray_tracer(int a) {
    ... C code, compiled into native assembly ...
    }
    // normal JS
    var r = ray_tracer(42);


    Как-то представляется что это позволит получить более предсказуемые результаты. И уж точно исполняться будет эффективнее.

    Да и сократить размер всего этого хозяйства опять же. А то вот получается что весь мой Sciter который есть фактически встраиваемый browser включающий JS superset по размеру меньше чем одна V8.dll ( sciter32.dll — 3.7mb, V8.dll — 4.7mb ).

  • Да, я пишу десктопные приложения под Windows
    0
    Для желающих биндинга есть +plus модуль

      <ol each="item in items|filter">
          <li class="{{done:item.done}}"><input|checkbox(item.done)/> {{item.subject}}</li>
      </ol>
    

    Это live data binding в стиле AngularJS.

    Но всякий автоматический binding имеет свою цену: далеко не всё укладывается в простой attribute-property binding, хорошо если 90% процентов того что нужно можно забиндить декларативно. Зато имплементауия остальных 10% как раз и занимает 90% отведенного времени. Так на так и приходится.

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

    Написать это вот явным образом
    prop1: this.attributes["prop1"],
    

    иногда в разы полезнее чем потом рабираться «где оно тормозит?».
  • Да, я пишу десктопные приложения под Windows
    0
    При чём здесь Visual Studio и ASP.NET MVC?
  • Да, я пишу десктопные приложения под Windows
    0
    Если «метод» это native backend function ( скажем «backendMethod1» ) то например так:

    include "decorators.tis";
    
    class MyUserControl : Behavior {
      function attached() {
         this.html = "<input.name/><button.add-name/>";
      }
    
      @click @on "button.add-name" 
           function() {
              var json = {
                 prop1: this.attributes["prop1"],
                 prop2: this.attributes["prop2"],
                 newName: this.select("input.name").value
              };
              view.backendMethod1( json ); // calling native method registered in view.
           }
    }
    


    Здесь используются декораторы.

    То же можно описать и в классическом JS/jQuery стиле (в Sciter многое из jQuery имплементирвано нативно)

      function attached() {
         this.html = "<input.name/><button.add-name/>";
         this.on("click","button.add-name", this.onAddNameClick);
      }
      function onAddNameClick() {...}
    
    


  • Да, я пишу десктопные приложения под Windows
    0
    А в Sciter содержимое видно в DOM inspector. Если учесть что перезагрузка UI (если нужно показать изменения) это просто F5
    то разницы между design time и run time я не вижу. На поддержку design-time тратится достаточно много ресурсов. В production этот весь код поддержки design-time редактирования не нужен, но он там есть зачем-то.

    image
  • Да, я пишу десктопные приложения под Windows
    +1
    Как-то мало кто обращает внимание на то что мы тихой сапой (кто такая эта «сапа» я не знаю ) все вместе перебрались в эру AppStores.

    AppStore это a) one click installation of native app и b) well known place to get it.

    Т.е. если раньше говорилось что мы делаем web app потому как не требует инсталляци, то сейчас дело доходит до совсем странного: на одном из проектов начальство попросило обернуть web app в PhoneGap (т.е. сделать из него как бы native) чтобы его можно было выложить в AppStore.

    При этом куча времени убилась на то чтобы обойти ограничения web app и его sandbox модель.
  • Да, я пишу десктопные приложения под Windows
    0
    Вопрос про то что есть MVC сугубо религиозный. Model в смысле UI это несколько иное чем data layer data model.
    Я считаю что loosely coupled UI и business logic есть хорошо. У каждого layer своя собственная data model.
    И общение между ними ограничено фактически get/set запросами.

    Во всяком случае код приложения (его core logic) не должен быть приколочен гвоздями к UI.

    Вот приложение которое уже практически 10 лет живет с htmlayout/sciter UI:
    sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-application
    за это время они практически только UI и меняют. CSS и script, ну там animation модно стало по другому делать и пр.

  • Да, я пишу десктопные приложения под Windows
    +1
    Ну тут кому как удобно. Если instances user-control будет много то

    <user-control id="n1" />
    ...
    <user-control id="n2" />
    
    


    А в Behavior.attached() делаем DOM population:

    class MyUserControl : Behavior {
      function attached() {
         this.html = "<input.name/><button.add-name/>";
      }
      function onMouse(evt) {...}
      function onKey(evt) {...}
    }
    
  • Да, я пишу десктопные приложения под Windows
    0
    Я не понимаю смысла фразы «Очень не нативно» в контексте .NET и WPF.

    В sciter есть samples/+plus/ модуль. Это duplex data binding в стиле AngularJS и прочих MVC. С templates, repeatable и прочими фишками. Основан на Object.observer(function).

    script в иделогии sciter это такой-же способ описания стиля как и CSS. script описывает behavioral style, а CSS rendering style. В это этом случае язык самого приложения выполняет то для чего он предназначен лучше всего — [business] локику приложения.

  • Да, я пишу десктопные приложения под Windows
    0
    Это да, толковый binding для .NET, еще предстоит написать.
  • Да, я пишу десктопные приложения под Windows
    0
    <user-control>
      ...
    </user-control>
    


    А в CSS сказать
    user-control {
      behavior: MyUserControl;
      ...
    }
    


    И если это С++, то в нем описать

    class MyUserControl : public event_handler {... }
    


    В .NET примерно так же (при наличии толкового binding).

    В script то же пишется как

    class MyUserControl : Behavior {
      function attached() {...}
      function detached() {...}
    }
    


  • Да, я пишу десктопные приложения под Windows
    0
    Да я как бы ни слова про язык code-behind-ui не сказал. Это может быть всё что угодно. В случае Sciter это tiscript, С++, D, Go, Delphi и все языки .NET.

    До мощности CSS XAMLу далеко. А markup он должен быть больше semantic. XAML попытался в одном флаконе объединить и то и то, но в результате толком ничего не получилось. ИМХО, ИМХО и еще ра ИМХО.

    Кстати если есть желание можем посотрудничать.
  • Да, я пишу десктопные приложения под Windows
    0
    А зачем WPF? Если понятно что XAML проигрывает (ну или как минимум не лучше) HTML/CSS связки. Cascading в CSS опять же…

    Я вот тут недавно сравнивал Sciter и WPF так как они сделаны для одного и того же — declarative desktop UI platforms.
  • Зачем нужен свободный код и как на нем зарабатывать
    +10
    «Начиная с 2013 года по текущий момент пользователями Linux Mint пожертвовано более $230k.»

    $230k это зарплата двух разработчиков на один год. Это без операционных расходов, лоеров, налогов и всего прочего.
    Это ничто для проекта уровня Mint. Либо им кто-то подкидывает денег (и что-то за это хочет и получает) либо они живут в долг и ждут что их кто-то купит.

    Пожертвования НЕ работают. от слова вообще.
  • Зачем нужен свободный код и как на нем зарабатывать
    +3
    C Rust, и с языками прогрммирования в частности, ситуация совсем иная. Там Open Source это фактически единственная модель в которой что-то еще возможно сделать в наше время.

    И кстати Rust как это ни странно есть способ борьбы с OpenSource. Вернее с последствиями OpenSource модели разработки Mozilla «когда любой залетевший дятел с горяшими глазами и патчами рушит цивилизацию» Мерфи. Сложная и не всегда понятная политика владения объектами в таком сложном проекте привела к куче проболем с memory management у них.

    Отсюда и растут ноги именно такой архитектуры Rust, который собственно и есть язык на котором он собираются переписывать движок.
    Решение спорное в смысле экономической целесообразности. Не ну если конечно Rust делать коммунистически-бесплатным образом — всем миром, всем народом. Да и то… без жесткой модерации нифига не выйдет.
  • Зачем нужен свободный код и как на нем зарабатывать
    +6
    Plug-ins это совершенно иная тема. И ортогональная открытости и закрытости базового продукта. У Visual Studio плагинов всяко больше visualstudiogallery.msdn.microsoft.com