151–160 of 226 posts
So can I finally banish babel from my build steps?
I also would need to straighten out some things with how I'm handling TSX I think.
Would be so cool if the js engines ignored types like python3. Then I could just write Typescript and run it on node/browser
Got a link to more info on that python thing? Sounds interesting.
Basically, Python 3 added syntax for annotations, but most of the syntax is make sure it parses like code expressions would, then ignore whatever those code expressions are.
Earlier quoted context omitted.
Can anyone weigh in on TypeScript vs Elm?
------------------ Elm ------------------ [Pros] - Good language design (immutable, based on haskell+OCaml, nice type unions/pattern matching, everything is an expression, etc) Most people who write Elm are seduced by its elegance. - Very, very typesafe. If it compiles, 99.5% of chances that you won't get runtime errors (baring a few bugs) handy when you're tired. - It was made for beginners, it's easy to pick up, th…
I like the functionality of let merged = { ...foo, ...bar, ...baz }; But I've come to understand ... as variadic parameters in C++, Java and Go. Wish they'd used another token.
Rest is the variadic case:
function myFunction(a, b, ...rest) {
}
let [a, b, ...rest] = ['a', 'b', 'c', 'd']
let { a, b, ...rest } = { a: 'a', b: 'b', c: 'c', d: 'd' }
Earlier quoted context omitted.
They're different things, TS is a transpiler while Haskell (GHCJS) and Scala (Scala.js) compile respective host languages to javascript. In a perfect world you'd go with the latter, but there's overhead involved (relatively slow compilation and large generated binaries) that is mostly absent in TS. Also worth noting that TS' community is gigantic in comparison to that of Scala.js and GHCJS.
I was asking about the native languages themselves and their typesystems, not the compile-to-js versions of those languages. Regardless, I don't see much of a difference between TS -> JS and haskell->JS and scala -> JS. It's all from one language to another. the fact that TS is still considered a form of javascript is kind of irrelevant other than for semantics
Are they different? If language X can be expressed in its entirety as language Y then we can speak about X and Y interchangeably -- that's literally the point: full interop between client and server.
Anyway, there's a world of difference between TS and GHCJS, Scala.js, Clojurescript, Js_of_ocaml, etc. One speaks javascript, the others speak both.
As for reliability, in so far as TS is typed it will provide the compile time guarantees that its type system provides; not surprisingly the same goes for Scala.js, GHCJS, etc.
So, the decision point probably hinges more on aforementioned overhead, size of community, and tooling than language/type system features/power. If it were otherwise we'd have seen a huge uptick by now wrt adoption rates for the compile-to-js languages. Maybe that will change in future but for now the big players drive the javascript bus...
Earlier quoted context omitted.
They're getting better at describing which features are shimmed, but the easiest way to check is by running a single plugin on a bit of code and seeing for yourself. For instance, I decided just now to check if `transform-object-rest-spread` included an Object.assign polyfill (because spread syntax transpiles to Object.assign behind the scenes.) With the following input: var foo = { x: 1, y: 2 }; var bar = { a: 3, b:…
Deduplication of helper methods is now available in typescript too, using the 'importHelpers' compiler option. It will automatically add import statements to include the helpers from the 'tslib' package, see https://github.com/Microsoft/tslib
Earlier quoted context omitted.
Might be referring to or var smt = new Smt(); or the use of ? etc.
Those all exist in Flow as well. I assume the original poster is talking about how few types you actually need to write in Flow because of how good the inference is.
Earlier quoted context omitted.
I don't think this is a false dichotomy. There's definitely a spectrum between static and dynamic type systems, and plenty of people who identify with either camp. Calling it "tooling" changes the name of the problem, there are still people who will complain when they think the tooling is going in the wrong direction, and those complaints have merits because so many of us will be forced to write code in a style we do…
There's definitely a spectrum between static and dynamic type systems The key word is spectrum. and plenty of people who identify with either camp. What does it mean when people take something that's actually a spectrum, then divide that into two opposing camps? Does this sort of activity generally get public discourse closer to the truth, or farther away from it? It usually does the latter, in my experience. Hopeful…
The difference between a dichotomy and a spectrum is itself a false dichotomy. Ask any biologist what a species is, and they might stammer out some kind of weaselly definition full of hedges, and that same biologist might turn around and publish a dichotomous key which tells you how to identify a particular species according to an easy set of rules. The same goes for politics, human sexuality, and yes, type systems.
So I'm not going to hedge myself when I say that people "identify with either camp". They do. Neither is it a contradiction when I say that there's a spectrum. And when I say that there are two main kinds of people—I hope that my reader understands that I'm not a robot, and that I don't actually think that type systems are some kind of strict dichotomy.
> Just who gets to write code in exactly the style that they like?
I could point out that, again, like/dislike is a spectrum and not only a dichotomy. See above discussion.