Marius Vatasoiu

Marius Vatasoiu

@mariusvatasoiu.com

Staff Engineer @ ING. Playing with Web Components & Deno. Creator of @limette.dev.

366 followers134 following593 posts

Pinned

I've made a framework! 🥳 It's called Limette and it's a full-stack framework for Deno and Web Components (Lit). There are still a lot of things to fix/improve/add, so please be patient. 🙏

Marius Vatasoiu reposted

Introducing tsrs: a Rust port of the TypeScript compiler 🦀 We are not forking TypeScript! ◆ In close collab with the TypeScript team ◆ Up to 8x faster than TS 7.0 & ~70% less memory ◆ Runs in WASM (works in your browser & workers) ◆ Soon part of Oxc npx tsrs blog.cloudflare.com/typescript-r...

blog.cloudflare.comIntroducing tsrs: a Port of TypeScript to RustCloudflare is collaborating on tsrs, a Rust port of TypeScript that is up to 8x faster and uses 70% less memory.

Instead of trying to reinvent a dev server, bundler and integrating other tools, vite offers that (and are better) + an entire plugin ecosystem.

After more than 6 years of work, it's time to finish the article about my biggest professional challenge so far. Thank God I wrote a draft in 2023 with the progress at that point. It has web components 😏

View full thread

But they also have workerd and they don't have too many reasons to maintain 2 runtimes. One possible solution it would have been workerd to merge with Deno Deploy' runtime, while Deno and Vite merge into what's today vite +.

I thought maybe there might be a future where they could be unified, not necessary in a single binary, but at least under the same team. Cloudflare acquisition is the best scenario for this to happen. Cloudflare has the money to support both projects.

I saw it coming for some time, but for the wrong reason. I have so many thoughts that I had to write an article. mariusvatasoiu.com/goodbye-deno

mariusvatasoiu.comGoodbye DenoDeno is being acquired by Cloudflare for the celld project which leads to Deno's death.
Cloudflare@cloudflare.social

We're making the Cloudflare developer platform the best place to run JavaScript, anywhere. Big step toward that today: the Deno team is joining us to build what’s next. https://cfl.re/4rXMBKy

Marius Vatasoiu reposted

Now that we've put Zena out there a bit, we're looking for collaborators of any sort. We especially need people to give feedback on the design choices from many different perspective: developer ergonomics, the type system, compiler architecture, etc. Anyone with any level of interest is welcome!

Recently I used ChatGPT/Codex for a project which uses web components. It made me realize I should finish the next version of Limette faster. LLMs are very good at writing web components/Lit and the support for Tailwind in Limette solves the visual consistency + less code. LLMs are also good at TW.

Marius Vatasoiu reposted

Porffor is now self-hosted, meaning it compiles itself with itself! This is made possible by Porffor's new rewrite, reducing its lines of code by >50% and making C output up to 5x more efficient! Here you can see the stats before and after the rewrite for Porffor itself:

After migrating the banking app to Vite/Vitest, it's time for our internal library of web components to do the jump. It's way easier to do it this time. Simpler config + the experience from the previous migration.

I was investigating a Woo shop for being too slow. It seems Redis Object Cache was the main issue in my case. A plugging that should improve performance, it doubles the page load, from 5s to 10s. Another interesting finding is the meta-webindexer, which was killing my server. 64GB/day. Why?

After migrating a not so small app from Webpack to @vite.dev, it became more clear the real power of Vite: plugins. Even though it's supposed to offer a lot of defaults to give a lightweight config, those don't work in complex apps. But plugins can unlock almost any limitation. And...

View full thread

The final config ain't that much different than Webpack's config. Bundled mode is in the early phase and is actually broken for me in the last 2 versions. There are some quirks for loading js as you need. But...documentation is top. Plugins are unmatched (thanks Rollup 🙏)

After migrating a not so small app from Webpack to @vite.dev, it became more clear the real power of Vite: plugins. Even though it's supposed to offer a lot of defaults to give a lightweight config, those don't work in complex apps. But plugins can unlock almost any limitation. And...

AI excels at writing plugins. Having a package that uses dynamic nested paths - wrote a plugin. Having multiple versions of the same package and wanted to dedupe a specific version - wrote a plugin. Trying to minify CSS literals using Rolldown's API - wrote a plugin.

After 2 years of waiting, I bought the Apple Studio Display XDR 🙂 But now I need a Thunderbolt 5 KVM switch to support 2 MacBooks, but it doesn't exist 🙃

