41–50 of 112 posts
Ok, when Glimmer's motivation was only typechecking, why not just fb flow then?
[1] https://github.com/facebook/flow/issues/245 [2] https://github.com/facebook/flow/issues/869 [3] https://github.com/facebook/flow/issues/1528
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.
>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.
IMO I feel like it is going to be a challenge to integrate the GC of another language with the GC of the JavaScript/DOM, and if so we'll be keeping JavaScript going for a while.
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…
> 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.
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…
import flatten = require('lodash/flatten')
module.exports = flatten
import flatten from 'lodash/flatten'
var flatten = require('lodash/flatten').default
I haven't migrated to webpack 2, but some brief experiments suggest all modules get massaged in to ES2015 format.
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 method arity mismatches, but TypeScript made this happen about an order of magnitude faster.
The second is how unobtrusive the types actually are. I did a fair bit of J2EE programming in the 00s, and types and interfaces can be really annoying. With typescript, interfaces are assertions about the shape of an object, rather than things themselves. That means, if you defined an interface as HasFirstName: { firstName: string } and function greet(person: HasFirstName), you don't actually have to put HasFirstName everywhere in the code that uses that function. You're not required to set up inheritance or anything. You just have to make sure that all arguments to greet have a firstName property. That's it. So I can say: const dude = { firstName: 'the' }; greet(dude) just fine. But if I try to greet(potato), it'll error.
Lexical typing this way gives you a lot of power while still staying out of your way in a language like javascript where it's super common to create consts as bags of properties without worrying about what particular interface they're instantiating. I really like that, as it is precisely the overbearing types of Java that annoy me.
Earlier quoted context omitted.
At the end of the day, JS will always be the language of the web. You're still going to be doing DOM manipulation through JS. WASM is really going to benefit people who want to do more heavy duty edge cases such as image processing.
Is this because browsers won't expose DOM manipulation at the WASM level, or is there a different reason?
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…
Earlier quoted context omitted.
> webassembly. is basically a better way to do ASM.js . How many Python,Haskell,Livescript have been built on top of ASM.js ? Do you really believe you can make your users download 10s of megabytes of binaries each time they visit a website just to bootstrap a language? And i'm not even talking about the runtime... Right now, the only viable languages for webassembly are the ones that don't use garbage collection and…
We make our users download tens of megabytes of shitty unoptimized JS for tracking, ad networks, unoptimized images, autoplaying videos, and so on and so forth now.
>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…