Live data from Hacker News

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

medium.com

51–60 of 112 posts

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

#51
post #45
post #12

Anyone got a link on how to transition existing large webpack/React/babel project to using Typescript? Googling I only found https://medium.com/@clayallsopp/incrementally-migrating-java... but it doesn’t use ts-loader and doesn’t go into details on how to use typings. I tried following ts-loader docs, but things broke at `import flatten from 'lodash/flatten'` and adding typings for `lodash ` didn’t help. Would be int…

ES2015/commonjs interop currently sucks with TS. This is how you only import flatten: import flatten = require('lodash/flatten') TS expects any modules imported using ES2015 import to have the shape of a ES2015 module. This is an issue for many UMD/commonjs modules. In the case of lodash, it's effectively doing this: module.exports = flatten And then you're importing it like so: import flatten from 'lodash/flatten' a…

I've been using `allowSyntheticDefaultImports` which does some magic behind the scenes for you to be able to use `import flatten from 'lodash/flatten'` making it really easy to use modules that don't define default exports.

So far (a bit unexpectedly) I didn't really run into any nasty side-effects or things that went wrong with it.

See https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in... for a (short) explanation.

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

#52

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.

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.

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

#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 downsides:

- Initially it was difficult to understand the exact mechanics of how typescript ... types. Definition files seemed like a bit of a black art, and how to annotate existing code so that it had the proper type wasn't always obvious, especially when you run into libraries with incomplete or wrong type definitions and when you want to do tricky stuff like creating typed mocks in unit tests. The typescript documentation is very good and I haven't needed much beyond it, but some extra real-world type definition chapters would help.

- Setting up a complete dev toolchain is challenging. I wanted everything: source maps, in-IDE debugging with breakpoints, in-IDE unit tests with code coverage, tslint, gradual introduction into an existing codebase, and robust integration into the build of the rest of the app (which in my case meant SBT integration). I still don't have code coverage in my in-IDE unit tests. The way I see it though, if your javascript has any build step at all you already have this pain, so this isn't so much a problem with typescript as a problem with javascript build pipelines in general.

- Convincing other developers typescript has value and isn't javascript's weird ugly nephew is an uphill struggle. Once you do a typescript project you end up understanding the value, even if you might not find it valuable for yourself personally, so it's only a matter of convincing developers to give it a go. However, getting to that point is a bit of a chicken and egg problem.

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

#54
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 of this together would be at absolute minimum 4.5 megabytes, which is absolutely unacceptably large for a frontend bundle.

WebAssembly is very cool techonology, but it's not going to deprecate Javascript because Javascript will be, at least for a very long time, the only scripting language that runs efficiently on the web, and also will always be the most well supported.

With WebAssembly you could write in any AoT compilation language that can compile on LLVM, but I, and many many other developers, have no interest in very low level languages like C, C++, or Rust in the browser, even though we acknowledge the flaws in JS. Maybe one day higher level languages besides Javascript will be practical, but that's a ways away.

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

#55
post #37

Earlier quoted context omitted.

> the state of Immutability and Typed Javascript is pretty grim as far as I can tell, unless I'm missing something. You definitely are missing something. Immutablejs and TS go together fine. Assigning to an immutable property or object is a syntax error instead of a runtime error. It's great.

I'll need to take another look at TypeScript. Last I checked you have to wrap your immutable records in classes with both TS and Flow. That's still true for Flow as far as I know.

I actually made my own type definitions that made immutablejs records "just work" for TS. I submitted them to the immutablejs guys, but they never acted on them.

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

#56
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.

>better ... language ... Python

ES5 was a dumpster-fire. But ES2015+ is an amazing language. You just have to take the time to systematically study it.

If you're choosing a language you'll spend thousands of hours with, you shouldn't use "initial learning curve" as sole criteria.

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

#57
post #38

Earlier quoted context omitted.

In contrast to many typed languages, currently in Typescript, you can't do any kind of reflection so runtime really has no access to the type system. Well, I still love TS though.

There is the possibility of decorators for stuff like this. Angular makes a lot of use of them.

But isn't that some sort of repetition? I don't know how Angular does this so I'm really asking.

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

#58
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.

Have you actually used Typescript? It's definitely better than Python, and I'd personally prefer it to Haskell / Livescript. I would love to hear what people actually think the "flaws" are with ES6 Javascript and Typescript, because they have been disappearing fast over the past two years.

WebAssembly will be great, but as a complement to Typescript, not as a replacement. I would love to import a native module for the small chunk of my code that needs to do heavy lifting. And I don't see any reason why the Typescript team couldn't eventually build a WebAssembly compatibility layer.

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

#59
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?

I honestly have no idea. It does so much that I don't know where you'd start - but I suspect that's also the problem.

I remember seeing a demo of React Canvas a few years ago - basically, recreating a "DOM" of sorts inside a canvas tag - and the performance was crazy. Beautiful 60fps touch interactions. But, of course, it only does a tiny subset of what the DOM does. I'm still waiting for a good reason to use it myself to try out how the API feels.

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

#60
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.
Post reply on HN