Live data from Hacker News

Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

github.com

31–40 of 165 posts

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#31
post #24

Earlier quoted context omitted.

They won't have untyped dependencies for situations where someone used Scriptc as a way to build a fast binary executable for some custom-written TypeScript, which was the first use-case that came to mind for me. Being able to build small, fast binaries without writing them in C or Rust - if you're already fluent in TypeScript - seems like a valuable capability.

Yes, being able to build small and fast binaries in TS would be a valuable capability, which is why basically all of us who work in this space have thought of this idea and rejected it after going deep on it. This isn’t a new idea. CanadaHonk has gotten further than the rest of us. It’s surprising and impressive. You’re only replying to the quickjs issue I raised, but it’s not the only issue. Their approach to number…

The QuickJS thing doesn't seem like a big deal to me, provided the documentation makes it clear that code will run slower if you use Any.

If I was using this project for something I'd expect to write custom TypeScript for it.

The floats rather than integers thing does look bad though. I tried compiling their fibonacci example to C (--backend c) and got this:

  static double sc_f_fib(double sc_l_n_0) { /* /private/tmp/fib.ts:1 */
    double sc_t0 = sc_l_n_0;
    double sc_t1 = 2.0;
    bool sc_t2 = sc_t0 

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#32
post #31

Earlier quoted context omitted.

Yes, being able to build small and fast binaries in TS would be a valuable capability, which is why basically all of us who work in this space have thought of this idea and rejected it after going deep on it. This isn’t a new idea. CanadaHonk has gotten further than the rest of us. It’s surprising and impressive. You’re only replying to the quickjs issue I raised, but it’s not the only issue. Their approach to number…

The QuickJS thing doesn't seem like a big deal to me, provided the documentation makes it clear that code will run slower if you use Any. If I was using this project for something I'd expect to write custom TypeScript for it. The floats rather than integers thing does look bad though. I tried compiling their fibonacci example to C (--backend c) and got this: static double sc_f_fib(double sc_l_n_0) { /* /private/tmp/f…

If you’re writing Typescript with zero dependencies and trying to target native I feel like it makes more sense to write it in a different language like Rust or Go. The main reason for this I think is getting cheap perf wins by running existing code natively.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#33
post #13
post #8

One of the strengths of TypeScript besides its expressiveness is that it's compatible with the massive npm ecosystem. Most packages only ship untyped JavaScript with type declarations defining the interface,[0] so realistically you'd still need a JavaScript engine if you use any packages. But if you're starting from scratch and know you won't be using any npm packages, you might as well use AssemblyScript.[2] [0]: Pu…

Those are good reasons to publish untyped libraries as a rule, sure. But the contention that those reasons outweigh the value of types kinda boggles the mind, ngl!

Publishing a lib as JS with .d.ts type files gives you JS compatibility and TS types for using the lib, but no TS source so no types inside.

I’ve seen people want to publish TS libs but there are issues: TS will type check the libs as well as your project. You can’t tell it to stop just because it’s going inside node modules. And the app may have tighter settings than the library and you will get type errors if your configs were setup differently. It would be interesting to standardize publishing real typescript libs but I haven’t seen it. Maybe deno tried? I haven’t looked.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#34
post #24

Earlier quoted context omitted.

They won't have untyped dependencies for situations where someone used Scriptc as a way to build a fast binary executable for some custom-written TypeScript, which was the first use-case that came to mind for me. Being able to build small, fast binaries without writing them in C or Rust - if you're already fluent in TypeScript - seems like a valuable capability.

Yes, being able to build small and fast binaries in TS would be a valuable capability, which is why basically all of us who work in this space have thought of this idea and rejected it after going deep on it. This isn’t a new idea. CanadaHonk has gotten further than the rest of us. It’s surprising and impressive. You’re only replying to the quickjs issue I raised, but it’s not the only issue. Their approach to number…

There is always AssemblyScript

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#37
post #36

another vercel labs thing that's been slopped together, hyped up on twitter and then left to be forgotten about in a few months time.

This is one of the things that is tiring me out the most. Previously people could have these "ohh shiny" ideas and would lose steam before they could be implemented, especially in areas they're clueless about.

Now people can have these ideas, slop together an awful solution that works at a surface level, maybe, but will never really go places because the foundation is slopped with no party involved actually capable of thinking thing through. But hey we launched something so let's make lots of noise! Oh look, a banana ... Sorry, what were we talking about?

There's an engineer on a team at work that I routinely engage with who slops together stuff so fast his team is basically exhausted all the time. They're stuck picking up a whole stream of pieces of crap because the engineer is incapable of actually doing the hard work of getting things to production because there's more "ohh, shiny" stuff they can spend tokens on, and their leadership aren't stepping in because it all looks terribly productive (it really isn't)

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#38
post #6
post #4

Porforr https://porffor.dev > has been working towards the same goal for a while. The creator, CanadaHonk https://honk.foo >, is extremely talented and the project still only passes ~68% of Test262. I'm more than a little suspicious of how Vercel has made so much progress so fast, unless I'm misunderstanding the scope of this project.

> I'm more than a little suspicious of how Vercel has made so much progress so fast Coding agents. They landed 918,000 lines of code in a single week: https://github.com/vercel-labs/scriptc/graphs/contributors?s...

Christ. Imagine if bridges, skyscrapers, dams, cars, airplanes were designed and built like that.

I vibeslopped thousands of pages of blueprints, nobody reviewed them, but another team of digital monkeys with the intellect of an ant have already built the bridge, and it seems to not have collapsed yet, so we're already directing traffic there.

I can't imagine actual engineers feeling anything but deepest contempt for this industry.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#39
post #6

Earlier quoted context omitted.

> I'm more than a little suspicious of how Vercel has made so much progress so fast Coding agents. They landed 918,000 lines of code in a single week: https://github.com/vercel-labs/scriptc/graphs/contributors?s...

Christ. Imagine if bridges, skyscrapers, dams, cars, airplanes were designed and built like that. I vibeslopped thousands of pages of blueprints, nobody reviewed them, but another team of digital monkeys with the intellect of an ant have already built the bridge, and it seems to not have collapsed yet , so we're already directing traffic there. I can't imagine actual engineers feeling anything but deepest contempt fo…

"Actual engineers" don't really care about software engineering, much less a strong emotion at all like the "deepest contempt" and many of them already vibe code today for their work anyway.
Post reply on HN