I've worked on dynamically typed code-bases in the past, and also on code-bases without formatters like prettier... and I'm not going back there.
So many odd bugs can be avoided simply by taking a little bit of time and declaring some types. It doesn't have to be a super fancy type-system (I actually prefer if it isn't), but I really want to know whether something is expected to be a string or a number, or what properties an object can be expected to have, or what values a literal can accept, and so on. It's just so frustratingly time-consuming to figure out in hindsight. And all for some person's odd perception of simplicity.
Same for formatters - all the squabbling over some personal preferences on how code should be formatted. Hell no. Let's install some opinionated formatter and let it do its job, I want to tackle more interesting problems than yet another narrow-minded discussion about necessity of semicolons, placement of whitespace or line-length.
I'm at a point where I straight-up refuse to work with people who prefer to work that way; or at least require them to be a few departments away from me. They can be programming gods; if they can't be arsed to type their code so I can immediately grok it, they can program elsewhere.
I sometimes write TypeScript for 2 hours straight without actually running the code or any unit test, and it would just work -- the return value is exactly what you want. I don't think I can do that for JavaScript for more than 15 minutes even though they are the "same language".
What exactly are you referring to? Specifically typescript has zero dependencies.
Generally speaking, I agree, the npm-ecosystem still has this pervasive problem that pulling one package can result in many transitive dependencies, but a growing amount of well-known packages try to keep it as limited as possible. Looking at the transitive dependency graph is definitely good (necessary) hygiene when picking dependencies, and when done rigorously enough, there shouldn't be too many bad surprises, at least in my personal experience.
this is the roadmap https://github.com/nodejs/loaders/issues/217.
We talked with the typescript team and we will give each other continous feedback on the progression. We made sure to take some precautions in order to avoid breaking the ecosystem. I still think in production, js is the way to go, so users should always transpile their ts files.
Could you expand on why transpiling is the right long-term strategy for production? I get that right now you don't support some TS-specific features like enums. Is that the concern? Those seem like a few legacy exceptions, new TS capabilities will be "just javascript".
Not transpiling would be great to reduce toolchain complexity and eliminate the need for sourcemaps just to understand exceptions and debug.
The first reason is because if we supported ts features that require transformation (such as enume) we would also need to support sourcemaps, so in the first iteration I decided not to, to avoid being overwhelmed. Right now we replace inline types with whitespace, so locations are preserved. We plan to add those features, probably behind a flag at the beginning. We need to move in small steps and think very carefully, every decision could make a huge impact on the ecosystem so I decided to start with the smalled subset possible.
That all makes sense, it sounds like you haven’t ruled out supporting TS directly in production, but it’s complex and you have to move carefully and you’re not sure if you’ll get all the way there. Is that right ?
Taking one link out of the toolchain (tsc) would already be a huge blessing.
And naive me hopes for a future where in my web-app I can set a policy that any non-ts, type-incompliant code is not allowed to run.
The amount of exceptions I get in the console from terrible garbage-code outside of my control but that I have to include because enterprise is staggering. Would love to have a meta-setting which would just kill them if they can't be arsed to even have a modicum of code-hygiene (sorry for the rant)
Why is taking out the part that actually checks the types at the developer's side a huge blessing?
Or if you are hoping to get the benefit of type checking in the browser itself (taking the same sweet time as tsc, but this time on every browser instead of once in the CI), then how long would you want to wait to be able to actually use the new typing functionality described in e.g. the latest TS annoucement? https://devblogs.microsoft.com/typescript/announcing-typescr... .
Because it would take a while until that would then become the standard and then become available in every browser. And you still need to provide the JS versions, because not every browser is going to support TS.
In the meanwhile you could just keep using tsc just as before and get access to new functionality immediately.
(I imagine you could run tsc in the browser right now if you really wanted to.)
> Why is taking out the part that actually checks the types at the developer's side a huge blessing?
Oh, no, certainly we want to keep type-checking in the pipeline, somewhere.
However, if the browser "understood" typescript, your codebase could have immediate hot-reload, without any transpilation in-between. The type-checking could then be (and already is when using something like esbuild/swc) an entirely separate process that happens independently.
Webpack's HMR is pretty good, but not having to modify the code at all to have it work in the browser, that'd be much much better :)
... the browser being able to typecheck (and reject violating code) itself is certainly something I'd love to see eventually, but fully agreed, this is not happening anytime soon.
In our codebase we started to disallow enums in favour of string literal types, and once folks get over the ingrained "this needs to be an enum" (coming mostly from other languages like Java), it's not much missed.
Enums are one of the very few things in typescript that seem to not have turned out that well, but it's relatively easy to work without them with string-literable types and such, derived from some const in case they're also needed at runtime.
I'm honestly giddy. This could be the (slow) beginning of a new era, where "JS with types" is finally a native thing.
I'm even willing to forgive all the mess that CJS vs. ESM is if they manage to pull this off.
I hope this sees widespread adoption/usage, which might finally cause some movement to integrate TS into ecmascript after all. Some dynamically-typed language fanatics (which are, in my opinion, completely detached from the reality that static types are what the vast majority of devs want) still have an iron grip on TC39, this might be the start of their end. And good riddance.
Yeah, my personal experience is that easily 95% of devs I work with/have met in person, if not closer to 99%, prefer statically typed languages. Maybe that’s a biased sample, but I do think the overall preference among devs is very strong. I also see JS slowly, more-or-less becoming TypeScript over time.
My days of being a real software developer are long behind me. So I'm totally willing to accept that I'm wrong here. But when I build a POC in particular, there's a LOT of power and flexibility granted by not giving a fuck about types. Suddenly I can accept non well defined data types (depending on my implementation) and can persist data that otherwise would have taken code changes and approval processes to accept. I do believe there is a place for types, but to type all the things is folly. There are capabilities within JavaScript to handle both.
It’s fine to have an escape hatch when you can’t figure/don't care about types (yes sometimes you should use unknown but that’s another topic)
But at least TS forces (if enabled by strict flag) you to explicitly mark all those places. You can always revisit them later.
Case in point: I’ve written A LOT of redux-saga code and figuring out types for that was exceptionally difficult for me. Sprinkled all that with a ton of anys. Had a few bugs but not anything serious.
Finally rewriting all that slop with async-await and am really happy about it
when I build a POC in particular, there's a LOT of power and flexibility granted by not giving a fuck about types
I find the same thing, but only for very small throwaway scripts and the like. For anything beyond like 20 lines of code, I rapidly hit confusing cases like “is this parameter just a map, or a map or maps?” Then I add types and it makes sense again.
Just use `any` or `unknown` when prototyping, then apply types once your happy paths start working for the first time to start catching the unhappy ones.
For sure, if I’m writing a short script, no more than ~200 LOC, Python (without type hints) is my favourite language. But for a sizeable codebase, worked on by multiple devs or even just me over time, I’ve got an extremely strong preference for static types.
Also, FWIW, TypeScript is the most “lightweight” statically typed language I’ve ever used, in terms of extra ceremony/lines of code over a dynamic language. Once you get used to its type system, and embrace the structural typing ideas, I feel the overhead is super minimal. It might slow me down by ~5% on a short script over JavaScript, while dramatically improving maintainability as a codebase grows.
This is not what GP asked for. That's the most requested feature from the state of JS survey.
I bet the percentage of web developers who want this are a tiny minority. There are just too many issues with this.
Static typing without the benefits of better runtime performance, soundness, strong typing etc. is basically just documentation/comments with extra steps.
Also TS is a complex, moving target. Most devs don't want to learn new fancy features every couple of months, but prefer stability guarantees. Several notable projects have moved away from TS. Even Ryan Dahl admitted that integrating Deno with TS was probably a mistake.
Meanwhile you have WASM slowly and steadily getting crucial features on a sound foundation.
I'm extremely cautious about TS and wary of the hype surrounding it.
> All of that is something that I consider to be platform-level
I agree with this, but the whole point of the blog-post is that the "platform" currently handles this rather poorly.
I have yet to see a frontend-project that was bigger than some three-person-garage-hobby that didn't occasionally run into CJS versus ESM issues. Maybe not something that pops up on the radar of all the devs in the project but at least at the level of folks who take care of the setup and whatnot, it often pops up in rather painful fashion. Case in point; a few angular-versions back, umd-bundles were dropped, which at least for the project I worked on caused me quite a lot of headache as some of our tool-chain (most notably our testing-setup) relied on angular shipping commonJS-compatible modules.
It's currently also a major pain for anyone publishing an npm-package, even if it's primarily intended to be run on node. The kind of incantations one has to do are just insane (especially if you dared to import from node:crypto or want to support more than just the latest lts); I've just stopped bothering after tearing my hair out for a weekend to no avail, even though I really wanted to support ESM as well.
> OSX sucks with 3 monitors and switches the output randomly when coming back from sleep/rebooting
This drives me nuts with my Mac at my workplace. It's mostly an awesome workhorse, but when I switched to Mac I was flabbergasted that this can be an issue.
The window-management I find also rather awful. When I asked the Mac-nerds I knew they all had their custom setup that includes some third-party-tooling, the built-in mission-control or whatever they call it didn't exactly receive favorable remarks...
There are some serious anti-proton-vibes in this thread, so just my 2 cents as a paying customer: I'm rather happy with their service. I pay them money, they make sure that Joe in Marketing won't be able to harvest data from my emails. I'm also fairly optimistic that they take security serious enough that the blast radius of some dataleak is hopefully very limited.
I have zero delusions however that they can protect me from state agents, let alone state agents with malicious intent. And I don't think it's realistic to expect that for the amount of money they cost. But that's fine with me - it's Joe from Marketing I'm scared about, and so far they seem to do a good job keeping Joe at bay :)
Seconded, happy Proton customer for years since de-Googling my life.
Par for the course at HN to have a "vaguely dislike-ish" relationship with Protonmail. Fastmail is the poster child of HN on the other hand.
I would guess the gist of it is that if you promise _any_ amount of security (or whatever feature), HN will nitpick you to death on not going 100% (despite the general improvement to your security). If you don't promise security at all, it doesn't matter that you're less secure than Proton. Something like that.
I've just been poking around at the Dropbox APIs recently when I got so frustrated by the fact that the Fastmail "attach from Dropbox" feature has been loading directly into my personal files space rather than showing the shared team folders since we switched over to using those last year - and I now have to download and re-upload files from those folders.
It's more than a glorified FTP. FTP does some heinous things with a separate control channel and stuff (let me tell you about adding encryption support to the Perl FTP server some other day), but this is next level!
It's not even as simple as just sending a fixed string in the "Dropbox-API-Path-Root" header for every API request (and they're all path based, so you have to make sure you always send that header or the paths won't parse right) - you have to get an ID for the real root, with a separate request, with a scope that we weren't requesting on refresh tokens.
So I hacked together something that worked on my testbed on the train ride home, but making it good is going to include adding a caching layer to the token refresh code, and suddenly it's not just a casual project. I'm still going to do it though, because dammit I have a file to attach to an email on Friday and I'm happy to spend hours on this to save myself 30 seconds.
I'm a free customer and I am always annoyed by ads in my inbox about other services provided by Proton. I signed up for an email box, I don't care about Proton Drive nor ProtonVPN. I chose Proton specifically because it supposedly had less or no ads at all, but it seems like Gmail continues to be the better choice.
Maybe this is disabled for free customers but at least for me there are settings to enable/disables what I kind of informations I'd like to receive from them.
Gmail in that regard I've always perceived as worse - every few months or so they update their policy, linking to some gargantuan document that I can't be bothered to read, each time wondering how much of my soul I've sold this time around...
I've worked on dynamically typed code-bases in the past, and also on code-bases without formatters like prettier... and I'm not going back there.
So many odd bugs can be avoided simply by taking a little bit of time and declaring some types. It doesn't have to be a super fancy type-system (I actually prefer if it isn't), but I really want to know whether something is expected to be a string or a number, or what properties an object can be expected to have, or what values a literal can accept, and so on. It's just so frustratingly time-consuming to figure out in hindsight. And all for some person's odd perception of simplicity.
Same for formatters - all the squabbling over some personal preferences on how code should be formatted. Hell no. Let's install some opinionated formatter and let it do its job, I want to tackle more interesting problems than yet another narrow-minded discussion about necessity of semicolons, placement of whitespace or line-length.
I'm at a point where I straight-up refuse to work with people who prefer to work that way; or at least require them to be a few departments away from me. They can be programming gods; if they can't be arsed to type their code so I can immediately grok it, they can program elsewhere.
reply