AF
Последствияшейминг? 😂
Ну вот и Adobe наконец начала WebAssembly и PWA юзать)
https://twitter.com/ireaderinokun/status/1336739477616807937
Size: a a a
2020 December 09
2020 December 10
M
SR
Ну вот и Adobe наконец начала WebAssembly и PWA юзать)
https://twitter.com/ireaderinokun/status/1336739477616807937
https://twitter.com/ireaderinokun/status/1336739477616807937
давно уже. вот еще с февраля статья, например
https://medium.com/adobetech/acrobat-on-the-web-powered-by-webassembly-782385e4947e
https://medium.com/adobetech/acrobat-on-the-web-powered-by-webassembly-782385e4947e
К
N
Ну все, фронты могут прыгать на плюсы или Раст:)
М?
Рисование на канвасе или вебассембли встречаются так редко, что за последние 5 лет я встречал дважды
Рисование на канвасе или вебассембли встречаются так редко, что за последние 5 лет я встречал дважды
M
М?
Рисование на канвасе или вебассембли встречаются так редко, что за последние 5 лет я встречал дважды
Рисование на канвасе или вебассембли встречаются так редко, что за последние 5 лет я встречал дважды
Это вообще не задача WebAssembly. Рисовать лучше на хосте, что собственно в основном и делают.
Имелось ввиду видвимо, что все должны переползти на Yew (Rust), Blazor (C#) и Vecty (Go). Но это вряд ли будет, так как выгоды вообще не вижу пока что. А вот какие нибудь ресурсоемкие алгоритмы могут перебраться, но обвернутые в js они ни чем не отличаются от обычного JS с точки зрения интеграции.
Да и возмождность символьной отладка это далеко не решающий фактор. Как я уже говорил самая важные фичи для фронтенда это:
- hot reloading и быстрая компиляция
- безшовная интеграция с Web API
- быстрое и легкое изучения фреймворка / тулкита
- отладка и полный стек трейс при runtime ошибки (частично сделано с DWARF секциями в V8)
- размер бинарника должен быть сопоставим или меньше чем у аналогичных JS фреймворков
Пока не ни одного фреймворка удовлетворяющего всем этим требованиям
Имелось ввиду видвимо, что все должны переползти на Yew (Rust), Blazor (C#) и Vecty (Go). Но это вряд ли будет, так как выгоды вообще не вижу пока что. А вот какие нибудь ресурсоемкие алгоритмы могут перебраться, но обвернутые в js они ни чем не отличаются от обычного JS с точки зрения интеграции.
Да и возмождность символьной отладка это далеко не решающий фактор. Как я уже говорил самая важные фичи для фронтенда это:
- hot reloading и быстрая компиляция
- безшовная интеграция с Web API
- быстрое и легкое изучения фреймворка / тулкита
- отладка и полный стек трейс при runtime ошибки (частично сделано с DWARF секциями в V8)
- размер бинарника должен быть сопоставим или меньше чем у аналогичных JS фреймворков
Пока не ни одного фреймворка удовлетворяющего всем этим требованиям
N
Это вообще не задача WebAssembly. Рисовать лучше на хосте, что собственно в основном и делают.
Имелось ввиду видвимо, что все должны переползти на Yew (Rust), Blazor (C#) и Vecty (Go). Но это вряд ли будет, так как выгоды вообще не вижу пока что. А вот какие нибудь ресурсоемкие алгоритмы могут перебраться, но обвернутые в js они ни чем не отличаются от обычного JS с точки зрения интеграции.
Да и возмождность символьной отладка это далеко не решающий фактор. Как я уже говорил самая важные фичи для фронтенда это:
- hot reloading и быстрая компиляция
- безшовная интеграция с Web API
- быстрое и легкое изучения фреймворка / тулкита
- отладка и полный стек трейс при runtime ошибки (частично сделано с DWARF секциями в V8)
- размер бинарника должен быть сопоставим или меньше чем у аналогичных JS фреймворков
Пока не ни одного фреймворка удовлетворяющего всем этим требованиям
Имелось ввиду видвимо, что все должны переползти на Yew (Rust), Blazor (C#) и Vecty (Go). Но это вряд ли будет, так как выгоды вообще не вижу пока что. А вот какие нибудь ресурсоемкие алгоритмы могут перебраться, но обвернутые в js они ни чем не отличаются от обычного JS с точки зрения интеграции.
Да и возмождность символьной отладка это далеко не решающий фактор. Как я уже говорил самая важные фичи для фронтенда это:
- hot reloading и быстрая компиляция
- безшовная интеграция с Web API
- быстрое и легкое изучения фреймворка / тулкита
- отладка и полный стек трейс при runtime ошибки (частично сделано с DWARF секциями в V8)
- размер бинарника должен быть сопоставим или меньше чем у аналогичных JS фреймворков
Пока не ни одного фреймворка удовлетворяющего всем этим требованиям
Что там кстати по поводу доступа к веб апи из васм? Что-то ожидается? Я последние пол года не следил.
Какие-то прдвижки произошли? Или только через жс?
Какие-то прдвижки произошли? Или только через жс?
2020 December 11
M
M
Сразу перематывайте на минут 15 вперед
SR
не понятно, они обсуждают доклады с конфы?
M
не понятно, они обсуждают доклады с конфы?
Да
АД
Это вообще не задача WebAssembly. Рисовать лучше на хосте, что собственно в основном и делают.
Имелось ввиду видвимо, что все должны переползти на Yew (Rust), Blazor (C#) и Vecty (Go). Но это вряд ли будет, так как выгоды вообще не вижу пока что. А вот какие нибудь ресурсоемкие алгоритмы могут перебраться, но обвернутые в js они ни чем не отличаются от обычного JS с точки зрения интеграции.
Да и возмождность символьной отладка это далеко не решающий фактор. Как я уже говорил самая важные фичи для фронтенда это:
- hot reloading и быстрая компиляция
- безшовная интеграция с Web API
- быстрое и легкое изучения фреймворка / тулкита
- отладка и полный стек трейс при runtime ошибки (частично сделано с DWARF секциями в V8)
- размер бинарника должен быть сопоставим или меньше чем у аналогичных JS фреймворков
Пока не ни одного фреймворка удовлетворяющего всем этим требованиям
Имелось ввиду видвимо, что все должны переползти на Yew (Rust), Blazor (C#) и Vecty (Go). Но это вряд ли будет, так как выгоды вообще не вижу пока что. А вот какие нибудь ресурсоемкие алгоритмы могут перебраться, но обвернутые в js они ни чем не отличаются от обычного JS с точки зрения интеграции.
Да и возмождность символьной отладка это далеко не решающий фактор. Как я уже говорил самая важные фичи для фронтенда это:
- hot reloading и быстрая компиляция
- безшовная интеграция с Web API
- быстрое и легкое изучения фреймворка / тулкита
- отладка и полный стек трейс при runtime ошибки (частично сделано с DWARF секциями в V8)
- размер бинарника должен быть сопоставим или меньше чем у аналогичных JS фреймворков
Пока не ни одного фреймворка удовлетворяющего всем этим требованиям
Лично для меня главная фича WebAssembly это использование существующих C/С++ библиотек, в вебе. Я из скромной и узкой области программирования всякого для поддержки процесса производства компьютерной графики для кино, рекламы, анимации. В этой области написано очень много хорошего. В основном на c/c++. И возможность скомпилить openEXR (https://www.openexr.com/), Alembic (https://alembic.sqlalchemy.org/en/latest/), USD (https://graphics.pixar.com/usd/docs/index.html) в wasm и запустить в браузере просто открывает целый новый класс невозможных ранее инструментов и позволяет переосмыслить некоторые процессы.
К
Это вообще не задача WebAssembly. Рисовать лучше на хосте, что собственно в основном и делают.
Имелось ввиду видвимо, что все должны переползти на Yew (Rust), Blazor (C#) и Vecty (Go). Но это вряд ли будет, так как выгоды вообще не вижу пока что. А вот какие нибудь ресурсоемкие алгоритмы могут перебраться, но обвернутые в js они ни чем не отличаются от обычного JS с точки зрения интеграции.
Да и возмождность символьной отладка это далеко не решающий фактор. Как я уже говорил самая важные фичи для фронтенда это:
- hot reloading и быстрая компиляция
- безшовная интеграция с Web API
- быстрое и легкое изучения фреймворка / тулкита
- отладка и полный стек трейс при runtime ошибки (частично сделано с DWARF секциями в V8)
- размер бинарника должен быть сопоставим или меньше чем у аналогичных JS фреймворков
Пока не ни одного фреймворка удовлетворяющего всем этим требованиям
Имелось ввиду видвимо, что все должны переползти на Yew (Rust), Blazor (C#) и Vecty (Go). Но это вряд ли будет, так как выгоды вообще не вижу пока что. А вот какие нибудь ресурсоемкие алгоритмы могут перебраться, но обвернутые в js они ни чем не отличаются от обычного JS с точки зрения интеграции.
Да и возмождность символьной отладка это далеко не решающий фактор. Как я уже говорил самая важные фичи для фронтенда это:
- hot reloading и быстрая компиляция
- безшовная интеграция с Web API
- быстрое и легкое изучения фреймворка / тулкита
- отладка и полный стек трейс при runtime ошибки (частично сделано с DWARF секциями в V8)
- размер бинарника должен быть сопоставим или меньше чем у аналогичных JS фреймворков
Пока не ни одного фреймворка удовлетворяющего всем этим требованиям
Ну вот я только из-за нормального режима дебага и не особо глядел в него.
Я сильно любитель консоль и отладчик потыкать (я провожу в ней больше чем в редакторе), так как у меня основная задача - отлаживать и гарантировать правильность исполнения.
Мы вчера 3 часа отлаживали почему у нас из кеша вместо Bounds вылезает Sprite в рандомных случаях (там коллизия по uuid вылезла после рефакторинга).
Я сильно любитель консоль и отладчик потыкать (я провожу в ней больше чем в редакторе), так как у меня основная задача - отлаживать и гарантировать правильность исполнения.
Мы вчера 3 часа отлаживали почему у нас из кеша вместо Bounds вылезает Sprite в рандомных случаях (там коллизия по uuid вылезла после рефакторинга).
M
Ну вот я только из-за нормального режима дебага и не особо глядел в него.
Я сильно любитель консоль и отладчик потыкать (я провожу в ней больше чем в редакторе), так как у меня основная задача - отлаживать и гарантировать правильность исполнения.
Мы вчера 3 часа отлаживали почему у нас из кеша вместо Bounds вылезает Sprite в рандомных случаях (там коллизия по uuid вылезла после рефакторинга).
Я сильно любитель консоль и отладчик потыкать (я провожу в ней больше чем в редакторе), так как у меня основная задача - отлаживать и гарантировать правильность исполнения.
Мы вчера 3 часа отлаживали почему у нас из кеша вместо Bounds вылезает Sprite в рандомных случаях (там коллизия по uuid вылезла после рефакторинга).
С языками строгой типизацией + asserts и нормальным покрытием тестами и дебаггер практически не нужен. Я вообще не помню когда им пользовался
К
С языками строгой типизацией + asserts и нормальным покрытием тестами и дебаггер практически не нужен. Я вообще не помню когда им пользовался
пока не void*
M
пока не void*
А не нужно использовать языки где есть такое)
P🍣
Ну и наркомания. Я сейчас смотрю код на плюсах, где генерируется код с шаблонами на плюсах, которые в свою очередь генерируют код во время компиляции.
P🍣
Напоминает времена когда webgl писали без сборщиков.
std::ofstream renormFct;
renormFct.open("../Specs/specRenorm.h",ios::app);
renormFct << "template<>\n";
renormFct << "inline void fast_renorm2L<" << sX << "," << sR << ">(double *x){\n";
PP
Лично для меня главная фича WebAssembly это использование существующих C/С++ библиотек, в вебе. Я из скромной и узкой области программирования всякого для поддержки процесса производства компьютерной графики для кино, рекламы, анимации. В этой области написано очень много хорошего. В основном на c/c++. И возможность скомпилить openEXR (https://www.openexr.com/), Alembic (https://alembic.sqlalchemy.org/en/latest/), USD (https://graphics.pixar.com/usd/docs/index.html) в wasm и запустить в браузере просто открывает целый новый класс невозможных ранее инструментов и позволяет переосмыслить некоторые процессы.
@scuff_alexey что-то из этого уже компилируется? Можно где-то посмотреть примеры?