Hacker News Reader

Comment by klodolph | Hacker News Reader

I love this.

Maybe it means that I don’t have to preprocess / compile TypeScript before running it. This is a genuine win for me. The TypeScript compiler can continue doing what it does best—type checking—and then I can just run the code. Running the TypeScript compiler from a cold start takes a surprisingly long amount of time.

Currently, I have to figure out how to get a build system that compiles TypeScript once for bundling to the browser and once for running in Node, and the user experience around setting this up is just incredibly bad. It sucks. I make some change to how I build for browser and it turns out to be incompatible with whatever system I am using for Node. This solves part of that problem, and reduces friction. Type annotations can be just part of the JS and stripped out by minification.

View on HN

I’ve been writing Vanilla JavaScript with JSDoc annotations and using TypeScript as a type checker (as opposed to a compiler) for some of my hobby-projects, and it is amazing breath of fresh air from the bundler tool chains of the past.

As pointed out by this proposal the JSDoc annotations are—to put it mildly—a bit cumbersome. The more complicated types are close to impossible to figure out how to write, if they are possible to write at all. And on Q&A forums I constantly have to translate between the two syntaxes in my head, since most of the audience will probably not understand the JSDoc syntax.

Having a unified type annotation syntax which the runtime ignores will definitely make my life easier.

I can't do much without some degree of pre-processing. The browser can't resolve NodeJS-style require's, so I'll need a bundler to serve my app in a manner the browser can understand. I imagine most use cases today face this dilemma. It wasn't the type annotations holding me back for requiring pre-processing, it was the ecosystem around how JavaScript is written that is the primary factor.

That’s your use case, but it’s not the use case the standards bodies have in mind.

ESM imports are the standard, unlike Node’s require. And you can now write ESM code that’ll run flawlessly on the backend and the front end without any transpiration. IMO that’s huge. Type annotations remove yet another blocker.

I haven’t used NodeJS type requires in new projects since Node 12 (which EOL-ed last april). Most code I write now uses standard imports. There is off course some issues around resolving from npm but there are mitigations, and going forward import maps (already supported by Chrome) will solve most of these.

Really the only reason to do pre-processing is if you want to do some optimization beyond what the browser can do, or if you want to write a syntax which is not supported by your target runtimes. And for many developers (including most library authors) this is not the case.

So the moment a single library author doesn't support a target runtime I have, I have to pre-process. It seems to further the point that pre-processing is a critical step for many that isn't going away. Some projects like Angular are using non-standards compliant decorators, so until they re-think that decision, it's an absolute must for them.

It's really hard to guarantee a world where my complete dependency tree meets my target runtime requirements (eg: I might also not be using nodejs-style require, but my dependencies could be), so pre-processing seems like something that will be with us for some time.

I don't see what the issue is.

For backend node, you simply edit a couple of lines in the package.json to use ts-node during dev, and run tsc for shipping builds (a bit more performant than ts-node).

For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it. And if you do everything manually, considering you still need to setup babel, webpack etc, it makes almost no difference.

It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.

I have been trying to get ts-node to work consistently for, like, five years and it’s always a fucking battle. I can only conclude that either I have miserably poor JavaScript skills or you only work on really simple code bases where this works, or some combination of the two. It’s not just ts-node—it’s Jest and other tools, it’s configuring ES modules to work in Node or deciding to use require(), it’s fine-tuning your TypeScript configurations (plural), it’s a bunch of stuff.

> For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it.

My experience is that this stuff is always on the verge of breaking when you integrate it with some new dependency, when you have needs that are slightly different from the mainstream use-cases that the developers envisioned, or when you start going through and updating your packages.

I’ve been using JavaScript since the dark ages and the only way we can survive is by periodically cutting down some of the built-up complexity. We don’t need to cut it down for everyone, and not all at once, and no change is without its drawbacks. I’ve used create-react-app, I worked at a company that used machine learning in the JS build pipeline to do code splitting, I’ve used vanilla JS, and I’ve written some pretty damn cursed build systems for stuff like JS13K or 1K coding competitions. TypeScript sticks out as a rough spot in most build systems I’ve used, and the reason I still use it (most of the time—not always) is because the typechecking and IDE experience are just so damn good that it justifies the cost.

> It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.

Not every change is applicable to all uses cases for everyone. That’s ok. If you decide to write TypeScript without enums you usually find that you don’t lose that much—it’s easy enough to do something like:

    type LogLevel = "error" | "warning" | "info";

Obviously this is not a one-size-fits-all trick, but I find myself using TypeScript enums less and less these days.

There are also some dirtier TS tricks you can which let you create something kind of like Haskell’s newtype—pure type system stuff.

The last point you mention actually makes me think this is probably a harmful change, that could have a chilling effect. People only wanting to use the subset of TS that runs as JS, could hamstring future TS features, as well as limit current features usage for no good reason.

I have the exact opposite opinion.

TypeScript used to have more sugar, and that sugar had been removed and merged with the equivalent ES functionalities. Dig through old TS versions and you’ll find obsolete syntaxes or semantics that have been removed.