Marius Vatasoiu reposted

🚀Rolldown 1.0 is here!🚀 Rust-based high-performance JavaScript bundler. 🏎️ Runs at native speed that’s up 30x faster than Rollup 🤝 Compatible with existing Rollup & Vite plugins ⚡The underlying bunder for Vite After 2 years, Rolldown is officially stable and has 20+M weekly downloads.

Marius Vatasoiu reposted

TypeScript 7.0 Beta is out 🎉 It's the 10x faster Go-based port 🔥 🔷 `tsgo` vs `tsc` CLIs allow comparing 🔷 --checkers sets checker thread count 🔷 --singleThreaded keeps parsing/emit/checking together 🔷 TS 6.0 deprecations are hard errors 🔷 API access is planned for TS 7.1

TypeScript@typescriptlang.org

TypeScript 7.0 Beta is here! Built on a new native and parallelized foundation, it's already being used on multi-million line codebases. Read up more here and try it on your projects today! devblogs.microsoft.com/typescript/a...

This is literally me while I'm migrating to @vite.dev and @vitest.dev. Once again I think Webpack is way underestimated. After months of work, today I configured vitest for coverage. The performance is dead. From 2-3 min to 27 min? 2-3 min was already just like Karma/Webpack/Jasmine, but 27 min??

View full thread

Vitest with browser mode and isolation fails on CI. There are some spikes in storage usage from Chrome's temp files. Vitest + Istanbul coverage is really really slow. Vitest + V8 coverage doesn't work with Chrome, only Chromium?? Not sure yet about the performance.

On the other side, the documentation is top. Even though it would help to have more examples/best practices, the overall documentation is one of the best. Same for both, Vite and Vitest. LLMs know a lot of Vite/Vitest being so popular it helps. Plugin system. Integration between Vite and Vitest.

This is literally me while I'm migrating to @vite.dev and @vitest.dev. Once again I think Webpack is way underestimated. After months of work, today I configured vitest for coverage. The performance is dead. From 2-3 min to 27 min? 2-3 min was already just like Karma/Webpack/Jasmine, but 27 min??

View full thread

I started with V7 then I've waited v8 hoping it will be better, but no. To name a few things: Dev server in buildless mode doesn't scale - 2000 reqs for a refresh? It's slower then Webpack's incremental builds. Dev server in build mode is not ready, at least source maps don't work at this point.

I don't have control on how scripts are injected and it's quite complex to inject a script at runtime before your main entry point. The bundle seems bigger and chunks are a little bit "unexpected". This is something I need to dive deeper.

This is literally me while I'm migrating to @vite.dev and @vitest.dev. Once again I think Webpack is way underestimated. After months of work, today I configured vitest for coverage. The performance is dead. From 2-3 min to 27 min? 2-3 min was already just like Karma/Webpack/Jasmine, but 27 min??

I don't want to throw shade on Vite/Vitest, I'm just frustrated with my experience. From outside, Vite/Vitest look top notch, but in my project they feel like the wrong tool for the job. For context, I have a Lit-based SPA, around 200 screens and 6000 unit tests.

Marius Vatasoiu reposted

Vite+ is open source under MIT and free for everyone.

VoidZero@voidzero.dev

Announcing Vite+ Alpha. Now open source. To make JavaScript developers more productive than ever before. A single binary that: ◆ Unifies your frontend toolchain ◆ Manages your runtime & pkg manager ◆ Caching & monorepo support Works with every framework and meta framework in the Vite ecosystem.

Well the joy didn't last. With isolation off, mock implementations get leaked in other files that use the original implementation at import time. 😪 Is this the final boss?

Marius Vatasoiu@mariusvatasoiu.com

After months of investigations I think I found the problem. In isolation mode, Chrome doesn't seems to handle the load. For 1k tests in browser mode, @vitest.dev generates around 40k requests, which seems to be too much for Chrome.

I'm still digging this issue and I might have found a @developer.chrome.com bug. When running @vitest.dev in browser mode with Chrome, there is a spike of some deleted but opened temp files by Chrome. In low space environments, this can hit the max limit which crushes vitest.

Marius Vatasoiu@mariusvatasoiu.com

I've tried a docker container with Ubuntu to be closer to the Azure DevOps agents, but no issues. The only difference seems to be some warnings about disk space 🤔

After months of investigations I think I found the problem. In isolation mode, Chrome doesn't seems to handle the load. For 1k tests in browser mode, @vitest.dev generates around 40k requests, which seems to be too much for Chrome.