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

81–90 of 112 posts

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

#81

Post by KurtMueller »

YCode wrote: post #11
pryelluw wrote: post #8

Earlier quoted context omitted.

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

I haven't; I haven't tried Flow either which looked promising. For kicks I tried the online Elm demo. Offhand it doesn't seem like Elm highlights errors inline(?). The syntax also looks a little foreign, whereas TS generally still looks like JS with a few exceptions. I imagine Elm/Flow both have this, but another thing I like that TS does in VSCode at least with a watching task is collecting errors project-wide in a…

Elm has a compiler (a very helpful one at that) which will indeed collect errors project-wide in a "problems" window. Text editors like VS Code and Atom have Elm extensions which will highlight any errors the Elm compiler comes across.

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

#82

Post by DougBTX »

pfooti wrote: post #46

There's two things that really stand out for me on TypeScript. There are other positive attributes, but these are the two things I liked. The first is that it made some specific workflows a lot easier. In particular, I'm working on some pre-alpha libraries where there's movement on how the API interface is defined. TypeScript made that transition a lot easier. Yes, my testing would have eventually caught all the meth…

For google-ability, TypeScript has structural types, in contrast with Java which has nominal types.

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

#83

Post by Rusky »

picardo wrote: post #64

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 TypeScr…

TypeScript's type system is intentionally unsound in a handful of places- function parameters are bivariant, for example. I believe Flow is at least closer to being sound.

I suspect switching from Flow to TypeScript would be relatively straightforward as far as the types go, but going the other direction would not.

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

#84

Post by lfischer »

picardo wrote: post #64

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 TypeScr…

The delta between the type systems is small enough that people have tried to automatically convert TypeScript type definitions to Flow. One notable difference is that Flow supports declaring types as covariant/contravariant. I suspect that as far as most application code bases go (as opposed to libraries), you would almost see no difference.

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

#85

Post by KurtMueller »

Joeri wrote: post #53

I've done a few typescript projects. Some migrating an existing codebase, some starting from scratch. Every time it has been a nice experience, and with every release it gets nicer. Two of the projects had very complex requirements, and typescript was instrumental in being able to refactor them with confidence. I think the upsides are quite well known by now. Honesty requires me to admit that I did run into some down…

> Convincing other developers typescript has value and isn't javascript's weird ugly nephew is an uphill struggle.

I feel the same way about Elm, F# and Fable, Facebook's ReasonML, and any other language that has an ML type system and compiles to javascript. I think the value becomes more apparent when: a) you work in a large codebase and have to refactor either a large swath of code and/or a critical piece of logic and b) you need to make illegal states unrepresentable. In both cases, I have found having a compiled, ml-typed language extremely helpful.

I think for both Typescript or an ML language, having immutable non-nullable types by default really cuts down on complexity - instead of having to specify everything that's immutable with something like a `const` keyword, you instead have to specifically point out which attritibutes on a type are mutable. That's a small win but has huge benefits - especially when you're trying to debug code.

That's just my two cents anyway.

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

#86

Post by recursive »

Lio wrote: post #71
recursive wrote: post #60

Earlier quoted context omitted.

The flagship feature of TS is static typing. That will never exist in JS.

I'd never say never. As I'm sure you're aware, JavaScript has had statically typed arrays since WebGL was introduced. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...

It has typed arrays, but they're still not statically typed. In a statically typed language, this would not run.

    console.log("hello");
    typedArr[0] = incompatibleType();
In javascript, it will produce "hello" as output, and then a run-time failure.

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

#87

Post by Rusky »

Enginerd3 wrote: post #47
weberc2 wrote: post #40

Earlier quoted context omitted.

Is this because browsers won't expose DOM manipulation at the WASM level, or is there a different reason?

DOM manipulation is going to be available at the WASM level in the future but it's going to be inefficient to do so just as it is inefficient to do image processing in JS right now. The only difference is that JS is the only viable option now if you want to do image processing on the web. WASM exists to solve this problem and complement JS. Hell, look at WASM's and JS's logo. They're two puzzle pieces that fit togeth…

Your analogy doesn't sound right to me- there's nothing about wasm that would make it slow to manipulate the DOM, while there is plenty about Javascript that makes it slow to process images.

Manipulating the DOM from wasm shouldn't be any slower than Javascript. Slow in general because of the DOM, perhaps, but not because of wasm.

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

#88

Post by tantalor »

_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.…

If you just want type checking for JavaScript, use Closure Compiler:

https://developers.google.com/closure/compiler/

Code checking. The Closure Compiler provides warnings for illegal JavaScript and warnings for potentially dangerous operations, helping you to produce JavaScript that is less buggy and easier to maintain.

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

#89

Post by lfischer »

boubiyeah wrote: post #69
pryelluw wrote: post #8

Earlier quoted context omitted.

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 prepare…

Have you encountered limitations in Elm that pushed you to resort to writing JavaScript (as opposed to using JavaScript libraries from Elm through ports)?

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

#90

Post by goatlover »

recursive wrote: post #60
_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.…

The flagship feature of TS is static typing. That will never exist in JS.

They got class stuff into the language, and that was no small feat (very contentious issue), even if it is still syntactic sugar over prototypes.
Post reply on HN