Not to get too bogged down in semantics, but in my mind, there’s a pretty big difference between an alpha and a prototype. A prototype just has to prove out your basic approach, and you don’t put it in the hands of end users, early adopter or not. An alpha is a lot more work, and while it’s expected to be buggy and missing some features, it should be substantially representative of the final product.
It already loads most websites pretty well (The JS engine is nearly complete!). Currently the big tasks are implementing the remaining web APIs and improving performance, stability, and security, so IMO 2026 is a good target for the first Alpha-test releases.
It's an entire new browser engine. It's a moving target fueled by billions of dollars, dominated by megacorporations, with thousands of edge cases to account for. I'm surprised it'll be ready for alpha that soon.
Oh! I stand corrected. That's a wrapper for TSC, though, right?
Edit to add: I see, Deno embeds TSC as a library and tries to straighten out the mess of tsconfig. That must be a leaky abstraction, which makes me wary, but maybe it works well in practice.
Don’t underestimate the difficulty of semiconductor manufacturing. It’s not that they’re trying to implement a fixed target - the technology has been exponentially advancing for the last 50 years.
I like the premise of Bun, and early speedups are impressive, but I'm not convinced by the project management yet. Lots of design decisions seem to be made arbitrarily (on a whim rather than deeply thought through), and want to see a track record of stability first.
I follow commentary from the dev team... there seems to be a tendency towards "this thing is useful, let's add it" without thinking through the larger API surface area or future issues adding those APIs will introduce. Not sure it was ready for v1 yet. If I were them I wouldn't be afraid to break things and increment the major version at this point.. but once you have real users you pretty much have to maintain your design decisions
I'd love to see these concerns turn out to be unfounded down the line! Also want to see Node adopt an incremental approach towards Rust or similar and focus more on performance in response
Deno I think just missed the mark by a wide margin out of the gate. Seemed to focus on things that nobody was asking for, and also hurt DevX. Perhaps the situation has improved more recently
Thank you for the detailed feedback. Deno 1.38.4 was just released with a partial fix for the VSCode issue you mentioned. We're fixing the twisted issue too.
We cannot simply stop driving anymore than we can stop using an increasing amount energy. There are huge portions of humanity that live in places that depend on cars. It’s a non-solution to say people should just stop driving - billions cannot.
It's unreasonable to expect individuals to unilaterally stop driving. But on a societal scale, it's entirely reasonable to expect our governments to build infrastructure that allows (many of) us to stop driving. That isn't simple, but neither is it an intractable problem.
reply