Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>> Похоже, что ты третьего не видишь, не говоря про всю палитру. Наивное предположение, что у всех одна и та же цель — стать богатым. Это только твое видение. G>>Да ты дяденька демагог. Сам поставил вопрос "за деньги и быстро" vs "ты в всегда прав". А теперь хочешь в этом меня обвинить.
I> Ну и директор. Учу читать бесплатно: I>"за деньги и быстро" — твой подход, ты сам про это пишешь I>"клиент в всегда прав" — снова твой подход, ты сам это пишешь.
Ты сам для начала читать научись.
Я не писал что клиент всегда прав. Это ты сам придумал.
I>Вот и выходит у тебя, раз клиент прав, то ты — нет
Не значит. У тебя с логикой проблемы.
I>Потому как ты сам перед собой ставишь ненужный выбор.
Выбор ты придумал.
Я тебе только сказал что лучше быстро, чем медленно, и что лучше быть богатым, чем правым. Последнее — не моя фраза, подслушал у кого-то. Остальное — твоя демагогия.
I>>>Что касается меня, то я хочу быть самим собой и обязательно счастливым. А правым или богатым — вообще дело десятое. Если самим собой и счастливым, то я бедным спокойно проживу G>>Еще один демагогический прием, ты конкретные понятия в обсуждении попытался заменить абстрактными. I>"правым или богатым" это по твоему конкретные понятия ?
По крайней мере формализуемые. В отличие от "быть собой" и "счастливым".
G>>Давай вернемся к конкретике — при прочих равных что выберешь: Остаться правым или получит деньги? G>>Сумма значительная. Оставшись правым ты никого ущерба не несешь. I>Я выберу быть самим собой и счастливым. Из твоей "конкретики" ничего не ясно.
Здравствуйте, TimurSPB, Вы писали:
TSP>>>Эм.. а что тогда такое файлы вида "app.7fddae04c636d3fa8754.js vendor.8d5d0c6d54afadb626e6.js ". Ну ок, два куска кода. F>>Байт-код F>>Ну реально, если разрабатываешь с webpack, то модули — это там где ты код пишешь. А объединенный-минимизированный результирующий выходной файл — это суть скомпилированное приложение. Которое скармливается браузеру, а как оно там внутри выглядит, уже не важно, руками его не правят же. TSP>Есть байт-код, есть нативный машинный код, и есть JS. Это всё разные вещи. И каждый слой должен оправдывать своё существование.
Тебе никто ничего не должен.
TSP>В случае JS оправдание — не развитый язык и компенсация его кривой поддержки браузерами.
Язык очень даже развитый, но поддержка браузерами хромает.
TSP>Нормально это Java, ну или хотя бы .NET. А это всё шляпа.
На техническом форуме увидеть аргумент "это все шляпа" — бесценно.
Помоему ты уже добрался до границы своей компетентности, почитай книжки, расширяй границы.
Здравствуйте, Serginio1, Вы писали:
S> Ну если ты используешь BynaryWriter то да. А побольшому счету Stream сам должен иметь эти методы или их добавлять через Extension.
Та ну, райтеров слишком много. Binary, String/Text, Xml, Json и миллион других райтеров под конкретные задачи.
S>Например BynaryWriter закрывает поток. А например мне это не надо. Мне нужно просто записать в поток (NetStream) но его не закрывать для последующего чтения.
Это косяк самого BinaryWriter — для системной библиотеки как оказалось этот вопрос весьма важен, хотя и обходился раньше через заворачивание потока в другой объект. Но ошибки так или иначе учтены: BinaryWriter(Stream output, Encoding encoding, bool leaveOpen).
S> Угу. Вручную release вызывал? Ну проще GC с определенной переодичностью вызывать А то release будет больше чем сам код
Думаю всё упирается в объем кода. У меня не много было и он был полностью локализован, поэтому это не было проблемой.
Здравствуйте, Serginio1, Вы писали:
F>>Короче, что бы вернуться к конструктиву — можно пример на пальцах, если я вдруг пропустил — зачем именно тебе нужны финализаторы в JS? S>http://rsdn.org/forum/flame.comp/6726048.1
S> У меня из JS создаются на стороне .Net объекты, которые сохраняются в хранилище List и на сторону JS возвращается индекс в этом хранилище. S> На стороне JS эта ссылка может храниться сколь угодно долго. По этой ссылке вызываются методы, передаются в параметрах. S> Но после окончания работы с ней нужно эту ссылку освободить, для сборки мусора. S> Приходится это делать вручную. Но иногда бывает, что долгоживущих ссылок может быть много, а вручную муторно освобождать.
Т.е. тебе нужен финализатор в JS, для того что бы .NET-ый объект мог быть собран сборщиком мусора.
Разрешить проблему можно:
0. Не лениться и печатать releaseObject. Сделать хелперы которые будут бить по рукам, если где-то забыли.
1. Разобраться как используется v8::Persistent::WeakHandle. Разобраться — мешает ли что-то это использовать в CEF. Раньше на слабых ссылках жило кое-что. Проблема в том — что это всё очень не бесплатно, и вдобавок никаких гарантий когда оно будет вызвано и будет ли оно вызвано — нет. С практической точки зрения для той эпохи одно-процессного CEF1 — это означало неминуемый путь к перерасходу памяти и только потом попытка высвобождения ресурсов. Пользователи жалуются => программисты пишут так, что бы мусор не копился. Если пошаманить они будут вызываться, они вызываются — в node.js — активно используются. Просто скажем для моего хоста — политика такая, что на рендерер не более 300-500Мб. На кой хрен вообще плодить мусор, который не нужен в принципе (уничтожается детерминированно) => не выходим за рамки 100Мб ни при каких обстоятельствах. Даже если оно будет идельно работать как ты хочешь — общий эффект от этого будет минимален, и потраченных усилий — стоить не будет. Теоретически и сейчас CefV8Handler должны уничтожаться (деструктор вызываться) автоматически при сборке мусора. Можно проверить — забайндить к окну объект, а затем его занулить и дёрнуть сборку мусора раза 3 кажется.
2. Если код с интеропом локализован, — реализовать что-то подобное:
AutoReleaseScope(function() {
// Все прокси созданные в этом методе - будут закрыты при выходе из него.
// Все колбэки идут лесом, так что надо быть крайне осторожным.
});
Разумеется такое решение скорее всего довольно легко поломать.
3. Почти как (2) но с явным scope:
var scope = new LifeTimeScope("myScope");
var context = BrowsingContext.NewWithScope(config, scope);
// ...
// ...
scope.Dispose(); // высвободили все объекты созданные в этом скоупе
// любая прокси возвращенная методома "context" - автоматически должны попадать в его же scope
4. Перестать маршалить объекты by reference. Все нативные объекты-сервисы — предоставляются платформой с которыми общаешься клиентский код. Т.е. оставить .NET объекты там где им и место, а из JS звать методы которые делают какую-то работу. Принимают запрос и получают ответ. Т.е. никаких проперти-аксессов через 5 слоёв маршаллинга. Тогда и скорость вызова перестанет быть важна. Но тогда и веб-сокеты/XHR станут применимы.
5. Дождаться... очередной версии ES в которой догадаются сделать WeakMapWithWeakValueButNotKey в котором weak ссылка будет не в ключе, а в value — тогда примитивный чистильщик пишется достаточно просто, хотя это и не будет честными финализаторами (кооперативность потребуется, но это ведь не проблема). К сожалению на сегодня есть только WeakMap и она к твоему случаю абсолютно не подходит, т.к. key — weak, увы.
Здравствуйте, Ikemefula, Вы писали:
I>Ога. Он генерит кучу дерьма только из за того, что в джаве совсем другая система типов. При чем здесь JS ?
Давай примеры.
I>Я тебе страшное скажу — джава на винде сосёт именно по этой же причине. Джава может внятно работать только внутри своей собственной VM. Именно поэтому и возникают проблемы с gwt.
Я тебе ещё более страшное скажу: ты несёшь чушь.
I>>>Скажем, ASM x86 был еще более убог и крив. Первые двадцать лет отладчики регулярно вывалились в этот самый ASM. И ничего. Языки, которые не научились внятно транслироваться в этот asm, сдохли. S>>Кривая аналогия: есть ARM, MIPS, PowerPC и прочее, есть NET, Java, Lisp, JavaScript (eye roll) и куча других виртуальных машин. I>На x86 остались только те, которые на ней внятно заработали. И ровно то же с остальными платформами. Не язык диктует условия, а платформа.
Я вижу что вы старайтесь сформулировать какую-то мысль, но у вас не очень получается. Попробуйте ещё раз.
S>>Так я о том же: javascript говно, и говно безалтернативное. I>Родовые травмы никого не интересуют. Все академически выведеные, вывереные языки нигде никогда не приживались. Вся история ЯП — приживаются уродцы. I>Важны не те грабли ,что тебя смущают, а возможности которые представляет JS.
Прямо секта какая-то.
I>Программирование на любом языке это прежде всего идиомы. И в каждом языке начинаются проблемы, если ты пробуешь писать без этих идиом.
Вы сейчас цитируете стандартный мануал евангелиста javascript "Ой, это не язык говно, это вы не так его используйте".
I>В каждом.
Не спорю, просто мне не нравятся идиомы, направленные на говнокодинг. Ergo — мне не нравится js (и php заодно).
Здравствуйте, turbocode, Вы писали:
T>На что то более вменяемое типа C# с хорошей стандартной библиотекой? Сколько можно тянуть этот JS легаси из 90-х годов?
Надо думать шире. Зачем вообще возиться с этим вебом? Нужны абсолютно новые открытые протоколы — для общения устройств, программ, пользователей между собой через Интернет. Как Битторрент, например. Уходить надо от гипертекста, JS сам потом отвалится.
Гипертекст сейчас нужен только конторам, которые хотят быть везде где есть пользователи — Гугл, Фейсбук. Подмять под себя всё, забрать всех в свои сети, заведовать всем рынком рекламы.
Здравствуйте, gandjustas, Вы писали:
G>>>Я не одной из презентаций качал чисто js приложение (node+клиент) и за 10 минут превращал его в типизрованное на TS без единого any. Ф>>И что это показывает? О чём это говорит? G>Это опровергает мнение что "И более-менее хорошо работает лишь с тем кодом, который изначально писался с прицелом на TS".
Пф-ф..
Ни разу не опровергает. Отчасти даже подтверждает.
Вы предлагаете рефакторить весь код перед началом работы?
G>То есть код из JS в TS можно превратить в 100-1000 раз быстрее, чем код был написан.
Эм-м.. 10 минут * 1000 = 10000 минут = ~167 часов.
Написание 400 строк кода на JS занимает до 167 часов? o_O А что за код там?
Кстати, как? Есть какой-нибудь простой способ прикрутить TypeScript к Angular 1.x? А то наши UI-девелоперы не знают, как это сделать. Ковыряются с голым JS на Angular.
В общем — если ты будешь возвращать JS объект с приатачченым CefV8Handler — то "слушай" когда будет вызван деструктор.
Проверить это недолго. Может тебе и подойдет такое.
Здравствуйте, gandjustas, Вы писали:
TSP>>Я вот представляю себе вариант, когда C++14 конвертируется в С++98, потом компилируется... Ну жесть же. G>Там же все еще интереснее происходит, с учетом препроцессора, obj файлов, линкера и преображования в машинный код. G>Как ты с этим живешь?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Ops, Вы писали:
G>>>А ты думал что разработка JS до сих пор ведется в блокноте? И ничем тут мегабайтные скрипты? Как они связаны с arrow functions или модулями? Ops>>При том, что это один из способов фактической реализации модульности — свалить все нужное и ненужное в один файл. Или поприседать с require.js и аналогами. Вот вам и import.
I>"приседать" уже давно не нужно. И сваливать всё в один файл тоже не нужно.
Ну как это не нужно? Вот люди на npm жалуются, в мавене оно поумнее сделано. И паковать таки надо, ну — не руками, естессно, можно считать это статистической линковкой.
Здравствуйте, Somescout, Вы писали:
I>>Ога. Он генерит кучу дерьма только из за того, что в джаве совсем другая система типов. При чем здесь JS ? S>Давай примеры.
Чем представлен number в JS и во что gwt компилит, например, лонги ?
I>>Программирование на любом языке это прежде всего идиомы. И в каждом языке начинаются проблемы, если ты пробуешь писать без этих идиом. S>Вы сейчас цитируете стандартный мануал евангелиста javascript "Ой, это не язык говно, это вы не так его используйте".
Так с каждым языком. Если ты на Джаве начнешь писать как на плюсах, язык покажется очень кривым.
I>>В каждом. S>Не спорю, просто мне не нравятся идиомы, направленные на говнокодинг. Ergo — мне не нравится js (и php заодно).
Не совсем понятно что ты имеешь ввиду. Есть какой нибудь релевантный пример ?
Здравствуйте, gandjustas, Вы писали:
I>> Ну и директор. Учу читать бесплатно: I>>"за деньги и быстро" — твой подход, ты сам про это пишешь I>>"клиент в всегда прав" — снова твой подход, ты сам это пишешь. G>Ты сам для начала читать научись. G>Я не писал что клиент всегда прав. Это ты сам придумал.
Писал, только не в этом топике.
G>Выбор ты придумал. G>Я тебе только сказал что лучше быстро, чем медленно, и что лучше быть богатым, чем правым. Последнее — не моя фраза, подслушал у кого-то.
Это и есть выбор. Подслушал ты или нет, дело десятое. Ты ему следуешь, по твоим же словам.
G>>>Еще один демагогический прием, ты конкретные понятия в обсуждении попытался заменить абстрактными. I>>"правым или богатым" это по твоему конкретные понятия ? G>По крайней мере формализуемые. В отличие от "быть собой" и "счастливым".
Ты уже в который раз отказываешься от своих слов и задним числом корректируешь смысл.
Здравствуйте, gandjustas, Вы писали:
TSP>>Плюс побочный проектик, где нужен фронтенд и там во весь рост JS. Как с этим жить? В одну руку берешь костыль VueJS, в другую jQuery и потихоничку ковыляешь в волшебный мир web 2.0. G>Ты удивишься, но из 5 последних проектов jquery был только в одном.
А что вы вообще используете для JS? Какой у вас путь от написания кода на js/ts до выкладывания собранного на staging?
Здравствуйте, TimurSPB, Вы писали:
TSP>В самом языке буст ничего не затыкает. Он его расширяет и многое потом отправляется в стандарт. А вот, например, $scope в angular это типичный пример костыля, который требуется понимать и правильно использовать.
Разумеется. Во первых, $scope это про первый Ангуляр, который уже устарел. Во вторых, точно так же в любом фремворке на любом язые надо понимать синтаксис и правильно использовать его фичи.
G>>Ну также в JS. Все давно забили на то, что на выходе. Проблема только в отношении. У многих в голове сидит паттерн "js — плохо, а <подставить любимый язык> — хорошо". TSP>Большинство забили. Но не думаю, что на больших проектах удасться полностью абстрагироваться от выхлопа этих всех богомерзких тулов.
Именно в больших как раз все просто. В больших всего будет намешано, не меньше чем в джавовских монстро-проектах. Тулом больше, тулом меньше — никакой разницы. А вот на мелких проектах, которые пишутся в текстовом редакторе, проблема есть, но и она решается — генераторы проектов давно уже не новость.
G>>Ты удивишься, но из 5 последних проектов jquery был только в одном. TSP>Точно нет jquery? Покажи папку node_modules.
jquery уже давно optional. Последние года 4 стандартом стал Angular.
Здравствуйте, Слава, Вы писали:
Ops>>>При том, что это один из способов фактической реализации модульности — свалить все нужное и ненужное в один файл. Или поприседать с require.js и аналогами. Вот вам и import.
I>>"приседать" уже давно не нужно. И сваливать всё в один файл тоже не нужно.
С>Ну как это не нужно? Вот люди на npm жалуются, в мавене оно поумнее сделано. И паковать таки надо, ну — не руками, естессно, можно считать это статистической линковкой.
20% указывает на то, что проекты однодневки или даже короче.
Здравствуйте, fddima, Вы писали:
F> 4. Перестать маршалить объекты by reference. Все нативные объекты-сервисы — предоставляются платформой с которыми общаешься клиентский код. Т.е. оставить .NET объекты там где им и место, а из JS звать методы которые делают какую-то работу. Принимают запрос и получают ответ. Т.е. никаких проперти-аксессов через 5 слоёв маршаллинга. Тогда и скорость вызова перестанет быть важна. Но тогда и веб-сокеты/XHR станут применимы.
Сейчас хочу дописать на аналог WСF. Там немного. Просто устанавливается основным класс с нужной функциональностью, а все объекты сериализуются через Json. Там немного. Зато безопасно. Но опять же, кому это надо?
F> 5. Дождаться... очередной версии ES в которой догадаются сделать WeakMapWithWeakValueButNotKey в котором weak ссылка будет не в ключе, а в value — тогда примитивный чистильщик пишется достаточно просто, хотя это и не будет честными финализаторами (кооперативность потребуется, но это ведь не проблема). К сожалению на сегодня есть только WeakMap и она к твоему случаю абсолютно не подходит, т.к. key — weak, увы.
Ну моя разработка никого не заинтересовала. Так, что ...
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
F>> 4. Перестать маршалить объекты by reference. Все нативные объекты-сервисы — предоставляются платформой с которыми общаешься клиентский код. Т.е. оставить .NET объекты там где им и место, а из JS звать методы которые делают какую-то работу. Принимают запрос и получают ответ. Т.е. никаких проперти-аксессов через 5 слоёв маршаллинга. Тогда и скорость вызова перестанет быть важна. Но тогда и веб-сокеты/XHR станут применимы. S> Сейчас хочу дописать на аналог WСF. Там немного. Просто устанавливается основным класс с нужной функциональностью, а все объекты сериализуются через Json. Там немного. Зато безопасно. Но опять же, кому это надо?
Откуда же я знаю. У CEF — специфичная аудитория. Большая половина колбасит на плюсах ad-hoc, т.к. встроенного message router им хватает. Остальным подавай готовый WPF/WinForms контрол и всё, CefSharp это закрывает, и простой js binding там был отродясь почти (сейчас не знаю остался ли). CefGlue и ChromiumFX — это биндинги для людей которые знают что и зачем делают и не чураются C++. Я лично WCF при возможности обходжу стороной. Поэтому — я х.з. кому это надо.
Вот если бы ты вместо CEF подставил Electron — массы возможно бы были и более благосклонны особенно на хабре — но по сути — одна холера, и ниша такая же узкая. OmniSharp — он интегрирован везде. Как именно — я не смотрел. Но, я не думаю, что они протаскивают произвольные прокси как ты. Хотя кто их знает...
F>> 5. Дождаться... очередной версии ES в которой догадаются сделать WeakMapWithWeakValueButNotKey в котором weak ссылка будет не в ключе, а в value — тогда примитивный чистильщик пишется достаточно просто, хотя это и не будет честными финализаторами (кооперативность потребуется, но это ведь не проблема). К сожалению на сегодня есть только WeakMap и она к твоему случаю абсолютно не подходит, т.к. key — weak, увы. S> Ну моя разработка никого не заинтересовала. Так, что ...
Не заинтересовала — потому, что это вообще очень специфичная и узкая ниша. Если взять простой случай, когда речь идёт о том, что бы сделать веб-приложение полунативным — то разумеется веб-приложение должно работать по стандартам, т.е. опираться на web-sockets и XHR, а не самописные расширения — так проще и писать веб-девелопером, и на веб-сервере можно набросать какую-то эмуляцию любого нативного функционала опять же для веб-девелоперов. А со своими расширениями — нужно уже заниматься этим на целевой платформе. А люди эти — совершенно не веб-девелоперы. Да и даже не смотря на то, что в CEF всё есть что бы легко и просто показать DevTools — это всё равно нужно где-то костылять в коде.
Я приводил в пример сам DevTools? Он работает через стандартные web-sockets. Однако настоящие веб-сокеты используются для удалённой отладки, а in-browser devtools — использует встроенный транспорт и никакого tcp нет.
Тем не менее — расширения иногда нужны и без них не деться. Но это опять таки — весьма специфичный софт.
Вeсь этот диснейленд, который ты описал в wasm, был много лет назад уже проделан с Явой, но оно не взлетело. Чисто с практической точки зрения, wasm по сравнению с JVM хуже всем (sandboxing, payload size, tooling, libs), кроме возможно скорости. Однако смотря на Minecraft, сдается мне, что скорость для всего, что вообще имеет смысл запустить в браузера с песочницей, может быть вполне себе приемлема.
Убило jvm кроме политики именно то, что нельзя было манипулировать DOM-ом напрямую, а только как в wasm через js. Вопрос почему мне до сиз пор не ясен, но то, что очевидно тут "все не просто" настораживает.
ИМХО, вопрос интеграции с объектами браузера абсолютно ключевой. Программировать клиентов на C++ мало кто будет, то есть для реальной смерти JS нужно еще перенести туда как минимум что-то легкое типа Питона/Руби и прокинуть в него DOM-байндинги. Это не говоря о Яве и .NET. Это все годы, если не пятилетки работы.
Здравствуйте, turbocode, Вы писали: T>На что то более вменяемое типа C# с хорошей стандартной библиотекой? Сколько можно тянуть этот JS легаси из 90-х годов?
сам ты legacy
похоже нечего теперь уже менять, google v8 достаточно быстр и масштабируем,
и он теперь везде, даже в hana cloud
год назад пробовал писать под web на haskell, конкретно на spock (scotty),
тогда всё было в каком-то зачаточном состоянии, маршрутизация на type families,
всё на трансформерах и плохо документировано, в попытке разробраться
неделю разгребал исходники до глубоко закопанного wai,
обнаружил, что оказывается ghc с 2010г пипец как сильно поменялся,
на теорию ушло много времени, а потом и вовсе забросил из-за основной работы
а вот недавно начал искать на чём щас модно писать ..
короче говоря этапы отрицания и смирения уже пройдены.
в сухом остатке — docker, nodejs (typescript), loopback.io, vuejs, webpack
Похоже, что ты третьего не видишь, не говоря про всю палитру. Наивное предположение, что у всех одна и та же цель — стать богатым. Это только твое видение. 
