• За счет чего Bun и Deno работают быстрее Node?

    bingo347
    @bingo347 Куратор тега Node.js
    Crazy on performance...
    У bun потенциально может быть быстрее старт приложения за счет использования движка JavaScriptCore вместо V8 в node/deno. Вот только у V8 на сегодня поддержка всех нюансов ECMAScript самая близкая к 100%. А старт рантайма происходит лишь 1 раз во время жизни приложения. Считать ли это профитом - вопрос философский.
    Ну и ИМХО, если биться за скорость путем смены движка, то я бы лучше взял QuickJS.

    Еще потенциальный выигрыш может быть за счет переписывания тех частей, что в node реализованы на JS. В node на самом деле очень многое на JS сделано. 100% встроенных модулей написано на JS, где уже под капотом дергаются функции из C++. Я не смотрел исходники deno/bun, но экспериментировал с v8 на Rust (спасибо deno за нормальный биндинг). Работать это будет быстрее, вот только обрабатывать JS Promise из нативки то еще приключение, и хочется делать это пореже за счет JS прослоек, как собственно и происходит в node.
    Rust (deno) и Zig (bun) по скорости сравнимы с плюсами (где-то быстрее, а где-то медленнее, но в среднем примерно одинаково). Самый большой оверхед в языках с рантаймом создает рантайм (сборка мусора, JIT компилятор и т.д.), у C++, Rust и Zig подкапотного рантайма почти нет, у JS - целый V8/другие движки.

    Ну и еще момент, что bun, что deno работают с ts из коробки. Вот только TypeScript - это язык у которого нет спеки, есть открытый код компилятора (в котором черт ногу сломит), есть release notes, а спеки нет. А значит гарантировать 100% совместимость с tsc не может никто. Хотя это проблема не только этих сред, но еще и WebStorm и babel-typescript например. Хотя на сколько понял они пошли путем babel - просто затранспайлить (по сути выкинуть все типы), вот только babel в некоторых кейсах все же ломает код...
    Ответ написан
    1 комментарий
  • Как исправить код конвертации vec_u8 to vec_&str?

    bingo347
    @bingo347
    Crazy on performance...
    Сумбурный вопрос, но если правильно понял, то автор хочет получить Vec<&str> элементы которого ссылаются на исходный вектор байт и в каждом элементе строка из 1 символа:
    let u01 = vec![59, 13, 10, 32, 47, 42];
    let u01_str = std::str::from_utf8(&u01).expect("invalid utf8");
    let mut u02 = Vec::with_capacity(u01.len());
    let mut i0 = 0;
    for (i, _) in u01_str.char_indices().skip(1) {
        u02.push(&u01_str[i0..i]);
        i0 = i;
    }
    u02.push(&u01_str[i0..]);
    println!("u02 = {:?}", u02);
    Ответ написан
    Комментировать
  • Как передать из функции значения в разные потоки?

    bingo347
    @bingo347
    Crazy on performance...
    Начну с того, что код представленный автором в комментах к вопросу имеет deadlock между мьютексом и recv() из канала и завершается лишь по тому, что мы не ждем фоновые потоки. Вариант без deadlock будет выглядеть так:
    fn test() {
        let mut channels = Arc::new(Mutex::new(Vec::with_capacity(PAR)));
        let mut joins = Vec::with_capacity(PAR);
        for _ in 0..N / PAR {
            for _ in 0..PAR {
                let mut channels = Arc::clone(&channels);
                joins.push(thread::spawn(move || {
                    get(channels.lock().unwrap());
                }));
            }
        }
        for j in joins {
            j.join().unwrap();
        }
    }
    
    #[inline(always)]
    fn get(mut channels: MutexGuard<Vec<mpsc::Sender<i32>>>) -> i32 {
        let (tx, rx) = mpsc::channel();
        channels.push(tx);
        if channels.len() == PAR {
            exec(channels);
        } else {
            drop(channels); // drop гварда отпускает мьютекс
        }
        rx.recv().unwrap()
    }
    
    #[inline(always)]
    fn exec(mut channels: MutexGuard<Vec<mpsc::Sender<i32>>>) {
        let mut i = 0;
        for c in channels.iter() {
            i += 1;
            c.send(1).unwrap();
        }
        println!("{}", i);
        channels.clear();
        // а здесь гвард дропнется сам
    }

    Вторая проблема в том, что все потоки выполняются по сути по очереди, так как ждут разблокировки мьютекса от других потоков, из-за чего многопоточка тут не дает никаких преимуществ, а лишь создает накладные расходы. Ради эксперимента я попробовал заменить мьютекс на еще один канал:
    fn test() {
        let (tx, rx) = mpsc::channel::<mpsc::Sender<i32>>();
        let mut handles = Vec::with_capacity(N + 1);
        handles.push(thread::spawn(move || exec(rx)));
        for _ in 0..N {
            let tx = tx.clone();
            handles.push(thread::spawn(move || {
                get(tx);
            }))
        }
        drop(tx);
        for handle in handles {
            handle.join().unwrap();
        }
    }
    
    fn get(sender: mpsc::Sender<mpsc::Sender<i32>>) -> i32 {
        let (tx, rx) = mpsc::channel();
        sender.send(tx).unwrap();
        rx.recv().unwrap()
    }
    
    fn exec(receiver: mpsc::Receiver<mpsc::Sender<i32>>) {
        let mut channels = Vec::with_capacity(PAR);
        loop {
            for _ in 0..PAR {
                let Ok(tx) = receiver.recv() else {
                    return;
                };
                channels.push(tx);
            }
            let mut i = 0;
            for c in channels.iter() {
                i += 1;
                c.send(1).unwrap();
            }
            println!("{}", i);
            channels.clear();
        }
    }
    Но особо это профита не дает, так как основной пожиратель перфоманса - switch context в ОС. Тысячи потоков делают только хуже. Запускать потоков сильно больше чем есть ядер - это вообще плохая идея. Просто ради интереса переписал еще раз на асинхронных каналах tokio:
    async fn test() {
        let (tx, rx) = mpsc::unbounded_channel::<mpsc::UnboundedSender<i32>>();
        let mut handles = Vec::with_capacity(N + 1);
        handles.push(tokio::spawn(async move { exec(rx).await }));
        for _ in 0..N {
            let tx = tx.clone();
            handles.push(tokio::spawn(async move {
                get(tx).await;
            }))
        }
        drop(tx);
        for handle in handles {
            handle.await.unwrap();
        }
    }
    
    async fn get(sender: mpsc::UnboundedSender<mpsc::UnboundedSender<i32>>) -> i32 {
        let (tx, mut rx) = mpsc::unbounded_channel();
        sender.send(tx).unwrap();
        rx.recv().await.unwrap()
    }
    
    async fn exec(mut receiver: mpsc::UnboundedReceiver<mpsc::UnboundedSender<i32>>) {
        let mut channels = Vec::with_capacity(PAR);
        loop {
            for _ in 0..PAR {
                let Some(tx) = receiver.recv().await else {
                    return;
                };
                channels.push(tx);
            }
            let mut i = 0;
            for c in channels.iter() {
                i += 1;
                c.send(1).unwrap();
            }
            println!("{}", i);
            channels.clear();
        }
    }
    и запустил в многопоточном рантайме в дефолтной конфигурации (количество воркеров == количеству ядер), работает быстрее в 19 раз.

    P.S. без I/O операций асинхронщина тоже создает ненужные накладные расходы, я ее здесь использовал только из-за простоты переписывания, лучше взять обычный thread pool с синхронными тасками.
    Ответ написан
    Комментировать
  • Почему реджекшн главного промиса не перехватываться блоком .catch?

    bingo347
    @bingo347 Куратор тега Node.js
    Crazy on performance...
    Как я понимаю, этот .catch должен перехватить реджект главного
    промиса, но эта часть в принципе не выполняется и выходит
    ошибка UnhandledPromiseRejection

    Не должен, он с ним никак не связан.
    Ответ написан
    1 комментарий
  • Какой Object pool стоит использовать в Rust?

    bingo347
    @bingo347
    Crazy on performance...
    меня очень смущает постоянно выделять буффер

    Конкретно в данном примере буффер выделяется на стеке, то есть на его выделение не тратится ровным счетом ничего, так как стек и так уже выделен при запуске потока.
    Есть конечно копеечные затраты ресурсов на заполнение буфера нулями. И если в буффер гарантированно сначала идет запись, как в данном случае, то это в принципе можно обойти:
    use std::mem::MaybeUninit;
    let mut buffer = unsafe {
        #[allow(invalid_value)]
        MaybeUninit::<[_; 1024]>::uninit().assume_init()
    };
    Но я бы так не делал. Во-первых чистота кода не стоит этих копеек производительности, а во-вторых немного накосячите с чтением и будет UB.
    Ответ написан
    3 комментария
  • Почему в Docker собирается не тот Rust?

    bingo347
    @bingo347
    Crazy on performance...
    FROM rust:latest as build
    
    WORKDIR /test-tcp
    
    COPY ./Cargo.lock ./Cargo.lock
    COPY ./Cargo.toml ./Cargo.toml
    COPY ./src ./src
    
    RUN cargo build --release
    
    FROM debian:buster-slim
    
    COPY --from=build /test-tcp/target/release/test-tcp /usr/src/test-tcp
    
    CMD ["/usr/src/test-tcp"]

    Проблема в том, что в докере Вы создаете пустой проект из шаблона cargo
    RUN USER=root cargo new --bin test-tcp
    и компилируете его, потом копируете src
    Да, там есть еще один билд после этого, но я попробовал собрать Ваш Dockerfile у себя, и получил на втором билде результат инкрементальной сборки без изменений. То есть cargo не увидел, что папка src поменялась.
    Ответ написан
    4 комментария
  • Как типизировать router.push(pathname)?

    bingo347
    @bingo347 Куратор тега TypeScript
    Crazy on performance...
    if (pathname !== null) {
        router.push(pathname);
    }
    Ответ написан
  • Как правильно принимать данные в потоках?

    bingo347
    @bingo347
    Crazy on performance...
    Arc нужно клонировать до move в замыкание, которое запускается на потоке. Если данные используются только на чтение, то этого будет достаточно, если данные будут меняться из нескольких потоков, то следует дополнительно обернуть их в Mutex/RwLock (или из std::sync или из библиотеки parking_lot).
    use std::sync::Arc;
    
    fn main() {
        let data = Arc::new(vec![1, 2, 3]);
    
        let thread_1 = std::thread::spawn({
            let data = Arc::clone(&data);
            move || {
                println!("Thread 1 data: {:?}", data);
            }
        });
    
        let thread_2 = std::thread::spawn({
            let data = Arc::clone(&data);
            move || {
                println!("Thread 2 data: {:?}", data);
            }
        });
    
        thread_1.join().unwrap();
        thread_2.join().unwrap();
    }

    Передавать так можно хоть вектор, хоть свою структуру, главное чтоб у типа был трейт Send и лайфтайм 'static (все владеющие типы имеют такой лайфтайм).
    Так как передаем мы по сути Arc, то Send должен быть у него, а он будет для любого содержимого реализующего Sync.

    Я обернул создание отдельного потока в функцию и так передавал в поток данные. Удобно, что такую функцию могу вынести в отдельный файл-модуль. Но не смог такое сделать динамически в цикле для группы потоков. Хочу подойти к варианту, когда поток, который закончил выполнение своего кода (раньше других), можно опять запустить из main и передать ему новую задачу (новые данные), - структуру данных, которую привёл в основном вопросе.
    Если правильно понял, то Вам нужен thread pool. Можно использовать из библиотеки rayon: https://docs.rs/rayon/1.7.0/rayon/struct.ThreadPoo...
    Но если хочется повелосипедить, можно нечто такое сделать:
    use std::{
        sync::{
            mpsc::{self, Sender},
            Arc, Mutex,
        },
        thread::{self, JoinHandle},
    };
    
    type Task = Box<dyn FnOnce() + Send + 'static>;
    
    pub struct ThreadPool {
        handles: Vec<JoinHandle<()>>,
        task_sender: Sender<Task>,
    }
    
    impl ThreadPool {
        pub fn new() -> Self {
            let threads_count = thread::available_parallelism()
                .map(|n| n.get())
                .unwrap_or(2);
            let (task_sender, task_receiver) = mpsc::channel::<Task>();
            let task_receiver = Arc::new(Mutex::new(task_receiver));
            let mut handles = Vec::with_capacity(threads_count);
            for _ in 0..threads_count {
                let task_receiver = Arc::clone(&task_receiver);
                handles.push(thread::spawn(move || loop {
                    let task_receiver = task_receiver.lock().unwrap_or_else(|e| e.into_inner());
                    let Ok(task) = task_receiver.recv() else {
                        return;
                    };
                    drop(task_receiver);
                    task();
                }));
            }
            Self {
                handles,
                task_sender,
            }
        }
    
        pub fn spawn_task<F: FnOnce() + Send + 'static>(&self, f: F) {
            self.task_sender.send(Box::new(f)).expect("All threads ended");
        }
    
        pub fn join(self) -> thread::Result<()> {
            drop(self.task_sender);
            for handle in self.handles {
                handle.join()?;
            }
            Ok(())
        }
    }
    
    #[test]
    fn thread_pool() {
        let pool = ThreadPool::new();
        for i in 0..500 {
            pool.spawn_task(move || {
                println!("Task {} working on thread {:?}", i, thread::current().id());
            });
        }
        pool.join().unwrap();
    }
    Ответ написан
    3 комментария
  • Как правильно сложить дату-время в массив?

    bingo347
    @bingo347
    Crazy on performance...
    use chrono::prelude::*;
    use std::sync::mpsc;
    use std::sync::mpsc::{Receiver, Sender};
    use std::{thread, time};
    
    fn main() {
        println!("- - - - -");
        let mut children = Vec::with_capacity(3);
    
        for id in 0..children.capacity() {
            let child = thread::spawn(move || {
                let mut date_times = Vec::with_capacity(5);
                for i in 0..date_times.capacity() {
                    let t: DateTime<Local> = Local::now();
                    date_times.push(t);
                    println!("{:?}_ поток, задача _{:?}, время: {:?}", id, i, t);
                    thread::sleep(time::Duration::from_millis(3));
                }
                (id, date_times)
            });
    
            children.push(child);
        }
    
        for child in children {
            let (id, date_times) = child.join().expect("Дочерний поток паникует");
            println!("thd_{} = {:?}", id, date_times);
        }
        println!("- - - - -");
    }
    Ответ написан
    1 комментарий
  • Как сделать много вставок в HashMap за минимальное время?

    bingo347
    @bingo347
    Crazy on performance...
    Начну с того, что Вы абсолютно не понимаете зачем нужен async. Есть 2 вида нагрузки - CPU-bound и I/O-bound (где I/O - это input/output). Особенность I/O-bound нагрузки в том, что процессор большую часть времени простаивает в ожидании I/O операций (диска, сети, базы данных и т.д.). Async как раз решает эту задачу за счет кооперативной многозадачности, пока одна задача ждет ответ от I/O мы можем нагрузить CPU другой задачей. Естественно все это не бесплатно, но выигрыш тут в отсутствии простоя CPU за счет того, что мы запускаем тысячи задач на небольшом количестве потоков (в некоторых средах, вроде node.js или asyncio в python такой поток вообще 1), например tokio по-умолчанию запускает пул потоков по количеству ядер.
    Из этого уже можно выделить проблемы в Вашем коде:
    #[tokio::main(flavor = "multi_thread", worker_threads = 1024)]
    1024 - потеряли весь профит от небольшого числа потоков, теперь ОС будет распределять 1024 потока на небольшое количество ядер CPU.
    async fn set(&mut self, name: String, value: String) {
        self.data.insert(name, value);
    }
    у этого метода нет ни одной причины быть асинхронным, операции с HashMap - чистый CPU-bound.

    Вообще, данную задачу можно распараллелить, и для этого достаточно обычных потоков:
    fn main() {
        let start = Instant::now();
        let handles: Vec<_> = (0..4)
            .map(|table_index| {
                std::thread::spawn(move || {
                    let mut table = Table::new();
                    for i in (0..3000000).filter(|i| (i % 4 + 1) == table_index) {
                        table.set(format!("{}", i), format!("value{}", i));
                    }
                    table
                })
            })
            .collect();
        for handle in handles {
            let _table = handle.join().unwrap();
            // тут добавляем таблицы в менеджер
        }
        let elapsed = start.elapsed();
    
        println!("Time taken to set 3,000,000 keys: {:?}", elapsed);
    }
    и даже это можно заморочиться и улучшить, например запускать потоков не больше std::thread::available_parallelism() или оптимизировать счетчик для каждой таблицы (
    (0..3000000).filter(|i| (i % 4 + 1) == table_index)
    ), но это я оставлю Вам в качестве д/з.

    В общем, Ваша проблема не в том, что какие-то структуры/библиотеки медленные, а в том, что Вы их используете не по назначению.
    Ответ написан
    2 комментария
  • Как в rust конвертировать place expression в value expressions?

    bingo347
    @bingo347
    Crazy on performance...
    Проблема с типами тут.
    Тип fn() -> u8 - это указатель на функцию. В него можно записать или обычную функцию с подходящей сигнатурой или замыкание, которое ничего не замыкает:
    fn some_func() -> u8 {
        0
    }
    
    let f: fn() -> u8 = some_func;
    let f: fn() -> u8 = || 0;

    Если же замыкание что-то замыкает (захватывает переменные из окружения), то это уже анонимная структура, хранящая в себе все захваченные значения (или ссылки на них), и у этой структуры просто перегружен оператор круглые скобки через трейты Fn/FnMut/FnOnce. Притом, так как компилятор генерирует для каждого замыкания в коде свою анонимную структуру, у каждого замыкания будет свой уникальный тип.

    Если массив замыканий полностью формируется в цикле, то замыкания будут одного типа и все скомпилируется:
    fn main() {
        let mut funcs = Vec::with_capacity(3);
        for i in 1u8..=3 {
            funcs.push(move || i);
        }
        
        for i in 0..3 {
            println!("{}", funcs[i]());
        }
    }


    P.S. для рэнжей есть литералы, не нужно их создавать через std::ops::RangeInclusive::<u8>::new
    Ответ написан
    2 комментария
  • Как происходит исполнение кода в Event Loop и управление потоками для веб приложений?

    bingo347
    @bingo347 Куратор тега Node.js
    Crazy on performance...
    1. Как происходит связь между кодом js, c++. На самом гитхабе Nodejs можно открыть папки с функциями, которые я импортирую в коде. А также их реализации в файлах .cc расширения. Но не могли бы подробнее описать механизм, которые позволяет 2 разных языка использовать.
    JS движок (например V8) предоставляет платформе (Node.js) некоторый C++ api, через который платформа может движком управлять. Например через это api можно дать движку строчку с JS кодом и попросить его выполнить, а в ответ получить указатель на результат выполнения (V8 например возвращает результат последнего выражения в коде). Так же, если у нас есть указатель на JS функцию, можно попросить движок ее выполнить с определенными аргументами и this, а в ответ получить результат этого выполнения (функция что-то вернула или бросила исключение). Ну и наконец, мы можем дать этому api указатель на C/C++ функцию, а движок сделает из нее JS функцию и вернет указатель на нее, когда JS функция вызывается движок вызовет нашу C/C++ функцию и даст ей на вход контекст выполнения, из которого можно извлечь this и аргументы функции, так же через контекст можно установить результат выполнения JS функции, указав что JS функция должна вернуть некоторое JS значение или бросить некоторое исключение.

    2. V8 - движок для исполнения JS кода, то есть превращения его в машинный код для исполнения комманд. Libuv написана на с++. Они же не работают в паре? Я так понимаю, что часть кода исполняется на движке v8, а различные асинхронные вызовы, которые через Nodejs api делегируются библиотеке Libuv - уже от неё превращаются в низкоуровневый машинный код, который исполняется компьютеров?Можете чуть пролить свет на исполнения уже между этими компонентами Libuv, V8.
    V8 ничего не знает о libuv, как и libuv ничего не знает о V8.
    V8 занимается компиляцией/интерпретацией/выполнением JS кода, управлением JS памятью и некоторыми другими связанными с JS вещами. В V8 нет никаких event loop и чего-то подобного, он запускает JS код только когда ему об этом скажет платформа (например Node.js).
    Libuv занимается асинхронными операциями. Что-то переадресует операционной системе, например сетевые сокеты можно собрать в пачку и отдать в epoll в Linux или kqueue в MacOS, заблокировав лишь один поток сразу на тысячи сокетов. А что-то просто блокируется на фоновых потоках, например обращения к файловой системе. Event loop нет и здесь, но зато есть очередь задач, которые потенциально готовы.
    Ну и наконец сама платформа (Node.js) реализует event loop (по сути просто бесконечный цикл), в котором получает потенциально готовые задачи от libuv и раскладывает по своим очередям готовые, а неготовые планирует в libuv, спрашивает у V8 не хочет ли он сделать сборку мусора, ну и наконец говорит V8 вызвать некоторые JS функции.

    3. После того, как Nodejs передает асинхронный вызов Libuv на исполнение. То callback функция помещается позже в стэк для исполнения, а исполнятся начинается после того, как система просигнализирует о завершении процесса, например считывания файла. Или вначале считывается файл, а потом система об этом сигнализирует и помещается callback функция в стэк Event Loop'a для исполнения?
    Выше уже расписал как Node.js взаимодействует с libuv в теле event loop, так же расписал как JS код может вызвать C++ функцию. Рассмотрим на сильно упрощенном примере, что происходит когда в JS коде на Node.js мы вызываем fs.readFile(filepath, callback):
    1. fs.readFile - это обычная JS функция, но внутри она вызывает некоторую C++ функцию из Node.js, которая получает указатель на строку filepath и указатель на JS функцию callback, но эта C++ функция будет запущена на том же потоке где и event loop (по сути где-то внутри цикла), а блокировать нам нельзя. Поэтому она просто планирует вызов другой C++ функции на фоновых потоках и завершается, возвращая тем самым управление JS коду.
    2. В какой-то момент до запланированной C++ функции дойдет очередь на выполнение на одном из фоновых потоков, она прочитает файл в память и добавит в очередь готовых задач некоторый объект, который является результатом операции чтения из файла, этот объект будет хранить в себе указатель на прочитанные данные и указатель на JS функцию callback.
    3. Еще через некоторое время поток с event loop извлечет из очереди этот объект результат и скажет V8 вызвать функцию callback с данными из файла.

    4. Можете более подробней рассказать про исполнение кода на инстансах приложения в зависимости от количества ядер процессора и управления потоками:

    4.1 Есть к примеру приложений на Nodejs. На компьютере 4 ядра. Я на каждом ядре могу запустить инстанс этого приложения. И у каждого инстанса в pool thread'e будет по 4 потока дополнительных, которые создаются по умолчанию?
    Каждый инстанс Node.js - это отдельный процесс операционной системы. У каждого процесса своя изолированная память. И да, каждый может запускать несколько потоков (у Node.js кстати 4 потока - это минимум, при большой нагрузке она может добавить в пул до 128 потоков), но в случае с Node.js большая часть потоков почти всегда что-то ждут (пока тот же файл прочитается например) и почти не тратят ресурсы CPU, а активно работает лишь один - тот в котором event loop.

    4.2 Если отойти от ноды и запустить приложение на php фреймворке на Apache и этот сервер выделяет под каждый запрос свой поток.В данном случае - это такой же условно поток, который может выделяться и библиотекой Libuv или это абсолютно разные понятия? И сколько инстансов php приложения запущено, когда Apache под каждый создает свой поток? Как соотносится поток с инстансом приложения на php.
    С точки зрения операционной системы - да, это такие же потоки. Разница заключается в том, что в этих потоках происходит. В php только 1 поток, который то что-то полезное делает, то ждет ответа от БД/файловой системы/еще чего-то. А в Node.js это разделено, 1 поток занят только полезной работой (выполнением JS кода) и несколько только ждут ответа.
    Насчет какие там лимиты на количество инстансов php у Apache я не скажу, но они точно не бесконечные, а значит если лимит будет исчерпан, то клиенты (браузер) будут ждать пока какой-то из инстансов php не завершит свою работу полностью. А в node.js мы на одном инстансе можем обслуживать сразу множество клиентов, выполняя задачи для каждого по чуть-чуть, пока для одного клиента ждем ответ из БД можем заняться обработкой запроса от другого клиента.

    4.3 Может в дополнение расскажите про потоки в системе, их ограничения и т.д
    Тут целую лекцию можно читать. Думаю это стоит вынести в отдельный вопрос.
    Ответ написан
    3 комментария
  • Реально ли заменить gulp на vite?

    bingo347
    @bingo347
    Crazy on performance...
    Есть сборщик gulp
    То что под gulp есть сборщики не делает сам gulp сборщиком. Gulp - task runner, запускалка задач. То есть сборщик под капотом может быть любой, хоть тот же vite.
    Теперь про vite, основная его фишка - это ускорение dev сборок и за счет этого ускорение самого процесса разработки. Достигает он это за счет того, что по сути не собирает Ваши исходники, а только применяет к ним трансформации, хотя зависимости все же собирает с помощью esbuild. При этом для прода вся сборка переадресуется на rollup. И то что в dev и в prod у Вас будут по сути разные сборщики изредка приводит к багам, которые воспроизводятся только в prod сборках. Rollup надо сказать тоже не идеален и на больших проектах порой ломает код, хоть и редко.
    Тут мое ИМХО и не более
    Rollup для сборки библиотек.
    Webpack для сборки конечных приложений.
    Vite интересен скорее интегрированным в него vitest, который позволяет писать unit тесты ближе к логике (привык я к хорошему в Rust).

    А по факту, смена сборщика чревата ошибками, сильными изменениями в структуре проекта и прочими подводными камнями.
    Если вопрос "стоит ли переезжать" появился только из hype-driven-development (погоней за модой по-простому), то ответ однозначный - нет, не стоит.
    Если же текущая сборка накладывает на Вас сильные ограничения и борьба с этими ограничениями занимает очень много времени, настолько, что потенциальные проблемы от смены сборки скорее всего займут времени меньше, то да, стоит переезжать.
    Ответ написан
    1 комментарий
  • Обработать If-Modified-Since?

    bingo347
    @bingo347 Куратор тега JavaScript
    Crazy on performance...
    Комментировать
  • Как правильно расширить дженерик интерфейс?

    bingo347
    @bingo347 Куратор тега TypeScript
    Crazy on performance...
    Что-то вроде такого:
    https://www.typescriptlang.org/play?#code/KYDwDg9g...
    Ответ написан
    Комментировать
  • Как реализовать логику игры на js?

    bingo347
    @bingo347
    Crazy on performance...
    Так как в нормальном диалоге следующие реплики зачастую зависят от предыдущих, то нужны не массивы, а дерево запросов и ответов. Или даже граф, так как возможно что несколько путей приведут к одной ноде.
    А дальше усложняйте на свой вкус, введите шкалу отношения например, от которой зависят реплики бота.
    Ответ написан
    1 комментарий
  • Является ли абстрактная фабрика способом динамически создавать классы?

    bingo347
    @bingo347
    Crazy on performance...
    Пример бы привели, который увидели.
    Если кратко - ответ нет, абстрактная фабрика отличается от обычной, тем что создает объекты не конкретного типа, а более абстрактного (любого типа удовлетворяющего интерфейсу например).
    Динамически создавать классы не во всех ЯП можно, а паттерны абстрагированы от ЯП.
    Ответ написан
    1 комментарий