Какие мы нежные и находимся в королевском Английском обществе с зашкаливающем этикетом.
Так может лучше вообще статьи не писать и вообще ни с кем не разговаривать? А то вдруг кто-то не будет восхищаться тем, что ты пишешь или говоришь.
Это утверждение не верно. Почему это вас не убеждает убрать это из статьи? Или изменить текст, на «совместить с Server Side Rendering можно в паре с HTML/SVG/Canvas to PNG и при загрузке JS реплейснуть на canvas для большей производительности и отзывчивости»
Но это уже явно переход границы профессионального общения.
Вас обидело слово «лень»? Ведь вам же аргументы приводят вполне конкретные, а не абстрактные взятые из потолка, а вы «переходит границы». Если не воспринимаете конструктивную критику зачем пишете статьи которые можно комментировать и критику высказывать?
Ну смотрите, есть минус, как бы минус настоящий, то есть вещь серьезная, ощутимая, реальный недостаток.
А есть «минус», ну как бы такое, высосанное из пальца, и названо минусом так чисто ради придирки.
Допустим есть у меня машина и вот лично мой экземпляр кушает на 0.1 литра на 100 км больше, чем у остальных, ну вот прямо где-то просочился малюсенький такой дефект, так вот, это можно назвать «минусом» который именно в кавычках и высосанный из пальца. И если переложить ещё сильнее на вашу статью, то при этом, она быстрее чем у всех остальных скажем на 50% разгоняется, двигатель работает ровнее, масло не поджирает, но есть вот у нее «минус», на 0.1 литра она все таки больше съедает на 100ку.
И вот дилема, можно ли называть это минусом вообще?) Или же все таки это минус чисто по приколу, не имеющий отношения к реальному недостатку?)
А теперь представьте, что она бы теперь кушала в 3 раза больше бензина чем остальные, но при этом все так же на 50% разгонялась быстрее, и вот тут уже этот минус ощутим и осязаем по настоящему, т.к. 10 литров и 30 литров очень большая разница, даже с учетом выигрыша по разгону.
Ах да, вы же написали
Не получится совместить с Server Side Rendering.
Но самом деле то получается, ещё как, просто вам лень) Потому что есть SSR в вашем кейсе или нет, роли реальной вообще никак для пользователя не сыграет.
Так что мешает на сервере нарисовать все на HTML/SVG, а когда загрузится JS, то зареплейсить HTML/SVG на Canvas? Если уж вы так сильно заморочены на этом и для вас это минус.
Ну не знаю, не вижу проблем в реальном асинхронном коде с async/await завернутом в try/catch. Тем более есть разные вариации, в том числе
await someMethod().catch(console.error);
Если не нужно останавливать выполнение кода ниже.
Зато он написан сверху в низ, читается и воспринимается легко и очевидно спустя время. В то время как функциональщина после того как код был написан теряет в читаемости, да и колбэк хэл это мягко говоря на любителя, который живёт далеким прошлым и не воспринимает настоящее время.
Как бы читаемость кода гораздо лучше. Не зря async/await во многих языках появился за долго до js'a. Колбеки давно забытое прошлое, но увы видать не для всех. Да да, цепочки .then это тоже колбэки.
Ага, разумеется))) нету никакого вектора развития стейт менеджеров. Начиная с es6 и по сей день proxy это предел совершенства и возможностей js. А в целом они все pub/sub, и делятся на примитивные и ущербные как redux и ему подобные с ручной подпиской и иммутабильностью или же современные, использующие возможности JS на 100%, такие как mobx и ему подобные реактивные, с автоматической подпиской, которые используют getters/setters и/или proxy, тот же vue например.
Что правда чтоли??)))) Явный pub/sub руками да? .on .off. trigger и т.п да? Вы знаете что такое getters/setters и proxy? Когда они появились в js и что с их помощью можно делать?)
Шел 2020 год, а люди до сих пор не знают что такое MobX и продолжают использовать допотопные, примитивные и ущербные технологии в виде redux и прочей ереси типо санок, саг, реселектов и тому подобное. 2014 год так и не хотите искоренять из себя. Больно смотреть на общий уровень разработки конечно.
Я верю только в то, что могу сам проверить. То что вы скинули vanila и svelte в рамках противостояния по размеру бандла вообще абсолютно не правильно и к реальности отношения не имеет, потому что вы даже элементарно не открыли ни один файлик который там в ваниле грузится и не увидели что он состоит из тонн комментариев, отступов и т.д. И говорите что-то про разницу в размерах бандла.
Итого:
Все что говорите вы или любой другой человек, но это не подтверждено кодом на который можно взглянуть и проверить, а правильное ли вообще это сопоставление/сравнение, то это просто пустые слова которые ничего не значат и брать их в расчет нельзя.
Да мне не нужно вам ничего доказывать :D Пишите как угодно, лишь бы это не трогало других людей) Я просто сочувствую тем, кому потом достанется ваше чудо) Но обычно просто такие проекты переписываются с нуля, т.к. bus factor
Лично для меня React + MobX удобнее использовать нежели Svelte, поэтому мне пофигу на то, что у Svelte бандл меньшего размера. Для меня удобство на первом месте, на втором востребованность на рынке, работаю я не за еду. Если инструмент не удовлетворяет первым 2 пунктам, то он для меня остается не актуальным, пусть он хоть 1kb занимает вне зависимости от размера проекта
Да, есть сходства, но размер то все равно будет меньше в ванильной JS. Мне то вообще по барабану на размер, для меня удобство разработки на первом месте.
Если вам так важен размер бандла, самый минимальный размер будет только когда вы напишеше просто на голой ваниле + минификатор итогового файла. Что тут не понятного то?
Зато маленький бандл) Мне лично на размер бандла начхать, поэтому я использую React + MobX, так же ничего против Vue не имею и против Svelte тоже, а вот от ангуляра блевать хочется)
А кто вам запрещает писать вспоногательные функции то?
В стиле:
const q = (s) => document.querySelectorAll(s);
И т.д. и т.п. плюс после минификации все равно будет меньше 100% чем Svelte значительно, так что для тех кто гонится за маленьким бандлом ванила в помощь
Вот этот блок уже сам по себе уродство и адское нагромождение. И это при условии что табличка то не из реальной жизни, у вас всего 3 колонки, в реальности их обычно 10 и больше.
Вы объединили тут 3 убогих подхода:
1) Render props
2) Wrapped hell
3) Props hell
Брр, вы меня теперь уже совсем запутали. Если вы используете хук useState, то зачем вообще нужен MobX?
useState тут используется просто как конструктор, который возвращает то, что возвращает функция которая в него прокинута, он никакой другой роли не играет и благодаря нему ничего не обновляется, он чисто для того, чтобы переменная state всегда ссылалась на один и тот же экземпляр созданного класса.
class App extends React.Component {
constuctor(){
this.state = new State();
}
}
Это по сути тоже самое, только для функционального компонента.
Так вы сам код посмотрели? Насколько все красиво, и элементарно на самом деле то? Не то, что ваши адские нагромождения и лапшекод. React кайфовый только лишь в связке с MobX, все остальное это дно полнейшее. Если не использовать React+MobX, то надо брать Vue или Svelte.
То есть по вашему что 200Кб, что 150Кб это одно и тоже?
Для тех, у кого всё ещё dial-up модем это не одно и то же, для всех остальных разницы нет, более того что 300kb что 150kb разницы нет, 1 раз загрузил, потом всё равно из кэша берет браузер
1) А зачем вы считаете css строки кода? css к реакту не имеет отношения
2) Можно сэкономить строку `export const App;` и подключать `import { App } from './App`
3) Если отбросить реальный бред и импорты, то разница в кол-во кода реально маленькая, и ей можно принебречь
4) Главное чтобы код был очевидным, легко читаемым и понятным, если из-за этого придется написать на пару строчек кода больше, то вообще пофигу как бы или нет?
5) React надо использовать с MobX, чтобы получать от него удовольствие. Голый реакт или реакт + redux это то ещё дно. Svelte и Vue будут разумеется лучше. Но вот react + mobx это совсем другая история