8 ms·

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators.

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators to be added when it was still stage 0. In exchange, they forfeited continued work on their would-be competitor to TypeScript. Even without the Decorators thing, Angular was intensely popular and it made a big impact how they went "all in" on TypeScript, pushing a lot of early adoption. I know lots of people that first started with TypeScript because of work on an Angular project. I think a lot of people don't seem to know/remember how touch-and-go TypeScript was in the very early days. There were many large projects that were all-in on FlowType, and others still that were pushing for Elm, etc. For example, it took quite a while for you to be able to do JSX _at all_. Today, we just have TypeScript. Well. I do know one company that uses ReasonML (or isn't it called Rescript now?) --- Historical stuff aside, I'm extremely happy we ended up with TypeScript over the others because the team is so incredibly awesome and dedicated. It's rare you see such a large project so well shepherded by such a talented set of individuals. It speaks volumes that the average tenure on that team is so high. We've seen some public apologies from the Flow team on this topic so I don't feel like I'm talking behind anyone's back if I say they ended up truly not being up to the task of being what TypeScript is today.

deleted 4y ago
[deleted]
JamesSwift 4y ago
One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.
- dimitropoulos 4y ago
  Same. I spent the next few years doing major refactors from Flow to TypeScript (the largest that's public was for Insomnia: https://github.com/Kong/insomnia/discussions/3654 https://github.com/Kong/insomnia/discussions/3654).
- latchkey 4y ago
  I'm curious what criteria you used to pick Flow vs. Typescript.
  - myth_drannon 4y ago
    Flow allowed gradual typing of the project and Typescript forced you to convert everything at once(at least the first versions of TS)
  - dimitropoulos 4y ago
    for a lot of people it was some combination of: - Flow has more adoption (it did, for a while, in the OSS sphere) - Microsoft is evil (remember, this was before everyone was using VS Code and loving it. (Also, tautologically, TypeScript has been one of the biggest things that changed this public perception for the people I hang around)) - Facebook is awesome (oh, how times have changed...) - Flow has total type soundness as a goal (from the beginning, and through to today, TypeScript still lists this as an explicit non-goal) - You literally cannot use React and Flow together (it didn't support JSX for what felt like an eternity and Flow did from the beginning (I think?). - Flow had exact object types (TypeScript _sorta_ has this today, but most people don't know to turn it on because it isn't in the strict-mode family: exactOptionalPropertyTypes) - Flow had more features (and was faster) - DefinitelyTyped didn't exist yet, and it was easier to find types for Flow (but, let's be real, both had nearly nothing compared to today)
    - RyanCavanaugh 4y ago
      Total type soundness is not a goal of Flow. For example, array bounds are not considered. Flow considers this program to have no errors, but TypeScript (with the correct option enabled) will: let m = [1, 2, 3]; console.log(m[4].toFixed()); Also, DefinitelyTyped itself launched before Flow (2012 vs 2015), so the timeline on that point isn't right.
martypitt 4y ago
I remember this well. From the outside, it seemed a fantastic example of collaboration between two separate (competing?) teams. It took humility and pragmatism for the Angular team to abandon AtScript and recognise TS as the better long-term bet.
agency 4y ago
I have often thought that it must have been tough to be on the Flow team. It was pretty good, and absolutely would have been "good enough" to catch on if it weren't for TypeScript. But ultimately the better language won.
- epolanski 4y ago
  Flow ultimately served only Facebook purposes and their work and the evolution of the language wasn't on par with TS.
- dimitropoulos 4y ago
  And it doesn't hurt that the TypeScript team is so great. We've seen some public apologies from the Flow team on this topic so I don't feel like I'm talking behind anyone's back if I say they ended up truly not being up to the task of being what TypeScript is today.
  - maxloh 4y ago
    Any links to their apologies? I don't understand why they apologized.
    - RyanCavanaugh 4y ago
      I presume they're referring to https://medium.com/flow-type/clarity-on-flows-direction-and-open-source-engagement-e721a4eb4d8b https://medium.com/flow-type/clarity-on-flows-direction-and-...
      - dimitropoulos 4y ago
        yes exactly. The only other context I'll add is for people shipping Flow that I knew at the time they felt that this announcement felt like it came about two years too late. I had already switched to TypeScript long before because, in part, of the things they're apologizing for in that article which were evident long before being said out loud. I say that with great reverence and respect for the people that worked so hard on Flow, by the way, but that's the situation I experienced.
epolanski 4y ago
True, Angular was crucial for adoption of TypeScript 5+ years ago but I think the community would've migrated nonetheless.
- dimitropoulos 4y ago
  for sure for sure. that's kinda the point though: they already were migrating... to Flow. Lots of big projects are on the list that had to change course later because TypeScript won: - Yarn - Jest - Luxon - Gatsby - Expo - Styled-Components - GitKraken - GraphQL-js and that's just off the top of my head. I'm sure there were many more.
  - davnn 4y ago
    Do you have the impression that Flow once had greater adoption than TypeScript, or that there was a movement from TypeScript to Flow? I think it was always behind in adoption, but of course, some projects used it anyways. From my memory, Flow always felt like the less conservative cousin and it was tempting to use it, but TypeScript always was the safer bet.
    - dimitropoulos 4y ago
      I have to disclose my potential bias here because I am these days very involved in the TypeScript world (with Michigan TypeScript). That said, I would never hide the fact that I was once a die-hard Flow person that.. died hard, haha. (and I'm very glad I did! more on that later) In the very early days (in every circle I was in) Flow was ahead by every measure (known examples, excitement, adoption, features, speed, etc). You could point to real live running apps like GitKraken and Discord (hopefully my memory isn't failing me on those) that where shipping Flow very early. And you could use JSX! At the time there was literally no known project (especially OSS) actually shipping TypeScript. Not from Microsoft and not from anyone else. It was hard to tell if TypeScript was more of "embrace extend extinguish" (obviously with hindsight we can be absolutely certain that it wasn't that (unless we're talking about a decades long "long con" lol)) But there's something I could never have anticipated at the time that's more important to me today than any feature of the language: The TypeScript team have done a breathtakingly amazing job of carrying the project through the years. TypeScript, as an open source project, is an absolute triumph: and I think it has everything to do with the people behind it. At this point TypeScript is "good enough" in every way that really matters. If they consciously stopped developing the language and just focused on performance and bugs I think we should all call that a success. I really believe it's been handled _that_ well. Meanwhile Flow went the other direction and there were bugs (in the 0.30 era, approximately) that had people pulling their hair out that were caused by the impedance mismatch of them making it for Facebook first and the rest of the world last. As far as I can tell, this really never changed (or at least, if it did, then maybe it was "too little too late"). Meanwhile, it seems like TypeScript has been managed with the literal opposite mindset: putting us in a situation where only one major project is left using Flow... React. There are other projects like ESLint that have been... how do I say this in a not bridge-burn-y way... surprisingly reluctant to realize that TypeScript isn't some passing fad. But I'm confident that they're going to have their wakeup call sooner or later. The culture of JavaScript-land is just not loyal enough for gatekeeping a technology like TypeScript. Look at webpack. We all spent nights and weekends for years gaining knowledge on how it works and weeks per year getting familiar with it, then esbuild happened and we threw webpack away overnight like it never even happened. I believe the same fate awaits projects that deny the necessity of writing in TypeScript at this point in history, with the possible singular exception of React.
skratlo 4y ago
We have WASM dude. But TS people are in TS bubble for what it's worth.
- yCombLinks 4y ago
  It's not worth anything. Are you writing raw WASM?
- swatcoder 4y ago
  WASM and TypeScript don’t really compare or compete. I’m not sure what you’re saying.
- mc10 4y ago
  Until WASM can touch the DOM you’re still going to need JS (and hence, TS).
  - oaiey 4y ago
    And objects. And so many more things. Wasm is a cpu or low level operating system and not programming language
  - nicoburns 4y ago
    In fairness, rust-in-wasm has pretty complete DOM bindings. You can quite easily write DOM manipulation code in Rust without ever touching JS/TS. Whether that's a good idea is another matter.
    - maxloh 4y ago
      How does that work?
      - amaranth 4y ago
        web-sys[1] generates the binding code using the same IDL files that browsers use to generate their JS bindings to the C++ doing the actual work. [1] https://github.com/rustwasm/wasm-bindgen/tree/main/crates/web-sys https://github.com/rustwasm/wasm-bindgen/tree/main/crates/we...
cies 4y ago
> and others still that were pushing for Elm Still pushing for it. TS is like make-up on a pig, compared to Elm. > I do know one company that uses ReasonML (or isn't it called Rescript now?) Re* is also a better alternative imho. Better interop with JS/TS is very nice. But in place one could use Elm, I'd say it certainly wins in the "clean" reward.
spankalee 4y ago
AtScript was always stillborn, and the Angular team absolutely could not have made a competitor to TypeScript.
- dimitropoulos 4y ago
  Agreed, but the point I was making here is that Angular itself was very far from stillborn, it pushed early adoption of TypeScript really really hard which did wonders for TypeScript to be taken seriously.
- zaphirplane 4y ago
  Wonder why they didn’t go with the other google language Dart Too foreign to frontend audiences? It has a lot of fans in flutter
  - jsyolo 4y ago
    There was AngularDart, don't know what happened to it.
    - pax_americana 4y ago
      Publicly it's dead, but it's alive and well and constantly getting updated inside Google.
no_wizard 4y ago
>Today, we just have TypeScript. Well. I do know one company that uses ReasonML (or isn't it called Rescript now?) One company outside Meta?
- dimitropoulos 4y ago
  yes! haha. They love it. I ping them and see if they want to identify themselves.
  - armacham 4y ago
    FB migrated all of its ReScript to Flow and deleted the ReScript.
- illusionalsgcty 4y ago
  There's definitely a few around that are using ReScript; we've been using ReScript for production services for a bit more than 2 years now at Autobooks. https://rescript-lang.org https://rescript-lang.org has a list too
throw_m239339 4y ago
> Without Angular, we may very well not have TypeScript today. Typescript was started at Microsoft by the guy who designed Turbo Pascal and C#, so completely independently from Google's Angular team. Angular had its own "AtScript" and eventually ditched that. Typescript had experimental decorator support well before Angular Team moved from AtScript, because it was a ECMAScript proposal. Angular had zero influence in the design or success of Typescript. Typescript however does support JSX optionally so one can claim that React DID influence Typescript's design decisions.
- dimitropoulos 4y ago
  Even if that's true (it's definitely not how it was depicted at the time at conferences and from people on the Google side).. the point stands Angular was absolutely huge for it's day and they pushed TypeScript really really hard. It was a truce between two huge companies and it made waves in terms of people trusting Microsoft. I have personally never been one of those mega Microsoft haters but I witnessed shouting matches in the office from people that we're hotly opposed to TypeScript being added to the codebase against others using Angular as a core motivation in many of their counter-arguments. I'm super glad we have TypeScript one way or the other because the team is so dedicated to OSS.
  - throw_m239339 4y ago
    > Even if that's true (it's definitely not how it was depicted at the time at conferences and from people on the Google side).. the point stands Angular was absolutely huge for it's day and they pushed TypeScript really really hard. It was a truce between two huge companies and it made waves in terms of people trusting Microsoft. Angular.js was huge, by the time Angular version whatever because it was always changing, figured out what it wanted to be, most front-end developers already moved to React. What Microsoft product uses Angular? Doesn't Teams uses Angular.js but not Angular? and what does a Google conference has to do with Microsoft? Nothing.
- styfle 4y ago
  > Typescript had experimental decorator support well before Angular Team moved from AtScript Do you have a source for this. My memory isn't so good but I seem to remember that the Angular team pushed to get this Stage 0 proposal implemented even though the TypeScript team usually waits until Stage 2 or 3 to implement.
giraffe_lady 4y ago
god just think how good life would be if we had all switched to elm or reason instead.
- roebk 4y ago
  there's not a day that goes by that I don't think about this
- iudqnolq 4y ago
  If only Elm was infinitesimally less pure.
- rk06 4y ago
  Elm was never an option with how hard it is on "no js" policy
nikeee 4y ago
I remember this well, too. Ironically, I think that angular is the framework that benefits least from actually using TypeScript. There is a separate templating language that's only type-checked if you set the right compiler options. JSX is much better suited for that. Being OOP like angular, it often requires opting out of null-safety or init-checks, because something is late-initialized. Having mutable instance state results in less opportunities to be more strict with typing. Its good that the TS team decided to align with the ES standards. Initially (talking like v0.8.0), I had the impression that they're building a "C# for the web", being incompatible with ES. Maybe that's why enums and namespaces were added and initially, the boolean was named bool.
- WorldMaker 4y ago
  Enums have been proposed for JS for quite a while (there was a sort of enum in "the lost version" ES4 and a TC-39 proposal stuck in Stage 0 for years now [1]). Enums have always had relatively simple JS output that resembles a somewhat common pattern in JS. It was a "standard", just never really a deeply adopted "standard". What's today called "namespaces" in Typescript was originally called "modules" and then "inner modules" (to differentiate from "exterior modules") and is a tiny simplification on a JS pattern that was extremely common at the time of Typescript's inception called at the time "IIFE modules". "namespace" is a very C# name chosen in desperation (when it became clear that "exterior modules" were the present not just the future of the language and "interior modules" was too confusing a term to live), but it's a very old (and used to be extremely common) JS pattern that TS gave a tiny bit of syntax sugar to. It was a "standard" that existed at the time that was (rightfully) killed by AMD/UMD/CommonJS/ESM, but it is hard to fault the Typescript team at the early 0.x days thinking the "Stage Wild" JS pattern would possibly live on for many years to come. (This is also relevant to the patch notes for Typescript 5.0 as 5.0 is the first version [!] to itself be written as [proper/"exterior"] modules rather than namespaces. There are some interesting stories, including in these release notes for why that took so long to transition and what the performance benefits have been post-transition.) Even those things that didn't seem like ES standards have some history as JS "standards". It's not like TS 0.x/1.x didn't support "standards", it is more that the TS team mostly decided to focus more on later stage ES standards (more likely to be accepted by browsers) rather than trying to "prollyfill" Stage 0 and "Stage Wild" standards. [1] https://github.com/rbuckton/proposal-enum https://github.com/rbuckton/proposal-enum
truth_seeker 4y ago
Yep. Frameworks play an important role in end user (developers) helps deliver software as quickly as possible. Just like without Rails framework, we may very well not have Ruby today. Also, without WordPress, we may very well not have PHP today.

deleted 4y ago

[deleted]

JamesSwift 4y ago

One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.

dimitropoulos 4y ago
Same. I spent the next few years doing major refactors from Flow to TypeScript (the largest that's public was for Insomnia: https://github.com/Kong/insomnia/discussions/3654 https://github.com/Kong/insomnia/discussions/3654).
latchkey 4y ago
I'm curious what criteria you used to pick Flow vs. Typescript.
- myth_drannon 4y ago
  Flow allowed gradual typing of the project and Typescript forced you to convert everything at once(at least the first versions of TS)
- dimitropoulos 4y ago
  for a lot of people it was some combination of: - Flow has more adoption (it did, for a while, in the OSS sphere) - Microsoft is evil (remember, this was before everyone was using VS Code and loving it. (Also, tautologically, TypeScript has been one of the biggest things that changed this public perception for the people I hang around)) - Facebook is awesome (oh, how times have changed...) - Flow has total type soundness as a goal (from the beginning, and through to today, TypeScript still lists this as an explicit non-goal) - You literally cannot use React and Flow together (it didn't support JSX for what felt like an eternity and Flow did from the beginning (I think?). - Flow had exact object types (TypeScript _sorta_ has this today, but most people don't know to turn it on because it isn't in the strict-mode family: exactOptionalPropertyTypes) - Flow had more features (and was faster) - DefinitelyTyped didn't exist yet, and it was easier to find types for Flow (but, let's be real, both had nearly nothing compared to today)
  - RyanCavanaugh 4y ago
    Total type soundness is not a goal of Flow. For example, array bounds are not considered. Flow considers this program to have no errors, but TypeScript (with the correct option enabled) will: let m = [1, 2, 3]; console.log(m[4].toFixed()); Also, DefinitelyTyped itself launched before Flow (2012 vs 2015), so the timeline on that point isn't right.

martypitt 4y ago

I remember this well. From the outside, it seemed a fantastic example of collaboration between two separate (competing?) teams. It took humility and pragmatism for the Angular team to abandon AtScript and recognise TS as the better long-term bet.

agency 4y ago

I have often thought that it must have been tough to be on the Flow team. It was pretty good, and absolutely would have been "good enough" to catch on if it weren't for TypeScript. But ultimately the better language won.

epolanski 4y ago
Flow ultimately served only Facebook purposes and their work and the evolution of the language wasn't on par with TS.
dimitropoulos 4y ago
And it doesn't hurt that the TypeScript team is so great. We've seen some public apologies from the Flow team on this topic so I don't feel like I'm talking behind anyone's back if I say they ended up truly not being up to the task of being what TypeScript is today.
- maxloh 4y ago
  Any links to their apologies? I don't understand why they apologized.
  - RyanCavanaugh 4y ago
    I presume they're referring to https://medium.com/flow-type/clarity-on-flows-direction-and-open-source-engagement-e721a4eb4d8b https://medium.com/flow-type/clarity-on-flows-direction-and-...
    - dimitropoulos 4y ago
      yes exactly. The only other context I'll add is for people shipping Flow that I knew at the time they felt that this announcement felt like it came about two years too late. I had already switched to TypeScript long before because, in part, of the things they're apologizing for in that article which were evident long before being said out loud. I say that with great reverence and respect for the people that worked so hard on Flow, by the way, but that's the situation I experienced.

epolanski 4y ago

True, Angular was crucial for adoption of TypeScript 5+ years ago but I think the community would've migrated nonetheless.

dimitropoulos 4y ago
for sure for sure. that's kinda the point though: they already were migrating... to Flow. Lots of big projects are on the list that had to change course later because TypeScript won: - Yarn - Jest - Luxon - Gatsby - Expo - Styled-Components - GitKraken - GraphQL-js and that's just off the top of my head. I'm sure there were many more.
- davnn 4y ago
  Do you have the impression that Flow once had greater adoption than TypeScript, or that there was a movement from TypeScript to Flow? I think it was always behind in adoption, but of course, some projects used it anyways. From my memory, Flow always felt like the less conservative cousin and it was tempting to use it, but TypeScript always was the safer bet.
  - dimitropoulos 4y ago
    I have to disclose my potential bias here because I am these days very involved in the TypeScript world (with Michigan TypeScript). That said, I would never hide the fact that I was once a die-hard Flow person that.. died hard, haha. (and I'm very glad I did! more on that later) In the very early days (in every circle I was in) Flow was ahead by every measure (known examples, excitement, adoption, features, speed, etc). You could point to real live running apps like GitKraken and Discord (hopefully my memory isn't failing me on those) that where shipping Flow very early. And you could use JSX! At the time there was literally no known project (especially OSS) actually shipping TypeScript. Not from Microsoft and not from anyone else. It was hard to tell if TypeScript was more of "embrace extend extinguish" (obviously with hindsight we can be absolutely certain that it wasn't that (unless we're talking about a decades long "long con" lol)) But there's something I could never have anticipated at the time that's more important to me today than any feature of the language: The TypeScript team have done a breathtakingly amazing job of carrying the project through the years. TypeScript, as an open source project, is an absolute triumph: and I think it has everything to do with the people behind it. At this point TypeScript is "good enough" in every way that really matters. If they consciously stopped developing the language and just focused on performance and bugs I think we should all call that a success. I really believe it's been handled _that_ well. Meanwhile Flow went the other direction and there were bugs (in the 0.30 era, approximately) that had people pulling their hair out that were caused by the impedance mismatch of them making it for Facebook first and the rest of the world last. As far as I can tell, this really never changed (or at least, if it did, then maybe it was "too little too late"). Meanwhile, it seems like TypeScript has been managed with the literal opposite mindset: putting us in a situation where only one major project is left using Flow... React. There are other projects like ESLint that have been... how do I say this in a not bridge-burn-y way... surprisingly reluctant to realize that TypeScript isn't some passing fad. But I'm confident that they're going to have their wakeup call sooner or later. The culture of JavaScript-land is just not loyal enough for gatekeeping a technology like TypeScript. Look at webpack. We all spent nights and weekends for years gaining knowledge on how it works and weeks per year getting familiar with it, then esbuild happened and we threw webpack away overnight like it never even happened. I believe the same fate awaits projects that deny the necessity of writing in TypeScript at this point in history, with the possible singular exception of React.

skratlo 4y ago

We have WASM dude. But TS people are in TS bubble for what it's worth.

yCombLinks 4y ago
It's not worth anything. Are you writing raw WASM?
swatcoder 4y ago
WASM and TypeScript don’t really compare or compete. I’m not sure what you’re saying.
mc10 4y ago
Until WASM can touch the DOM you’re still going to need JS (and hence, TS).
- oaiey 4y ago
  And objects. And so many more things. Wasm is a cpu or low level operating system and not programming language
- nicoburns 4y ago
  In fairness, rust-in-wasm has pretty complete DOM bindings. You can quite easily write DOM manipulation code in Rust without ever touching JS/TS. Whether that's a good idea is another matter.
  - maxloh 4y ago
    How does that work?
    - amaranth 4y ago
      web-sys[1] generates the binding code using the same IDL files that browsers use to generate their JS bindings to the C++ doing the actual work. [1] https://github.com/rustwasm/wasm-bindgen/tree/main/crates/web-sys https://github.com/rustwasm/wasm-bindgen/tree/main/crates/we...

cies 4y ago

> and others still that were pushing for Elm Still pushing for it. TS is like make-up on a pig, compared to Elm. > I do know one company that uses ReasonML (or isn't it called Rescript now?) Re* is also a better alternative imho. Better interop with JS/TS is very nice. But in place one could use Elm, I'd say it certainly wins in the "clean" reward.

spankalee 4y ago

AtScript was always stillborn, and the Angular team absolutely could not have made a competitor to TypeScript.

dimitropoulos 4y ago
Agreed, but the point I was making here is that Angular itself was very far from stillborn, it pushed early adoption of TypeScript really really hard which did wonders for TypeScript to be taken seriously.
zaphirplane 4y ago
Wonder why they didn’t go with the other google language Dart Too foreign to frontend audiences? It has a lot of fans in flutter
- jsyolo 4y ago
  There was AngularDart, don't know what happened to it.
  - pax_americana 4y ago
    Publicly it's dead, but it's alive and well and constantly getting updated inside Google.

no_wizard 4y ago

>Today, we just have TypeScript. Well. I do know one company that uses ReasonML (or isn't it called Rescript now?) One company outside Meta?

dimitropoulos 4y ago
yes! haha. They love it. I ping them and see if they want to identify themselves.
- armacham 4y ago
  FB migrated all of its ReScript to Flow and deleted the ReScript.
illusionalsgcty 4y ago
There's definitely a few around that are using ReScript; we've been using ReScript for production services for a bit more than 2 years now at Autobooks. https://rescript-lang.org https://rescript-lang.org has a list too

throw_m239339 4y ago

> Without Angular, we may very well not have TypeScript today. Typescript was started at Microsoft by the guy who designed Turbo Pascal and C#, so completely independently from Google's Angular team. Angular had its own "AtScript" and eventually ditched that. Typescript had experimental decorator support well before Angular Team moved from AtScript, because it was a ECMAScript proposal. Angular had zero influence in the design or success of Typescript. Typescript however does support JSX optionally so one can claim that React DID influence Typescript's design decisions.

dimitropoulos 4y ago
Even if that's true (it's definitely not how it was depicted at the time at conferences and from people on the Google side).. the point stands Angular was absolutely huge for it's day and they pushed TypeScript really really hard. It was a truce between two huge companies and it made waves in terms of people trusting Microsoft. I have personally never been one of those mega Microsoft haters but I witnessed shouting matches in the office from people that we're hotly opposed to TypeScript being added to the codebase against others using Angular as a core motivation in many of their counter-arguments. I'm super glad we have TypeScript one way or the other because the team is so dedicated to OSS.
- throw_m239339 4y ago
  > Even if that's true (it's definitely not how it was depicted at the time at conferences and from people on the Google side).. the point stands Angular was absolutely huge for it's day and they pushed TypeScript really really hard. It was a truce between two huge companies and it made waves in terms of people trusting Microsoft. Angular.js was huge, by the time Angular version whatever because it was always changing, figured out what it wanted to be, most front-end developers already moved to React. What Microsoft product uses Angular? Doesn't Teams uses Angular.js but not Angular? and what does a Google conference has to do with Microsoft? Nothing.
styfle 4y ago
> Typescript had experimental decorator support well before Angular Team moved from AtScript Do you have a source for this. My memory isn't so good but I seem to remember that the Angular team pushed to get this Stage 0 proposal implemented even though the TypeScript team usually waits until Stage 2 or 3 to implement.

giraffe_lady 4y ago

god just think how good life would be if we had all switched to elm or reason instead.

roebk 4y ago
there's not a day that goes by that I don't think about this
iudqnolq 4y ago
If only Elm was infinitesimally less pure.
rk06 4y ago
Elm was never an option with how hard it is on "no js" policy

nikeee 4y ago

I remember this well, too. Ironically, I think that angular is the framework that benefits least from actually using TypeScript. There is a separate templating language that's only type-checked if you set the right compiler options. JSX is much better suited for that. Being OOP like angular, it often requires opting out of null-safety or init-checks, because something is late-initialized. Having mutable instance state results in less opportunities to be more strict with typing. Its good that the TS team decided to align with the ES standards. Initially (talking like v0.8.0), I had the impression that they're building a "C# for the web", being incompatible with ES. Maybe that's why enums and namespaces were added and initially, the boolean was named bool.

WorldMaker 4y ago
Enums have been proposed for JS for quite a while (there was a sort of enum in "the lost version" ES4 and a TC-39 proposal stuck in Stage 0 for years now [1]). Enums have always had relatively simple JS output that resembles a somewhat common pattern in JS. It was a "standard", just never really a deeply adopted "standard". What's today called "namespaces" in Typescript was originally called "modules" and then "inner modules" (to differentiate from "exterior modules") and is a tiny simplification on a JS pattern that was extremely common at the time of Typescript's inception called at the time "IIFE modules". "namespace" is a very C# name chosen in desperation (when it became clear that "exterior modules" were the present not just the future of the language and "interior modules" was too confusing a term to live), but it's a very old (and used to be extremely common) JS pattern that TS gave a tiny bit of syntax sugar to. It was a "standard" that existed at the time that was (rightfully) killed by AMD/UMD/CommonJS/ESM, but it is hard to fault the Typescript team at the early 0.x days thinking the "Stage Wild" JS pattern would possibly live on for many years to come. (This is also relevant to the patch notes for Typescript 5.0 as 5.0 is the first version [!] to itself be written as [proper/"exterior"] modules rather than namespaces. There are some interesting stories, including in these release notes for why that took so long to transition and what the performance benefits have been post-transition.) Even those things that didn't seem like ES standards have some history as JS "standards". It's not like TS 0.x/1.x didn't support "standards", it is more that the TS team mostly decided to focus more on later stage ES standards (more likely to be accepted by browsers) rather than trying to "prollyfill" Stage 0 and "Stage Wild" standards. [1] https://github.com/rbuckton/proposal-enum https://github.com/rbuckton/proposal-enum

truth_seeker 4y ago

Yep. Frameworks play an important role in end user (developers) helps deliver software as quickly as possible. Just like without Rails framework, we may very well not have Ruby today. Also, without WordPress, we may very well not have PHP today.