121–130 of 201 posts
I wonder if it's worth migrating from Flow to TypeScript? Flow has been great, but I've just tried to update to the latest version and I'm dealing with a flood of indecipherable errors, especially from the react-dnd library. Looks like no-one is really maintaining the flow types so I'm on my own, and I don't even know where to start. I also haven't been able to track down some errors, like "Cannot read property 'foo'…
Earlier quoted context omitted.
For what it's worth typescript is developed by Microsoft. Doesn't get much bigger than that
I know, and that’s a definite plus. I don’t have to worry that it will go away or lose all the main contributors. But is not developed by the same developers/company as React. I will say given what TS is competing against the fact that it so well used is rather compelling. I know all of Angular is also written in TS. It’s clearly very heavily used.
I'm really interested in this, as I'm a happy Angular user. (I'm primarily a non-frontend dev/tech/ops, but I occasionally I do frontend development.) So every time I look at a React component/codebase I'm completely lost, and I'd like to understand why and what and how.)
Real big fan of TS, like anything though you just have to be disciplined when using it. Type absolutely everything and set the transpiler to the most aggressive checks possible... If you’re being lazy and putting : any everywhere and then complaining about how good it is...you’re doing it wrong In our project I’ve found we make a lot less mistakes than with pure JS and there’s a lot less pointless type check unit tes…
I always use it with > "compilerOptions": { "strict": true } But given the huge number of other options I worry that like GCC's '-Wall', that doesn't actually give you the strongest possible type checking. Anyone know about that? My aim with Typescript is to turn JS into OCaml.
I thought about this for quite a while when we started on TypeScript at Google (I work on this with Evan). I've convinced myself that using a different language cannot solve the problem that we're looking at.
The argument goes like this: if you use a different language than JavaScript for front end development, you're (hopefully) doing it for a reason. That is, you (a) want the other languages semantics (e.g. bounds checks on array accesses, runtime types, method dispatch, you name it), or you (b) might want the programming languages ecosystem - editors, IDEs, etc; but most importantly libraries and frameworks. Most likely, you're looking for a combination of (a) and (b).
The problem with (a) is that the more different the runtime semantics of your programming language are, the more emulation code you need. Emulation code is costly in code size, performance, interop with JS, and often understandability (at some point you will need to debug the output, believe me).
The problem with (b) is that you typically opt into a large ecosystem that was originally written for a very different environment. This was a big issue with GWT: people would pull Java libraries, but those libraries, amazing as many are, were not written for the web or with code size in mind. This meant using a common library like Guava required a lot of engineering effort to keep code size in check. This also applies to WASM, possibly even more so.
These mechanisms work together to make it very hard to hit the sweet spot between performance, developer experience, and interoperability. And ironically, the better you get at the goals you're aiming for (different semantics, different ecosystem), the farther you get away from a working solution.
I don't think it's impossible to achieve a transpile-to-JS language that works really well with enough investment, but keeping in mind the other reasons Evan lists (mind share, existing code base), incrementally improving JavaScript where needed is IMHO the much more promising approach.
Earlier quoted context omitted.
For the default props side of things, as of typescript 3 and the latest @types/react it should work as you would expect: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...
I saw that for default props, but can I use it yet? The React typescript definitions are still on 2.8 [1], and I imagine that they plan to stick with 2.8 until maybe the next major react release? I have no idea where people discuss things like react types for DefinitelyTyped. Github issues seem like a mess due to the sheer number of different projects sitting in a single repo. [1] https://github.com/DefinitelyTyped/D…
[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/1d96...
I wonder if it's worth migrating from Flow to TypeScript? Flow has been great, but I've just tried to update to the latest version and I'm dealing with a flood of indecipherable errors, especially from the react-dnd library. Looks like no-one is really maintaining the flow types so I'm on my own, and I don't even know where to start. I also haven't been able to track down some errors, like "Cannot read property 'foo'…
The reason I initially chose Flow was the fact that their goals were more ambitious (trying to build a sound type system for example). And there were features that Flow had and TypeScript didn't (tagged unions for example).
The reason I ultimately switched to TypeScript was that after a couple of years, it had simply caught up and surpassed in the one area it was behind Flow (i.e. expressiveness of the type system and type-level programming), and that it had widened the lead in the areas that it was always better at, like much better tooling, bigger community, core team being more engaged with the community, releasing RCs to smooth out the rough edges, etc.
So yes, I switched to TypeScript, and I see that I'm spending less time working around the type system's quirks and more time getting things done. I'm also very much enjoying the fact that I can express types in TS that I never could in Flow. So my codebase has much better type coverage in TypeScript than it did with Flow.
[0] https://www.typescriptlang.org/docs/handbook/advanced-types....
What js in browser is missing is something that golang provided on the server - fast, simple (and more standard) way of writing and executing code, including large code bases. Typesafety is a small part of it and I’m not sure whether switching or choosing entire dev tooling based on just that is worth it. Just structure your code better and use react prop types and most of type issues go away, in react code bases.
> Gmail engineers had to worry so much about Internet Explorer's poor garbage collection algorithm that they'd need to manually hoist string literals out of for loops to avoid GC pauses. What does this mean in practice? I know about variable hoisting and function scoping, but not about old JS GC algos.
Having the programmer define a variable before the loop and then reuse it each iteration meant that all that allocation and garbage collection wasn’t necessary during the passes of the loop.
After a few years with both TS and JS my verdict is that TypeScript definitely helps , but mostly with type-related bugs - with proper testing you don't get many of those. What I would like to have in TS is a more expressive type system - the current is somewhat basic(e.g. you can't have a Symbol as a dictionary key - interesting given that it's possible in JS. Also you can't mix dictionary fields with regular ones i…
The point of type checking isn't so much to prevent bugs in production, but to speed up your development loop by catching many errors before you've even saved your file. Its much faster to see a red squiggly right after you've written a line of code, and fix it, rather than figure out whats gone wrong 10 minutes later looking at a stack trace in your test suite.
I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious. My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.
TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. And if you were already using Webpack picking it up was as easy as adding a loader. IMO, using such early proposals isn't worth the risk in production. Especially for proposals that are so young that they haven't even settled on a clear spec as to its behavior, like the pipeline operator.
Either way it wasn't Typescript itself that made it difficult. There wasn't as large of community yet, documentation was much less, editor support wasn't as great and very few packages had type definition files. Definitely typed could show all or most of their packages on GitHub at the time and many were incomplete. That was the sole way to get any type definitions.
Agreed with your comment on early proposals. Still would like to have the option to use it and double check the transformation of how it outputs. And not everything needs to be for production use. Writing for fun is an enjoyable hobby.