Hacker News Reader

Comment by thisoneisreal | Hacker News Reader

Can you explain more about how the front end aspect works? I'm not clear how the front end code could by TypeScript without a build step, unless I'm misreading.

View on HN

Node strips types on all imported code regardless of where that code executes.

Node doesn't run in the browser.

Presumably Node is the server (back end), and when the browser requests a TS file, Node is stripping the types before serving it to the browser.

That presumption is wrong, and doesn't quite make sense if you think about it.

Why doesn't it make sense? I actually do exactly this in my own setup, but with golang instead of Node.

I don't know what tooling you're using in go, but node does not do any kind of transformation to assets it serves over http. Running logic written in TypeScript on the front end requires some kind of bundler so that the browser can run the code.

You don't need a bundler, just a type stripper. And yeah you need a middleware to perform the type stripping, the server won't do it automatically, but it's like 10 lines of backend code. The basic flow would be something like:

1. Browser requests /js/foo.js

2. Server middleware checks if /js/foo.ts exists

3. If yes, server middleware strips types from the file before returning it

In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly. The middleware looks like this:

``` return esbuild.Transform(string(fileBytes), esbuild.TransformOptions{ Loader: esbuild.LoaderTS, Format: esbuild.FormatESModule, }) ```

It only takes a few microseconds and I don't need any bundlers or tsc or anything like that. Everything on my frontend is 100% vanilla TS; I make changes directly to TS and then hit refresh in my browser and the changes are reflected instantly without needing a bundler or even node/npm for that matter. Note: for this setup to work, your front end TS has to use ES modules import/export which browsers natively support. If you try to use CommonJS or something like that, you would start needing a bundler again because browsers can't resolve "require" statements.

In node it should be even easier than Go because Node added native type stripping starting with v22[2]

But even on older versions of Node, a type stripping middleware would still be very easy to implement[3][4].

[1] https://pkg.go.dev/github.com/evanw/esbuild

[2] https://nodejs.org/api/module.html#modulestriptypescripttype...

[3] https://github.com/bloomberg/ts-blank-space

[4] https://esbuild.github.io/api/#js-async

> It only takes a few microseconds and I don't need any bundlers

And yet you're using one. Esbuild is one of the most popular bundlers in the js ecosystem, your workflow is functionally identical to any other bundler workflow except that the example you provided is worse than the typical workflow because it builds the ts file on every request rather than just once when the source code changes.

> And yet you're using one

I'm using a TS type stripper API from a go package inside the server. I'm not actually doing any "bundling" which implies resolving imports, tree shaking, combining multiple files into one, minification, uglification, etc. I'm strictly stripping out types and serving what's left directly to the browser. This costs less than 1ms of cpu time on a cold load (and usually costs nothing because of front-end caching/etags)

Look, I don't want to argue with you. Just sharing my setup. I develop medical device software which means dependencies are very expensive because they incur regulatory burden. SBOMs and associated CVEs have to be tracked and reported to the FDA. My TS/golang stack means:

- My docker images can be from scratch or from busybox with a statically linked go binary

- My frontend can be vanilla TS with zero dependencies (npm or otherwise)

- Debugging is dead simple: set breakpoints directly in dev tools and it's WYSIWYG (no map files needed, etc)

- Feedback is instantaneous. If I change a file in TS and hit refresh, the change is reflected instantly (compare to bloated Vue/React shops I've seen where every change requires a 10 second frontend compile pipeline to run before you can get feedback in the browser)

I am aware and it’s not what I said.

You literally said "this even includes front-end code for the browser".

So what exactly are you referring to here?

I write all my application code in TypeScript, even if it is for the browser. I then import all that code into Node regardless of whether it will execute in Node. All code that will not execute in Node needs to be wrapped in a function for safety, because global references like "document" or "window" will not work in Node.

You write all your code in TS - great.

You run node with the TS support - great.

That doesn't explain how your front-end TS code is transformed into JS. You seem to be suggesting that node does it automatically, but it doesn't. The explanation of your setup isn't adding up.

> That doesn't explain how your front-end TS code is transformed into JS.

Node will do that at run time. Its automatic. Functions do not have to execute to receive this benefit. They just have to be imported. Ensure you are using a very recent version of Node.

Yes, but how does your http server deliver the imported code to the front-end? Are you using some type of streaming bundler that does real time builds? Something isn't making sense here.

On application startup I assemble together the various front end files I need and store this in memory as a string. When the server sees a request for the desired page I respond with the desired string.

Since I am not handcuffed by some giant framework I have maximum flexibility to do what makes sense.

> On application startup I assemble together the various front end files I need and store this in memory as a string.

So in other words, you created your own bundler?

Node isn't actually doing the work for you on the front-end.

Again, I never said Node is did anything for the front end.

Again, yes you explicitly did:

> I just write my code and then point node at the main file, and this even includes front-end code for the browser.

It sounds like you're just making stuff up.

If you hire me as a consultant I will do it for you at $150 per hour.

You said:

> I just write my code and then point node at the main file, and this even includes front-end code for the browser.

Then you said:

> I never said Node is did anything for the front end.

So which is it?

Since you need just a little help…

Yes, I push all my TS code through Node for type stripping. No, Node is not executing browser code. No, I am not suggesting Node is running in the browser.

For extra extra extra clarity importing functions in JavaScript does not execute them. They still have to be called for them to execute.

I am still willing to fix your code for a consultation fee.

yeah this is a bit confusing. so you strip the types from the frontend and serve the .ts file as .js file? That's a transpiler/bundler.

Confusing or not it works for me. No compile step and no build step. The application starts up in 0.2 seconds on Linux and about 1.2 seconds on Windows.

it is confusing the way you are explaining it, so much that even you can't understand.

You do have a build step, you just think that doing that using node script is the same as not having one, I guess.

Yeah, IMO they are just making stuff up. Even as explained what they're saying makes no sense. Ultimately, there needs to be some entrypoint into the client-side script, node has no built in way to serve source code it's type-stripped over http.

If Node is your web server then node does have a way to serve the code to the browser... or you could just have node write the stripped code to a file for your other web server. It sounds like you are not even trying to think through this. I recommend putting fingers on keyboard and just trying to find your way through the solution instead of complaining about how impossible life is.

> I recommend putting fingers on keyboard and just trying to find your way through the solution instead of complaining about how impossible life is.

I recommend you stop making stuff up online. We're 10 layers deep into this thread and you still can't explain how any of this works in a coherent way.

If any of this is real, why don't you attach a link from the node documention or an article that explains this technique that allows node to serve type stripped imports over http.

I'm not asking for a link to the http stack, I'm asking you to explain how you run a node app that consumes your typescript source code and serves it over http without a bundler.

guy really think everybody is a JS-framework user so he can drop a few words and get away with saying things that doesn't make sense.

But in the last post he kinda explained that he uses a node script to convert TS to JS. He is just confused.

Reply on news.ycombinator.com