RUVDS.com corporate blog
Website development
JavaScript
Client optimization
Comments 25
+5
Еще бы TypeScript в браузеры имплементировали, в чем сложность, два движка осталось всего.
+2
Cчастье, когда строгий компилятор находит ошибки за тебя, особенно если ты поправил декларацию в одном месте, а при сборке он проверил 10 тысяч строк кода, и нашел несоответствие где-то далеко, о чем уже и не вспомнишь.
+7
при сборке он проверил

Так вы же сами и написали. Typescript нужен при сборке. В браузере-то он зачем?
+2
Отладка например, скорость загрузки, интеграция с другими языками. По сути движок все-равно компилирует в момент открытия страницы, зачем нам лишняя прослойка, пусть сразу из тайпскрипта в байткод компилирует. Тут Rust ругают, что он компилирует в LLVM, хотя это глазу никак незаметно, а в JS-это уже весьма заметно. Тому же wasm-у проще линковаться с типизированным интерфейсом, чем с нетипизированным, и так далее.
+1
Почти всё вышеперечисленное как раз таки лучше делать в AOT режиме, а не в браузере у клиента. Для отладки есть source-map, которые также просто позволяют дебажить исходники на ts. Соглашусь только с аргументом про
По сути движок все-равно компилирует в момент открытия страницы, зачем нам лишняя прослойка

при условии, что речь о компиляции в обычный js. Если со временем это всё переползет на компиляцию в wasm, то опять таки это надо делать в AOT, а не у клиента.
интеграция с другими языками

Тут не понял о чём речь.
0
Если со временем это всё переползет на компиляцию в wasm, то опять таки это надо делать в AOT, а не у клиента.

А перегнать TypeScript в WASM — это хотя бы в теории вообще реально? Пусть даже и с ограничениями типа "никаких any и никаких X as unknown as Y"...

0

Спасибо! Как я и предполагал, компилируется довольно жёстко ограниченное подмножество, но то, что его удаётся чётко очертить, — уже приятный сюрприз. Буду изучать.

0
Возможно Вы и правы насчет AOT, а про другие языки — модули wasm можно писать и на других языках, и в идеале желателен мэппинг параметров, а когда на стороне JS один тип «объект» — привет тестирование в рантайме.
+1
V8 при оптимизации тратит довольно много ресурсов на попытку понять, с каким объектом он имеет дело. Если бы информация о типах объекта передавалась сразу в движок — движок мог бы потратить эти ресурсы на что-то другое. Ну или стал бы работать быстрее, потому что часть работы бы отпала

0

Дык тут wasm надо тащить, Имхо. А то о чем вы пишете это просто колоссальная переработка движка, как мне видится. Смысла нет, тем более, что wasm уже есть, хоть и тулы для него (TS — >wasm) в зачатке только.

0
wasm спроектирован так, что он может только дополнить JavaScript — обращаться к API и DOM все равно приходится через Javascript-вызовы.

Посему непонятно, как вы видите решение «тащить wasm». Далеко его не протащищь, это хороший инструмент для оптимизации абстрактных (не привязанных к конкретному API) вычислений. Для работы ему нужен JavaScript
0
V8 во многом занимается тем, что дженериковые словарики типизирует в рантайме и оптимизирует вызовы функций. И да, wasm фактически работает через js (что вроде как не обязательно, но на текущий момент только так), но если для исполнения wasm кода ему в чем-то не хватает типизации, то лучше её вносить в сам wasm (через аннотации и т. п., примерно как в IL .Net например), а не тащить в браузер ещё один высокоуровневый язык, вместо унификации единого формата исполняемого кода. Всё имхо, конечно. Под wasm не кодил, не могу сказать является ли подобное для него принципиальным ограничением, но, думаю, что нет.
+2
Но как обычно, ни одна из тенденций так и не способствует TDD. И не надо пытаться убеждать в том, что есть и другие решения. Меня очень сильно не устраивают инструменты, которые говорят «У тебя ошибка», а уж где, будь добра найти сам.
+8

Как же надоели такие статьи, сил нет.


Если бы автор реально пытался анализировать тренды, то хотя бы воспользовался существующими исследованиями:



И вот на основе их понял, какую поверхностную лажу он написал.
Сорян, за такие слова, но сколько можно-то?!

0

Никак не хочу комментировать текст самой статьи. Но вот такие безапелляционные сообщения мне всегда "нравилилсь". Благо недостатка в них нет и даже наоборот.
Посмотрел по первой ссылке. Не вижу, где предположения автора противоречат результатам даже таких, косвенно относящихся к "прогнозированию будущего", исследований.

+3

Безапелляционные? Ну вроде я вроде приложил ссылки, но и без ссылок видно, что расклад сил уже давно устаканился и изменения нужно искать не в веб компонентах, ui либах и тем более инструментах для дизайнера, но если вам это не очевидно, могу развернуть:


Custom Elements. Уже давно не будущее, но за все года они показали крайне мало пригодным. Обычно их выбирают огромные копрорации (ибо стандарт, да и гугл за спиной), но из реальных, крупных решений вышел, наверно только Youtube и текущая ситуация с ним очень показательна.


Кроме этого, использовать их себе дороже, а профит сомнительный, проблема шаринга высосана из пальца, мы уже лет 5+ живем в эру компонентов (до которой были jquery plugins/widgets на любой вкус), поэтому проблема найти для того же React, Angular, Vue готовый, качественный компонент, просто нет, любые серьезные либы имеют биндинг под каждую из них.


Проблема как раз в таких решениях как Lit-html, StencilJS или SvelteJS (который не понятно как попал в этот список, ведь совсем не про CE). Можно было рассчитывать, что эти решения займут нишу для построения виджетов, но практика показывает, что проще сделать на чистом JS с литеральными шаблонами, или собрать из готовых React компонентов, заменить React.createElement на h, чтобы сжималось лучше, в финале выкинуть React, добавив Preact и готово.


Фреймворки. И тут как обычно видим React, хотя FW на фронте, которые ещё живы, это Ember, Angular и Vue (Aurelia может). React только либо, а дальше во круг неё люди стоят бог знает что, сам Реакт никакой официальной архитектуры не предлагает, только тонкие намёки… хотя вру, с появлением useReducer, намёки становиться более прямыми, думаю весь 2019 год мы будем наблюдать, как люди обмазываются хуками изобретаю чудных монстров типа Flux, а дальше очередной «Дэн» нам покажет, как можно «проще», вот так и наступит 2020.


GraphQL. Опять же, какое это будущее? Он есть, он работает и уже давно, кто хотел, то уже использует, но если мы говорим про реальные highload проекты, то там как был RPC/REST, то так и останется, т.к. особой проблемы при их использовании нет.


Ну и так далее, такое ощущение, что автора нам пишет из 2016-2017, всё что он написал подходит к любому этому году.


Тредны на 2020 будут достаточно простыми, ситуация мало чем изменятся, проблем с компонентами и их стилизацией нет уже сейчас, максимум можно чего ожидать, это новые версии популярных компонент, типа Ant.Design, Material Design и т.п.


Главным будет конечно WASM, но скорей главным он будет к концу 2019, пока на фоне люди будут выяснять, как же лучше использовать хуки в React ;]


Ещё ещё один важный тренд и ниспадающий, это безопасность и тут конечно WebAuthn.


Да, и если говорить про дизайн и разработку, то тут нас ждет больше Grid'ов и конечно типографики.


Ну и так далее и тому подобное.

-1
расклад сил уже давно устаканился
Отличный комментарий вы написали! Браво!

Статья эта по сути выражается в двух словах — "Я вижу что React впереди, но, ребята, есть же ещё куча «шавок» бегущих за ним и чихающих в его пыли..."

весь 2019 год мы будем наблюдать, как люди обмазываются хуками
Верно. Хуки это тренд 2019 года.


очередной «Дэн» нам покажет, как можно «проще», вот так и наступит 2020.
Вангую — Дэн будет тот же!


0
Спасибо за ссылки, познавательно. Однако это немного не то, о чем пишет автор. Статья у автора в основном аналитическая, в ней приводятся рассуждения. А по ссылкам собрана статистика с последующим анализом. У каждого подхода есть сильные и слабые стороны. У «статистики» слабая сторона — невозможность «заглянуть» в будущее, потому что у него нет никакой статистики. Например, специально искал информацию про веб-компоненты, но там об этом ни слова.
+1
основном аналитическая, в ней приводятся рассуждения

А на основе чего автор проводится анализ? Просто на основе своих фантазий или он всё же опирается на статистику и тренды? Если просто фантазии, то какой это "анализ"?

+1
Интересный анализ, в глаза бросилось ES6 vs TypeScript.
Кол-во тех кто то попробовал TypeScript и больше бы его не использовали, более чем в 9 раз выше относительно, чем у ES6.
Т.е. большой антирейтинг у TS, что вы об этом думуаете?
0

Мне кажется проблема в сообществе, низкий порог входа, поэтому у людей нет нормального бекграунда и для них все эти «типа» сложны, непонятно и просто излишни. Кроме этого, огромная проблема с самими инструментами, они не TS-friendly, что Vue, что React (особенно с Redux) в них TS смориться инородно и монструозно.


Увы, люди не видят полной картины, что TS, кроме проверки типов, даёт супер крутой autocomplete, изумительно удобный рефакторинг, а ещё если вникнуть в Transformer API, то инструмент раскроет себя во всей красе.

0

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

+3

Sketch, Apollo, Bit.dev… я надеюсь в будущем фронт разработки не будет миллион инструментов, делающих какую-то магию под капотом

Only those users with full accounts are able to leave comments. , please.