47 ms·

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 buil

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.

rektide 4y ago
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 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-typescript-4-7/ https://devblogs.microsoft.com/typescript/announcing-typescr...
- zackify 4y ago
  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
  - rektide 4y ago
    > 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.
    - codethief 4y ago
      > 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?
      - rektide 4y ago
        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).
zackify 4y ago
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…
- rektide 4y ago
  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.
klodolph 4y ago
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.
- redox99 4y ago
  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.

rektide 4y ago

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 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-typescript-4-7/ https://devblogs.microsoft.com/typescript/announcing-typescr...

zackify 4y ago
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
- rektide 4y ago
  > 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.
  - codethief 4y ago
    > 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?
    - rektide 4y ago
      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).

zackify 4y ago

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…

rektide 4y ago
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.

klodolph 4y ago

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.

redox99 4y ago
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.