Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Glimmer.js: What’s the Deal with TypeScript?

medium.com

Post reply on HN
Print view View original

61–70 of 112 posts

Re: Glimmer.js: What’s the Deal with TypeScript?

#61

Post by recursive »

untog wrote: post #25
uranian wrote: post #9

>At the end of the day, though, JavaScript is the language of the web. And when webassembly arrives that will be over, and Typescript will be deprecated. I can't wait for a better modern language like Haskell, Python, Livescript, etc.. built on top of webassembly. Then we can finally stop trying to fix Javascript's flaws with new language features.

And I can't wait for the rude awakening anti-JS developers have when they realise the vast majority of issues (particularly, performance) come from the DOM, not JavaScript. (And the first version of WebAssembly can't touch the DOM anyway) If people start writing Python for the web for no other reason than they just dislike JavaScript we're going to be forcing users to download a dozen different runtimes, just because…

My complaints about JS have nothing to do with the DOM. Like weird `this`, no integer types, surprising type coercion rules, and so forth.

Re: Glimmer.js: What’s the Deal with TypeScript?

#63

Post by recursive »

rubiquity wrote: post #27
tomelders wrote: post #23

Am I the only one who thinks typed Javascript, wether it's TypeScript or Flow, is a really flakey experience? I really enjoy Swift, so I'm not put off by types. But I find the experience of working in a real typed language to be very different to working with Flow or Typescript, where the types are for pretend, and type definitions are wrong often enough to be a real pain. And I found my self evaluating npm packages…

Types are pretend in TypeScript and Flow the same way that types are pretend in any other typed language. Types are used at compile-time and not runtime in both cases.

In most other languages, type casts are assertions that can fail. Not typescript.

Re: Glimmer.js: What’s the Deal with TypeScript?

#64

Post by picardo »

I have a project that uses Flow. I've had no complaints with it so far, but I've been craving the IDE support of TypeScript. What's the difference between the type system of TypeScript and Flow? Would it be worthwhile to switch?

Part of me wants to wait out the Flow team come up with better IntelliSense support. The `flow ide` command in the release 0.42 is a big step in the right direction. But it seems like TypeScript already has this, and if the delta between the two type systems is small, I might just go ahead and switch.

Re: Glimmer.js: What’s the Deal with TypeScript?

#65

Post by stupidcar »

trimbo wrote: post #39
_m8fo wrote: post #2

I haven't used TypeScript extensively, but I feel that there should be more of a push (maybe there is, please correct me if I'm wrong) to introduce whatever functionality people deem worthy that exists in TypeScript and introduce it to JavaScript. You can already see the conflict happening as some people prefer Flow and others TypeScript. Perhaps later Google will throw their hat into the ring and introduce GScript.…

> Perhaps later Google will throw their hat into the ring and introduce GScript Google had one called Atscript, but rallied Angular 2 around Typescript instead. http://sdtimes.com/google-microsoft-combine-typescript-atscr...

The Angular team also managed to get TypeScript approved as a new language for internal development at Google, joining a pretty short list (Java, C/C++, Python, JavaScript, and Dart I believe).

All the others were apparently decided by fiat in earlier days then grandfathered in. TypeScript is the first, and so far only, language to successfully go through the official approval process.

I feel like we're going to see a big increase in TypeScript related activity from Google in the next couple of years, due to this.

Re: Glimmer.js: What’s the Deal with TypeScript?

#66

Post by [deleted] »

pryelluw wrote: post #50
untog wrote: post #25

Earlier quoted context omitted.

And I can't wait for the rude awakening anti-JS developers have when they realise the vast majority of issues (particularly, performance) come from the DOM, not JavaScript. (And the first version of WebAssembly can't touch the DOM anyway) If people start writing Python for the web for no other reason than they just dislike JavaScript we're going to be forcing users to download a dozen different runtimes, just because…

What would you replace the DOM with?

[deleted]

Re: Glimmer.js: What’s the Deal with TypeScript?

#67

Post by mi100hael »

_uhtu wrote: post #54
uranian wrote: post #9

