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

101–110 of 112 posts

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

#101

Post by [deleted] »

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…

[deleted]

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

#102

Post by bauerd »

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…

>we're going to be forcing users to download a dozen different runtimes

Why would users need to download a runtime, given that we'd have WASM as a compilation target for Python, the language?

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

#103

Post by fwefwwfe »

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…

You're missing Scalajs.

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

#104

Post by kej »

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…

>What's the difference between the type system of TypeScript and Flow?

This presentation [1] was posted to HN recently and gave a pretty good overview of the differences between TypeScript and Flow.

[1] https://djcordhose.github.io/flow-vs-typescript/flow-typescr...

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

#105

Post by picardo »

kej wrote: post #104
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…

>What's the difference between the type system of TypeScript and Flow? This presentation [1] was posted to HN recently and gave a pretty good overview of the differences between TypeScript and Flow. [1] https://djcordhose.github.io/flow-vs-typescript/flow-typescr...

Awesome prez! Thanks for the link!

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

#106

Post by vladimir-y »

Achshar wrote: post #72
petre wrote: post #62

Well, if we already transpile ES7 to JS then why not tanspile TypeScript instead because of all the added benefits?

Because eventually in a couple of years you can take your ES7 code and remove the transpiration and it will all work seamlessly. Not so much with Typescript.

Transpiling is going to stay, currently you transpile es6/7/typescript=>es5, later you will do es8/9/typescript=>es6/7, and so on, so this point is not relevant.

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

#107

Post by valuearb »

arcosdev wrote: post #52
zebrafish wrote: post #26

Earlier quoted context omitted.

I'm curious as to why you don't like the use of classes. Are you against classes in all languages or just JavaScript?

I'm not against classes in other languages, especially those that follow a typical OOP pattern (i.e. Java, C#, etc.). See above for my reason re: JavaScript.

So appeal to authority?

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

#108

Post by Achshar »

vladimir-y wrote: post #106
Achshar wrote: post #72

Earlier quoted context omitted.

Because eventually in a couple of years you can take your ES7 code and remove the transpiration and it will all work seamlessly. Not so much with Typescript.

Transpiling is going to stay, currently you transpile es6/7/typescript=>es5, later you will do es8/9/typescript=>es6/7, and so on, so this point is not relevant.

I meant it in the code's current state. Suppose the development stops or stagnates in a month or two. The product is complete. So you can remove the transpilation. Also we won't have to transpile current features in the future. That and code can go as is and have the benefit of native execution that it doesn't currently have.

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

#109

Post by weberc2 »

zengid wrote: post #92
weberc2 wrote: post #43

Earlier quoted context omitted.

WebAssembly doesn't have a GC, And I don't see any reason why the DOM should be subject to a JS GC.

Correct, but python (or haskell or java or whatever) running on top of WASM would , and there are plans to integrate WASM with the other GC's in the browser, however: "'compile the VM' strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser" [1]. My prev comment was speculati…

I don't know what is meant by "there are plans to integrate WASM with the other GC's in the browser". Is the idea that the browser runs a GC for DOM elements that is separate from the JS VM GC? I wonder if they could follow a model like operating system resources (e.g., file handles) where the process is responsible for managing the resource lifetimes. This would make resource management trivial, and running (for example) Python on WASM would simply mean emitting WASM instructions instead of x86.

Of course, lots of other problems remain, for example, downloading an entire runtime or "putting Python on WASM isn't going to magically make it fast". But I don't think the GC should be a particularly large challenge.

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

#110

Post by 6a68 »

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

Just FYI, this has already been done with emscripten a while ago, and it does work. See: http://pypyjs.org/
Post reply on HN