То есть, если убрать из этого класса observable, action и computed, то в коде смогут разобраться даже далёкие от js люди
поправьте если не прав, но ведь тогда это будет не mobx?
По такой логике, просто уберите из redux actions/reducer/store и в нем сможет разобраться каждый
а чем гарантирована обратная совместимость эксперементальной фичи?
Завтра выходит какой-нибудь ts 5 и ее выпиливают.
Если фича 6 лет не может из эксперементальной перейти в стабильную, то это о чем то да говорит
А есть где об этом почитать? Во что и чем тогда Deno компилирует TS?
Нашел что Deno работает с V8, если есть V8 то почему тогда не компилить TS в JS и не запускать его потом на V8?
вкусовщина это вкусовщина, а мой комментарий был лишь о том что утверждение что «Svelte наиболее приближен к нативному JS, если сравнивать его с тем же Реактом и Вью» в корне не верен, я бы даже сказал что все как раз наоборот.
Так как ближе всех к JS как раз таки React. В то время ка Svelte переопределяя стандартный синтаксис для своих нужд как раз таки дальше всех от JS, так как скорее притворяется им но не является.
Тем более Svelte наиболее приближен к нативному JS, если сравнивать его с тем же Реактом и Вью
React это как раз таки чиcтый JS, лишь с одним синтаксическим сахарком в виде jsx, который просто заменяет конструкцию на React.createComponent(MyComponent) и по факту все.
А вот Vue и Svelte имеют свой «язык» для описания шаблонов. + Svelte вообще использует синтаксические контрукции из js не по назначению, заменяя полностью их смысл (это про метки). Так что говорить что svelte ближе к нативному js чем react в корне не верно.
Забыли добавить в сравнение важный параметр а именно размер библиотеки и возможность тришейкинга.
И конкретно ваше решение сильно страдает от отсутствия последнего
Если на какой то страницы мне нужна просто одна кнопка — то пользователю придется выкачать дополнительные 105кб кода в гзипе а браузеру распарсить дополнительные 400кб кода.
Вы конечно заявляете что официальной поддержки мобилок нет(хотя это тоже огромный минус) но с таким размером библиотеки об этом в целом можно забыть.
Почему кстати ui библиотека берет на себя работу по валидации форм тоже не очень понятно. Это явно стоит вынести в отдельный пакет, так как нужно не всем а размер пакета опять же сильно раздувает
а вот не факт… Мне кажется что тот же Блюз не особо вдохновлен классикой. Изначально это была музыка черных и врятли они много классики слышали
Но утвердждать не буду
Svelte интересен концепциями, но не более. Можете посмотреть доклад Ильи Климова на эту тему, достаточно содержательно и отвечает на вопрос, почему у Svelte мало шансов занять большую нишу
вы немного отстали от жизни) давно уже не выходит «по фреймворку в неделю».
Три основных игрока уже давно закрепились. React/Vue/Angular.
И обратную совместимоть давно никто не ломал. Да и Vue 3 ее не ломает.
Хотя мажорная версия имеет на это полное право
А при чем тут typescript если речь о JS фреймворке? Поддержка фремворком ts это лишь дополнительная плюшка.
А на счет того что typescript начнет противоречить стандарту ES — тоже весьма сомнительно. Ведь он изначально позиционировался как надмножество над ES.
Пока правда не понятно как они будут выкручиваться из данной ситуации с декораторами
нет общепринятых правил. Есть правила принятные на конктретном проекте, не более. Плюс подходы типа CSSModlues лучше работают именно с camelCase нотацией
1. Мы выиграем мы немного процессорного времени… но зачем? Если в приложении есть страница где так много стилей что это начинает играть роль, то скорее всего проблема в самом коде. Если существующий код оправдан, то это уже очень специфичный кейс
2. Нет css, нет js. Есть компонент. Если правите что-то — то вы правите компонент. И его стоит загрузить заново.
Если у вас при правке компонента переобсирается css на 5МБ, то опять же это уже проблема организации кода.
поправьте если не прав, но ведь тогда это будет не mobx?
По такой логике, просто уберите из redux actions/reducer/store и в нем сможет разобраться каждый
Завтра выходит какой-нибудь ts 5 и ее выпиливают.
Если фича 6 лет не может из эксперементальной перейти в стабильную, то это о чем то да говорит
Нашел что Deno работает с V8, если есть V8 то почему тогда не компилить TS в JS и не запускать его потом на V8?
Так как ближе всех к JS как раз таки React. В то время ка Svelte переопределяя стандартный синтаксис для своих нужд как раз таки дальше всех от JS, так как скорее притворяется им но не является.
React это как раз таки чиcтый JS, лишь с одним синтаксическим сахарком в виде jsx, который просто заменяет конструкцию на React.createComponent(MyComponent) и по факту все.
А вот Vue и Svelte имеют свой «язык» для описания шаблонов. + Svelte вообще использует синтаксические контрукции из js не по назначению, заменяя полностью их смысл (это про метки). Так что говорить что svelte ближе к нативному js чем react в корне не верно.
у вас не верная информация. render props живее всех живых и как раз повсеместно применятся для реализации слотов.
И конкретно ваше решение сильно страдает от отсутствия последнего
Если на какой то страницы мне нужна просто одна кнопка — то пользователю придется выкачать дополнительные 105кб кода в гзипе а браузеру распарсить дополнительные 400кб кода.
Вы конечно заявляете что официальной поддержки мобилок нет(хотя это тоже огромный минус) но с таким размером библиотеки об этом в целом можно забыть.
Почему кстати ui библиотека берет на себя работу по валидации форм тоже не очень понятно. Это явно стоит вынести в отдельный пакет, так как нужно не всем а размер пакета опять же сильно раздувает
Зайти только раз в квартал и оплатить страховые взносы
Но утвердждать не буду
а как ученые определяли неординарную и ординарную музыку?
Три основных игрока уже давно закрепились. React/Vue/Angular.
И обратную совместимоть давно никто не ломал. Да и Vue 3 ее не ломает.
Хотя мажорная версия имеет на это полное право
А на счет того что typescript начнет противоречить стандарту ES — тоже весьма сомнительно. Ведь он изначально позиционировался как надмножество над ES.
Пока правда не понятно как они будут выкручиваться из данной ситуации с декораторами
Плюс не забыаем, что css в браузере отлично управляется через js. А значит мы можем меня ть значения каких-либо css переменных в рантайме
2. Нет css, нет js. Есть компонент. Если правите что-то — то вы правите компонент. И его стоит загрузить заново.
Если у вас при правке компонента переобсирается css на 5МБ, то опять же это уже проблема организации кода.
А зачем вобоще кешировать js и сss отдельно? Компонент это не js и не css, это все вместе. Разбиваем на чанки — кешируем чанки.
Это отличный инструмент, со своими плюсами и минусами