>At the end of the day, though, JavaScript is the language of the web. And when webassembly arrives that will be over, and Typescript will be deprecated. I can't wait for a better modern language like Haskell, Python, Livescript, etc.. built on top of webassembly. Then we can finally stop trying to fix Javascript's flaws with new language features.

To run python on WebAssembly you would have to compile the entire CPython executable, and every single dependency it has, into WebAssembly, then ship that giant executable with every page so you could then run Python code with it. You would then also most likely need a special library, which at some point someone will have to write or you'll have to write it yourself, to give Python a clean interface to the DOM. All…

> To run python on WebAssembly you would have to compile the entire CPython executable, and every single dependency it has, into WebAssembly, then ship that giant executable with every page so you could then run Python code with it.

I mean, that's kind of already the case when you want to ship a Python project as a stand-alone package to run on the desktop. Alternatively, I could see a method of installing runtimes into your browser like plugins so it doesn't have to be shipped over the wire every time. Not saying I'd ever want to do something like that, just that alternatives exist. Browsers are moving more and more towards VMs that transcend the context of a single synchronous request/response.

Re: Glimmer.js: What’s the Deal with TypeScript?

#68

Post by RyanCavanaugh »

arcosdev wrote: post #13

What turns me off immediately about TypeScript (and examples in the article show it) is the use of the class construct. If I could see some examples of teams writing TypeScript without falling into the use of classes I would feel a lot better about it. I am in full agreement with Douglas Crockford and others that adding pseudo-classes to JS was a big mistake.

You could look at the TypeScript compiler itself, which uses zero classes.

Re: Glimmer.js: What’s the Deal with TypeScript?

#69

Post by boubiyeah »

pryelluw wrote: post #8
YCode wrote: post #6

What sold me on TypeScript was that it didn't just add features, it actively solved a problem I'd been experiencing. Once a JavaScript project scales beyond what can fit in your head, JS's initial productivity boost crumbles because you have to constantly double back and make sure your methods/constructors/etc. are correctly used, which properties are optional, etc... A lot of the debugging happens in runtime and god…

Have you tried Elm? Id love to know your experiences.

Elm is very different from typescript and is generally a much more involved choice than just "let's make our usual JS strongly typed".

- You need to like Elm the language (it's pretty good, but limited, not expressive)

- You need to like purity. Time.now or Math.random returns an asynchronous Task. I know why it's done like that, I just don't agree with the tradeoff.

- You need to like Elm the ecosystem or be prepared to write lots of awkward JS glue code

- You need to like Elm, the architecture (it's simple, but has tons of boilerplate and limitations)

- You need to accept Elm, the roadmap made by a benevolent dictator. The progress is slow.

Compared to a good typescript codebase, you will get like +5/10% type safety. Typescript is way more flexible, but that also mean you will have to rely a bit more on human code reviews, etc rather than the Elm compiler just telling you "no, there is only one way to do this". On the other hand, you have just typescript on one side, Elm + javascript/typescript if you want to achieve anything serious on the other :)

Go with Elm if you like being in a very, very controlled environment (frameworky) and you're afraid to make mistakes. Go with typescript if you're a hacker who like to mix and match architectures, libs, etc and accepts things change fast in the frontend orld right now.

Re: Glimmer.js: What’s the Deal with TypeScript?

#70

Post by reducesuffering »

stupidcar wrote: post #65
trimbo wrote: post #39

Earlier quoted context omitted.

> Perhaps later Google will throw their hat into the ring and introduce GScript Google had one called Atscript, but rallied Angular 2 around Typescript instead. http://sdtimes.com/google-microsoft-combine-typescript-atscr...

The Angular team also managed to get TypeScript approved as a new language for internal development at Google, joining a pretty short list (Java, C/C++, Python, JavaScript, and Dart I believe). All the others were apparently decided by fiat in earlier days then grandfathered in. TypeScript is the first, and so far only, language to successfully go through the official approval process. I feel like we're going to see…

I believe Go would also be an approved language for internal development.
Post reply on HN