Just to pick an example, TS had class before JS. IMO the ideal scenario here is that TS is just type annotations on top of JS, and any features you use which aren’t universally available, you polyfill/transpile as a separate step.

This means TS is just types, and your transpired/polyfills are just transpilers/polyfills. To achieve that, TS classes are modified to match JS classes.

My sense is that TS will not add new stuff not in JS any more. It’s simply not a direction TS is going. I also get the sense that enums are a mistake in TS’s design.

TS in some sense is a reaction to the lessons learned from its predecessors, like CoffeeScript.

TS replacing it's own custom features if JS implements them is the correct move. But in my opinion they shouldn't hold back from adding features if they are good features.

TS goal IMO should be to offer the best developer experience, while maintaining interoperability with the JS ecosystem. Not just limiting themselves to types.

Why do you think enums are a mistake? Enums allow you to have autogenerated mappings from symbols to integers. You can't do that with types as you showed in your example.

TS should absolutely hold back from adding new features that are not in JS. That’s TypeScript’s niche—we already have other languages with new features, TypeScript works better as a typing system and nothing else on top of an existing language.

That’s why enum should be avoided in TS or added to JS.

I can understand why people want TS to be a “better” language, but these days, ES is pretty good and a major part of TS’s success is that it follows JS semantics almost everywhere.

> we already have other languages with new features

Not languages that can interoperate with JS the way TS does (except for flow and similar type checkers).

TS success is that it's a superset of JS (unlike say CoffeScript). So you can throw some JS and it will be valid TS. The point of being a superset is that you can add new stuff. Types, enums, annotations.

So the only argument why enums are bad except for that it's not in JS? Why does it matter, just because a JS developer has to learn more things if they switch to TS? The whole argument hinges on the premise that TS should not add anything that JS doesn't have except for types, but why is that?

That ship has already sailed, the TS team have been clear about not wanting to add features that aren't purely type-level for a long time. The suggestion issue template has a checklist requiring you check off that "This could be implemented without emitting different JS based on the types of the expressions" and telling you it realistically won't be implemented if not.

Well that's a pity. I find annotations and enums very useful, and wish we had more stuff like that.

I completely agree with you. You’ll want to remove them anyway. So you’re going to have a script run to strip them.

These hackernews developers always act like it’s the most blissful thing

“If only we could just write JS without running a special transpile command”

That’s actually a much worse developer experience. If you’re using any modern frontend technologies, you’ll want to have a dev server running.

Using hot module replacement at a bare minimum (where your browser updates the screen without doing a page refresh, instantaneously)

Is a much better experience, so you should already be running a dev server anyway if you’re being productive is the point…

This is true (ish, sort of, today) when you work for a corporation & have either years of experience or people backing you.

It completely ignores what it takes to get started, or how alive & malleable the web is.

The domination of concerns by deeply deeply industrialized ways of thinking holds back the joy of the hypermedium we work. And it truncates human potential. Making code & coding accessible is a virtue. One that could cost us nothing.

How many years have you been doing this? How many hours have teams you've worked on spent configuring build pipelines? How many people have you seen to go other mentors or helpers in your org when they are setting up a new project? How many many times have you seen someone start from from nothing & be done in <1 hour?

This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are.

It also misses one of the biggest harms. It doesn't consider what a pain in the ass it is when the source/libraries you are consuming have already been downcompiled into lesser JS via someone elses perhaps-poorly configured build pipeline. I'd guess that >80% of TypeScript modules don't export ESM right now. TypeScript 4.7 is about two weeks old & it's the first time TypeScript and Node's ESM play well[1]. Because it all involves complex transpilation. How many modules do you think will get updated, ever?

You know what would be great? If we could just write code. If we didn't have to worry about build pipelines. If my toolchain could make what it would of other code, be it JS or JS+TypeScript Type Annotations or JS+Flow Type Annotations.

> "For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever" "For backend node, you simply edit a couple of lines in the package.json"

The amount of dissympathy for the real complexity here, for how hard a couple specific projects have worked to make things "just go" is staggering. The amount of ink spread to support, the amount of stack overflow questions struggling through, is probably enough to reprint the Apollo Missions guidance software a couple times over.

This is hard stuff. It's complex & interlinked. There are not singular solutions; there's many many interlinked & complected tools & systems & options.

Easing the path back towards- it will work. Towards just being able to ship code, without necessarily needing to typecheck it, transpile it, downcompile it: it helps a huge range of people who are really really in need of help. Who don't have teams, companies, support. Who just want to start to learn, want to start to get going. This change may or may not (I'd argue more that it may but...) have huge impact on your life as a highly-late industrial supercorp developer, but it has huge impacts on the ecosystem, it's approachability, it's friendliness. Writing all that off, just pretending we have some magic wands we can wave & these dilemnas, these pitfalls, are not really here: woe be un to us if we are not willing to assess the real cost of this all. I can't see your post as taking for real the costs.

JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy.

[1] https://devblogs.microsoft.com/typescript/announcing-typescr...

> How many years have you been doing this?

Over a decade, before all these tooling existed.

> This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are.

I know build systems can get very complicated, in fact it's part of my point. Which is that considering you already need to set up a build pipeline, adding typescript support is quite simple.

