4 ms·
The power of web components is having the ability to develop complex front end without the need for a build tool in 2026. In 2008 when I got started with heavy
by shams93 3mo ago
The power of web components is having the ability to develop complex front end without the need for a build tool in 2026. In 2008 when I got started with heavy javascript jquery was a must have tool to fill in for all the horrible browser api incompatibilites at the time. But because we are just developing custom elements with vanilla it works fine with vue and rust and all the others.
- austin-cheney 3mo agoI write in vanilla TypeScript. I do not have any build step in my application. Since Node now supports native type stripping I don't have a compile step either. I just write my code and then point node at the main file, and this even includes front-end code for the browser.
- thisoneisreal 3mo agoCan 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.
- austin-cheney 3mo agoNode strips types on all imported code regardless of where that code executes.
- root_axis 3mo agoNode doesn't run in the browser.
- umvi 3mo agoPresumably 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.
- root_axis 3mo agoThat presumption is wrong, and doesn't quite make sense if you think about it.
- umvi 3mo agoWhy doesn't it make sense? I actually do exactly this in my own setup, but with golang instead of Node.
- root_axis 3mo agoI 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.
- umvi 3mo agoYou 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 https://pkg.go.dev/github.com/evanw/esbuild [2] https://nodejs.org/api/module.html#modulestriptypescripttypescode-options https://nodejs.org/api/module.html#modulestriptypescripttype... [3] https://github.com/bloomberg/ts-blank-space https://github.com/bloomberg/ts-blank-space [4] https://esbuild.github.io/api/#js-async https://esbuild.github.io/api/#js-async
- austin-cheney 3mo agoI am aware and it’s not what I said.
- root_axis 3mo agoYou literally said "this even includes front-end code for the browser". So what exactly are you referring to here?
- austin-cheney 3mo agoI 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.
- deleted 3mo ago[deleted]
- root_axis 3mo agoYou 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.
- austin-cheney 3mo ago> 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.
- root_axis 3mo agoYes, 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.
- tancop 3mo ago> develop complex front end without the need for a build tool zero build on complex front ends is disrespectful to your users. when you dont minify and code split you are basically saying "got a slow connection? tough luck, go wait for 10 seconds while this page loads 1.5mb of code that could be 5x smaller but i dont care enough to spend a couple minutes on a basic vite setup." you might get away with it when its a mostly static page with a couple lines of script but when its a bigger app users will notice. "just write less code" is not an option most of the time. and tsc is also a build tool so if you take it strictly you either get no type safety or get stuck with awful looking jsdoc comments that take up space in your final script file.