orta

The author and I have both been in the iOS community for over a decade. We likely have similar opinions that SwiftUI is interesting but still in incubation phase, and that the majority of SwiftUI's focus has been iOS support.

So a post showing how v2 of SwiftUI's limitations is a useful read because it's a reminder that it has more to go on the Mac - I expected that, and I bet he did. So it's positive in the sense that he wasn't disappointed, but that it met the (admittedly low) expectations of the author

+1 on that roller-coaster ride too

About decade ago a girl I knew moved off to Australia for a year, as her iPad was her main communication device, I made a just-for-her iPad app with Spotify playlists I could edit from my computer. https://orta.io/Mixtapes/

She's now my wife.

(and you don't have permission to put this on that site)

It's a good question ( I have a YouTube video on some of the reasonings, https://www.youtube.com/watch?v=8qm49TyMUPI ) but the TLDR is that TS really wants to only be a type layer above JS - turning into something like MSIL means breaking JS runtime semantics or re-creating that in MSIL ourselves. The idea has been tried a little differently by MS research though, https://www.microsoft.com/en-us/research/publication/static-...

Ah, yeah that's what you mean - so the first time I built this graph I used the real dates and their difference from release to give accurate %s. This turned out to not work, because there wasn't enough space to fit the text underneath. I then explored making the graph vertical with accurate %s, but it still felt heavily one-sided at end with the beta/rc/release. all clumped at the bottom.

The third iteration is this, I moved the release date up into a sentence above, then had a mostly representational but kinda accurate overview of the three release stages. I think it gets the idea of the phases across, works in all browser sizes etc and doesn't take up too much visual space

It's a good idea, and I did consider it, but it's been "playground" for 7 years and even third party versions kept the playground name to let people know it's a REPL. Breaking that is a pretty big change which I opted to not do.

Your choice of naming matches mine too, the abstraction which lets anyone build their own TS repl is called the sandbox: https://www.typescriptlang.org/dev/sandbox/

For the handbook specifically (the part where we expect you to read from start to finish) I created both an epub and pdf in the publishing process, you can see the links here: https://www.typescriptlang.org/docs

The PDF one isn't stunning, bit of a WIP, but the epub one is good.

It is bound to actual release data!

https://github.com/microsoft/TypeScript-Website/blob/v2/pack...

The divs are updated every time the website is re-deployed, and it deploys often. This means we don't need to run JS to give you the right date info.

Ha, yeah, I did consider getting my windows machine out for some the screenshots, then I could do light/dark win/mac. In the end, I figured the same framing was better because I mainly wanted to highlight the light/dark theming support, and "cross-OS" isn't really a feature you need to show for a website

I gave a write-up on my motivations for choosing Gatsby on their blog too: https://www.gatsbyjs.org/blog/2020-01-23-why-typescript-chos...

I think this is a good article, and worth the time to give it a read. When Deno was first announced I was not sold on this aspect of the system.

Over time though, and after having wrote a barely-above-trivial app in Deno. I've started to come to the conclusion that Deno's form of dependency management is a fresh perspective which ties closer to how browsers work and is a welcome simplification. The article covers a few ways that you can get production/reproducible builds out of the box which is usually people's first worry.

We (the TypeScript team) have a bunch of private repos (blog post drafts, planning docs, reproduction repos, rando internal tooling ) on GitHub that are many years old. I'm pretty sure that Sam was mistaken here.

Artsy did a randomized dev team swap, where team leads stayed and everyone under shuffled: https://artsy.github.io/blog/2017/09/11/DevSwap/

That is easy to do! https://docs.microsoft.com which is, to my knowledge, the MSDN replacement is built as a static site hybrid.

Here's a talk form one of the creators: https://www.youtube.com/watch?v=EpYYe6aQjJM

This is a great write-up, thanks!

I've been punting on making a dark/light mode selector on the new TypeScript website for a few months specifically so I don't have to be certain of this route first-hand. This was exactly what I was expecting. Good work.

I believe bikeshaving's point above is that you learn the semantics of generator functions in JavaScript and that's your 'magic convention' - one that's not unique to this library because it comes form the languagee

Yep, a schema would work fine for this (and you can generate it from types)

You can test them locally using vscode using the "$schema" field on the root obj, here's an example PR doing all that: https://github.com/danger/peril/pull/281

You can either have users add that schema reference in the JSON (throw it in the template) or ship a vscode extension which connects them

Usually it's one or two people using their spare time to eventually get something good enough to work on work time occasionally unless it's 100% aligned with the company goals (e.g. a company like zeit or gatsby)

Parcel is good (and I use it), but it's likely if someone had pitched it internally I'd bet someone would have said "Webpack is good enough for us". At least that's how it would have gone at the places I've worked at.

You can use TypeScript to improve the tooling: https://github.com/JXA-userland/JXA

There's a bunch of website work that came out with this release too: mainly search and a lot of playground improvements.

https://www.typescriptlang.org

I work on the TS team, I have built two pretty big TypeScript projects in the lsat few years:

- https://github.com/danger/danger-js - https://github.com/flappy-royale/flappy-royale

They don't use bleeding edge concepts, but are solid & simple codebases which have scaled well. (Though whether you should ever take code advice from a game is a worthy question)

Yep - they have a secret access store per repo

TypeScript does a pretty good job here if you're willing to add a bit of extra syntax:

  const a = [1,2,3]
  a.push(4)

  const b: readonly number[] = [1,2,3]
  b.push(4) // Property 'push' does not exist on type 'readonly number[]'.

What was your top score?

Awesome, I've been looking forwards to this!

Somewhat hijacking this thread to say that if you have ideas for improvements to TypeScript's documentation or website, we're currently asking for ideas:

https://github.com/microsoft/TypeScript/issues/31983

Nice overview! I plan on building a larger version of this into the docs eventually

https://github.com/microsoft/TypeScript/issues/31983#issueco...

Disagree on the no aspect, I think there are folks who will do OSS at depth regardless - but there are people for whom the incentives (of community, empowerment, fame etc) aren’t enough and maybe this is one way to make them jump the hurdle.

I pitched that this could be worth trying at Artsy on my last day

At Artsy we made the decisions to use React Native a few years ago as a team of iOS devs, with a lot of JS folks on the web who were interested in React. We don't regret it.

While we've found ways to work within the boundaries of React Native - it's really refreshing to see how many of the points we considered to be negatives against React Native are getting addressed this year. Congrats team!

No limitations (only that it's a bit more verbose than just TS), this is canonical supported by the TypeScript powered tooling which VS Code provides by default on an JS project.

https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...