> You know what would be great? If we could just write code. If we didn't have to worry about build pipelines.

But that will not be the case. People are not FTPing their dev folders into prod anymore. Even with this change, you will still need a build pipeline, as everybody already does regardless if they use TS or not.

> JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy.

I disagree with this. That's probably nostalgia talking. Slapping some script URL and editing with Notepad++, having absolutely no IntelliSense, no errors/squiggly lines and having to F5 a browser after every change, trying to hit the code path in question and check the browser console for errors was awful.

Nowadays the editor will tell you what's wrong as you type it, the browser will automatically refresh the code while maintaining state and so on.

Your development bias reflects that of a decade+ wisened & mature developer, well set up, prodyctive with great tools in your toolbelt.

I think you conflate the development environment with the hypermedium. You stick lo-fi tools with shame, but you're not actually talking to the language & it's lightweight versaility & hackability. You're not talking to the editability, the malleability, & simplicity of the medium as it was, and which, if we can do just a little bit of healing, can be again.

> Even with this change, you will still need a build pipeline

Will we? Why? I tend to wager a decent static webserver (especially one that has decent cimpression built in) will be a very fine deploy target for many again, soon. ESM, early-hints, http3... it could happen. Yeah we probably should strip comments & these type annotations, but need to? Meh. I think we fret too much about the small stuff & havent spent nearly enough time conisdering incremental loading architectures & better use of service workers. The endless pish for optimizing what we have has been a race of folly ignoring the real peaks around us daring us to be summited.

JS can & should be less build intensive. Non-build module-using js was the high fantasy we were driving for a decade ago, when the idea of modules was new, & it's been slow, but that objective was there for really good & importamt reasons. A js which is naturally accessible, which is evident & real, is good for humanity & how the web reconnects with itself as a hypermedium, as more than just another shitty developer app-dev toolbox for nerds like us. We can be better. We can make the source real again.

> Will we? Why? I tend to wager a decent static webserver (especially one that has decent cimpression built in) will be a very fine deploy target for many again, soon. ESM, early-hints, http3... it could happen. Yeah we probably should strip comments & these type annotations, but need to? Meh. I think we fret too much about the small stuff & havent spent nearly enough time conisdering incremental loading architectures & better use of service workers. The endless pish for optimizing what we have has been a race of folly ignoring the real peaks around us daring us to be summited.

Even with http3 and so on, serving node_modules which almost always is 100k+ files would be awful. And of course, yes, you don't need npm. But I don't see people going back to the jquery days of having a single o no dependencies.

I guess the point stands for new people learning web development who are only playing on localhost and don't care yet about having something good enough for prod. But I don't think people who are at that stage should worry about typescript. If they did and didn't want a build pipeline, they would just manually run tsc. Is adding a new feature to JS just so that beginners who want to use TS don't need to run tsc worth it? IMO no.

80% of typescript modules don’t export esm? What?

Most people write code using esm for the past few years. If anything the problem is that shared libraries are only exporting esm so tools like jest that still require commonjs don’t work.

Just use Tsdx or other tooling to automatically expose the different bundle types.

Even still, if JS developers took the time to understand the different module types we would be in a much better place on the shared packages front

> Most people write code using esm for the past few years.

But what do they target? TypeScript projects targetting only es2015 or only cjs are all too numerous.

Much of nobility of this Type Annotations work is we could (potentially) stop transpiling. The source could be the source.

> Just use Tsdx

Just use ____ is the center square of the JS bingo game. It's a terrible answer, but it's almost always the answer, and the answer always changes.

That there's an ever rotating constellation of "just use" answers to newcomers questions, all of which are semi-required "zero configuration" "just works" new tools to fix the previous pile of cobbled together stuff: painfully Python-esque.

> painfully Python-esque

I agreed with every single thing you wrote until that last line. In what universe is the ever-changing mess that is the JavaScript ecosystem even remotely comparable to the Python ecosystem?

A not unreasonable call out at all. The multi-layers of pip, setuptools, easy_install, virtualenv stuff made me very sad at the time. Nodejs was such a relief at the time.

My understanding is recently Python docs have started to encorporate a little more guidance on handling dependencies in virtualenvs, and some specific suggestions & write up about tools. Which is great.

I think your right that JS probably has a lot more build/compiling/lifting machinery, & is much more confusing. To be fair, it also has a much harder job (since the build-target is only sometimes the local machine).

The confusing thing is that even though we have all been writing import statements in Typescript, that is not the same as ESM. Now, even though we all think we have been using ESM, when libraries only export ESM our tools/build chains are not compatible.

This episode isn't 100% current, but still relevant and discusses this issue: https://changelog.com/jsparty/137

This is the reason I don't use the typescript compiler and instead use babel to strip the types out completely on compilation. I use vs-code's built-in type checking when coding in dev and then throw out types in prod. Fast dev builds and still get all the type checking I want. Optionally you can run the full blown typescript compiler as part of CI/CD if you want to ensure no errors or warnings hit prod.

That "optionally" is going to bite you in the arse as soon as you have more than one person working on the project.

esbuild works well.

Reply on news.ycombinator.com