Можно конкретный пример бизнес-логики, которую сложнее реализовать на JS, чем на твоем любимом языке X?

Это не диалекты.

Большая часть списка (почти весь) — это инстоументы трансляции других самостоятельных языков в js.

Из списка активно использовался только кофе очень давно и сейчас TS, но это пересекающийся язык для статической типизации.

большая часть да, но есть занятные редкости

Никак не связаны

Друг, ну говорить о том что 10 лет назад js был не очень и поэтому сейчас на нем писать не надо — это бред) Уже столько новых спецификаций вышло

не так vue3 инициализируеться

import { createApp } from ‘vue’

https://vuejs.org/guide/components/registration.html#global-registration

Ну вышло пару релизов, не особо много, как не было полноценного ООП с множественным наследованием, интерфейсами ит.п., так и нет, как было тяжко тестировать JS так и осталось, как избегали клиенты SPA (потому-что «JS косячники») так и избегают — хотя теперь это уже странно, да

это ж официальная, чё она не подойти должна

Вы спецы, вас и спрашиваю

ги, спасибо

ООП в js очень спорная тема. Лично я считаю, что при всей гибкости использования функции в js пытаться выпердеть какое то недо-ооп это плохое решение. По поводу сложности тестирования, соответственно, не понял довода — объясни, в чем сложность тестирования js кода?

Не понятно, какое отношение множественное наследование и интерфейсы имеют с ООП.

С тестирование тоже не понятно, какие проблемы.

SPA — это не JS, это подход.

>как не было полноценного ООП с множественным наследованием

во-первых, JS — это не про ООП вообще, не нужно пытаться натянуть опыт с других языков на JS, это так не работает
во-вторых, JS прекрасно решает все задачи и без ООП в классическом понимании, а при желании можно повторить весь нужный функционал, тем более уже давно существует сахар над прототипами, который приближен к обычному ООП

>как и нет, как было тяжко тестировать JS так и осталось

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

>как избегали клиенты SPA

тут вообще непонятно, о чем ты

И слава богу что нет множественного наследования, зато есть миксины 🤡

1) Вот с этого пункта и тянутся все беды при реалзиации крупной бизнес-логики на JS, было бы логично многие штуки на фронте делать, но нет JS «не про ООП», поэтому будем просто отрисовывать страницы после бека, обидно, ООП сила, паттерны много чего дают
2) Вот мы и пришли к диалектам) ну да, существуют, в умелых руках полезная штука, но их существование и вскрывает проблемы ванили
3) Ну, тут уже не про меня, в среднем по больнице покрытие тестами низкое, отлаживать трудно, коллеги тоже жаловались, может я каких хороших практик не знаю по написанию тестов, поделитесь?!
4) Да это про личный опыт, тараканы конкретного клиента

В Js никто паттерны не использует или это эксклюзив только для тру ООП языков?

Ну конечно используют, чего только флакс стоит, но это труднее чем в тру ООП

1. Паттерны не только в ООП бывают. Если для вас ООП = классы, они и в js есть. Нет статической типизации.

2. Сахар над прототипами — это не диалект, это 7летний JS. Уже в школу пошли 🙂

Ванила — всё ещё не про язык, а про апи окружения

3. Расскажи про проблемы, можно будет обсуждать, как из решать 🙂
Инструментов много, решений много, интересных плюшек много

Да можно ругать js. И Vue можно. Сами поругать можем. Но надо за дело ругать)

Ассемблер вас не уважает )

Не шарю, так что даже ответить нечего)

позволяет, не люблю в нём JSX

Каждый инструмент хорош на своём месте, с ассемблером было время неплохо защиты с програмок выковыривал

>Вот с этого пункта и тянутся все беды при реалзиации крупной бизнес-логики на JS

можно конкретный пример бизнес-логики, которую сложнее реализовать на JS, чем на твоем любимом языке X?
или хотя бы опиши, в чем выражается эта сложность

>Вот мы и пришли к диалектам)

честно говоря, я до сих пор не могу понять, почему ты ссылаешься на какие-то абстрактные диалекты, мы выше обсудили, что 99% из этого уже давно не используется, сейчас есть JS и TS, все остальное — что-то очень экстраординарное и редкое

>в среднем по больнице покрытие тестами низкое

наверное, это не “в среднем по больнице”, а на основании твоего опыта, в противном случае я бы не отказался глянуть на статистику
но в целом, это не проблема языка, а проблема конкретных проектов, низкое покрытие может быть где угодно и на чем угодно

jsx — лучшее, что придумало человечество

Да вот тот же чат взять — тестов несколько строк, и там во многих либах https://github.com/antoine92190/vue-advanced-chat

так, а как это относится к JS?

то есть если бы там был не JS, а условный PS, то тестов бы прибавилось или..?

Ну во первых за то что требует необосновано мелко делить компоненты, во вторых за то что не HTML, на котором экономически целесообразней писать, т.к. верстальщики дешёвые и много чего готового

JSX не требует никак делить код на компоненты, это исключительно про подход, ты можешь хоть все приложение описать в App.tsx

Случайный репозиторий с небольшим количеством звёздочек и установок что-то говорят о языке?

нет но в библиотеках подобного размера на Python например покрытие будет в среднем сильно лучше

В смысле требует? Если больше 10 элементов суешь ошибку выдает или что?)

Про экономическую целесообразность орнул

есть подозрение, что ты сравниваешь теплое с мягким
разные языки, разные либы, разные авторы, разная цель

880 — небольшое количество? ну понятно там где десятки тысяч тесты будут, но вот как раз такие библиотеки средней популярности многое могут рассказать об удобстве тестирования

Экосистема у Пайтона, пакетный менеджер, документации либ в среднем на голову хуже экосистемы js. Но как это связано с языком?