121–130 of 147 posts
It always comes as a surprise to me how the same group of people who go out of their way to shave off the last milliseconds or microseconds in their tooling care so little about the performance of the code they ship to browsers. Not to discredit OP's work of course.
Earlier quoted context omitted.
Yeah, it is as if there were never other compiled languages before to rewrite JavaScripting tooling.
Why do people get so mad that other people enjoy a language? If I’m more likely to rewrite some tooling because of the existence of a programming language and it’s more performant, isn’t that good for everyone? We are programmers we are supposed to like programming. These rust haters are intolerable.
Earlier quoted context omitted.
Why do people get so mad that other people enjoy a language? If I’m more likely to rewrite some tooling because of the existence of a programming language and it’s more performant, isn’t that good for everyone? We are programmers we are supposed to like programming. These rust haters are intolerable.
Because it gets tiring to have all those Rewrite X in Y, as if X was the very first language where that is possible.
Earlier quoted context omitted.
> esbuild Another example is the TypeScript compiler being rewritten in Go instead of self-hosting. It's an admission that the language is not performant enough, and more, it can never be enough for building its own tooling. It might be that the tooling situation is the problem, not the language itself, though. I do see hopeful signs that JavaScript ecosystem is continuing to evolve, like the recent release of MicroQ…
Which also proves the point that not everything needs to be Rust.
Earlier quoted context omitted.
they are going to use vite plus for monetization
The vite plus idea is that you'll pay for visual tools. What's odd to me is it makes their paid product kind of a bet against their open product. If their open platform were as powerful as it should be, it would be easy to use it to recreate the kinds of experiences they propose to sell. The paradox gains another layer when you consider that their whole mission is to build tools for the JavaScript ecosystem, yet by m…
From what I understand, Vite+ seems like an all-in-one toolchain. Instead of maintaining multiple configurations with various degrees of intercompatibility, you maintain only one.
This has the added benefit that linters and such can share information about your dependency graph, and even ASTs, so your tools doesn't have to compute them individually. Which has a very decent potential of improving your overall pre-merge pipeline. Then, on top of that, caching.
The focus here is of course enterprise customers and looks like it is supposed to compete with the likes of Nx/Moonrepo/Turborepo/Rush. Nx and Rush are big beasts and can be somewhat unwieldy and quirky. Nx lost some trust with its community by retracting some open-source features and took a very long time to (partially) address the backlash.
Vite+ has a good chance to be a contender on the market with clearer positioning if it manages to nail monorepo support.
Earlier quoted context omitted.
Oxidation of iron produces rust. Rust is the language of implementation of that compiler, and of the entire Oxc suite.
But rust is named after a mushroom?
Earlier quoted context omitted.
Which also proves the point that not everything needs to be Rust.
I agree and foresee a future, maybe a decade from now, when the trend shifts to everyone rewriting all the Rust written or generated in the meantime to something else, a newer hopefully simpler language that accomplishes the same thing.
Earlier quoted context omitted.
I expect a file formatter to format the files when I call it. Anything else would be surprising to me.
a new user should not expected to know whether to use "--info", "--help", or "-info" or "/info" A power user can just pass the right params. Besides, it is not that hard to support "--yolo" parameter for that use case
It always comes as a surprise to me how the same group of people who go out of their way to shave off the last milliseconds or microseconds in their tooling care so little about the performance of the code they ship to browsers. Not to discredit OP's work of course.
TBH I don't know how to do that work. If I'm in the backend it's very easy for me. I can think about allocations, I can think about threading, concurrency, etc, so easily. In browser land I'm probably picking up some confusing framework, I don't have any of the straightforward ways to reason about performance at the language level, etc. Maybe once day we can use wasm or whatever and I can write fast code for the fron…
You think about allocations: JS is a garbage collected language and allocations are "cheap" so extremely common. GC is powerful and in most JS engines quite fast but not omniscient and sometimes needs a hand. (Just like reasoning with any GC language.) Of course the easiest intervention to allocations is to remove allocations entirely; just because it is cheap to over-allocate, and the GC will mostly smooth out the flaws with such approaches, doesn't mean ignoring the memory complexity of the chosen algorithms. Most browser dev tools today have allocation profilers equal or better to their backend cousins.
You think about threading, concurrency, etc: JS is even a little easier than many backend languages because it is (almost excessively) single-threaded. A lot of concurrency issues cannot exist in current JS designs unless you add in explicit IPC channels to explicitly "named" other threads (Service Workers and Web Workers). On the flipside, JS is a little harder to reason about threading than many backend languages because it is extensively cooperatively threaded. Code has to yield to other code frequently and regularly. Shaving milliseconds off a routine yields more time to other things that need to happen (browser events, user input, etc). That starts to add up. JS encourages you to do things in short, tight "bursts" rather than long-running algorithms. Here again, most browser dev tools today have strong stack trace/flame chart profilers that equal or exceed backend cousins. Often in JS "tall" flames are fine but "wide" flames are things to avoid/try to improve. (That's a bit reversed from some backend languages where shallow is overall less overhead and long-running tasks are sometimes better amortized than lots of short ones.)
> But someone browsing my webpage one time ever? That might matter a lot less to me, you're not "browsing in a hot loop".
The heavily event-driven architecture of the browser often means that just sitting on a webpage is "browsing in a hot loop". Browsers have gotten better and better at sleeping inactive tabs and multi-threading tabs to not interfere with each other, but things are still a bit of a "tragedy of the commons" that the average performance of a website still directly and indirectly drags everyone else down. It might not matter to you that your webpage is slow because you only expect a user to visit it once, but you also aren't taking into account that is probably not the only website that user is browsing at that moment. Smart users do directly and indirectly notice when the bad performance of one webpage impacts their experiences of other web pages or crashes their browser. Depending on your business model and what the purpose of that webpage is for, that can be a bad impression that leads to things like lost sales/customers.
I've played with all of these various formatters/linters in my workflow. I tend to save often and then have them format my code as I type. I hate to say it, but biome just works better for me. I found the ox stuff to do weird things to my code when it was in weird edge case states as I was writing it. I'd move something around partially correct, hit save to format it and then it would make everything weird. biome isn…
oxc formatter is still alpha, give it some time