10 ms·
Every new web app at PayPal starts with TypeScript
- jondubois 8y ago>> What took took me so long? It took a while for all of Microsoft's marketing to kick in and for the mindless hypewagon to reach full speed. I have decades of experience with Typed ECMAScript (first with ActionScript 3 from 2006 and then TypeScript). It's not worth it. Productivity will drop enormously and bug density will not change at all.
- matthoiland 8y agoPart of me feels the same way. I've been through AS3, Coffeescript, Dart, and now the Typescript hypewagons. I'm willing to give it a deep dive, but I'd rather see an optional flag in an upcoming ES version for types and other TS superset features.
- simplify 8y agoAside from type annotations, TS only has one superset feature (decorators). It's already behind a flag.
- sverrejoh 8y agoand namespaces and enums at least.
- simplify 8y agoThanks, I had forgotten about those.
- WorldMaker 8y agoNamespaces are considered a deprecated artifact from TS < 1 and most projects suggest turning on lint errors for using them. Even if you do them, they are simple syntax sugar for an IIFE pattern that has been common in JS since forever. Enums are simple syntax sugar for constants patterns you could write by hand easily. Other than decorators and JSX-related stuff (also behind compiler flags), TS has been pretty strict about keeping only to Stage 3+ ES proposals since 1.x. Decorators got a strong push from Angular-based teams and JSX gets a lot of attention from React-based teams, so its also not like TS is adding stuff "just because", they are doing it for real world project engineering needs.
- simion314 8y agoMy personal experience is that AS3 was a better experience over JS and Flex4 was a pleasure to work over the JS frameworks and CSS mess.
- jondubois 8y agoAS3 was better than TypeScript in several ways; - It was interpreted natively (no build step). It was fast. AS3 was much faster than AS2. - It was heavily targeted at games. Games have a lot of objects and those objects tend to have complex relationships with each other (I.e. more inheritance and more polymorphic compositions; where different objects can be passed to the same method to produce different effects).
- 52-6F-62 8y agoIf I have to continue doing any kind of front end work, I would be very okay with a native TypeScript runtime in the browser with support for modules. Add in the option for a flag to skip type-checking and we might have a win-win for fans of pure ES6/7/8.
- Matthias247 8y agoOverall AS3 with Flex felt great, and I used it for one of the funnest projects I've ever worked on (prototyping for a new GUI system). The inbuilt widgets functionalities were great, with things like skinning functionality and the ability to place shaders on widgets right on your fingertip. States were easy to model. I think it took Javascript years to catch up, and while now some of the modern frameworks (React, Angular, Vue) might be ahead in lots of regards, they might still be behind in others. Actionscript itself had a pretty weak type system compared to what Typescript can do now (or could do years ago). E.g. there were no generics, apart from the some kind of semimagical vector. So this one is the smaller loss.
- simion314 8y agoI agree, my point was not that AS3 > TS , my point was that AS3 > JS still and AS3 is old and it had no improvements in years. The GUI part is still behind though, you still can't CSS the scrollbars and you need a JS library, you can't CSS the select options and you need a library to create a better dropdown, you have no built-in or a standard set of Widgets simlar to the DataGrid or AdvancedDataGrid, working on some old projects CSS drives me crazy
- naiyt 8y ago> It's not worth it. Productivity will drop enormously How does TypeScript make your "productivity drop enormously"? It has type inference, union types, looks just like ES6, and the typing is fully optional. The learning curve is quick if you've ever done static typing before (and not that hard even if you haven't). And you get the productivity boost of not dealing with a lot of the regular JavaScript BS (no more "spooky undefined at a distance" because somebody forgot a 3rd parameter 4 methods down the callstack), as well as the ability to safely and automatically refactor, and the ability to immediately understand the API of other people's code or libraries (as long as it's typed, and most popular libraries have type definitions now). In my experience the productivity benefits more than make up for the time you spend managing your types.
- jondubois 8y ago>> How does TypeScript make your "productivity drop enormously - Slow debug cycle due to increased compile time. If using TDD, it takes longer to run tests. The delays adds up - Especially on large projects and especially if you're not used to having a build step during development. - Sporadic source mapping issues/bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I've worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind. - Type definitions from DefinitelyTyped are often out of date or have missing properties/methods. It means that I can't use the latest version of a library. - Third party libraries are difficult to integrate into my project's code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements). - Doesn't guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The 'unknown' type helps but it's not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript. - Whenever I write any class/method, I have to spend a considerable amount of time and energy thinking about how to impose constraints on the user of the library/module instead of assuming that the user is an intelligent person who knows what they're doing. - Compiler warnings make it hard to test code quickly using console.log(...); I'm more reliant on clunky debuggers which slows me down a lot and breaks my train of thought. - The 'rename symbol' feature supported by some IDEs is nice, but if a class or property is mentioned inside a string (e.g. in a test case definition) then it will not rename that; so I still have to do text search after doing a symbol rename and manually clean up. - It takes a lot of time think of good names for interfaces and they are renamed often as project requirements evolve. It's not always clear whether similar concepts should be different types or merged into one. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic and coming up with meaningful abstractions which don't require arbitrary constraints to be imposed. - Setting up TypeScript is a pain. - Adds a lot of dependencies and complexity. It's a miracle that TypeScript works at all given how much complexity it sweeps under the carpet. Have you looked at the output JavaScript? Try to compile something that uses async generators and see what the output looks like.
- deleted 8y ago[deleted]
- tracker1 8y agoI'm not sure that I agree... AS3 had typing that was very similar (originally part of ES4 spec). I often feel that it can make some code that should be simple more complicated and sometimes reduces some flexibility in practice, or is harder to define. What research I can find indicates it's mostly a wash on time. You prevent a certain class of bugs, but at the same time you have the time to add typing. In the end, I think it depends. If you're working on a large project with a lot of developers in differing areas, the appeal is growing on me. In the end, when working on code you don't trust with behaviors that are loosely defined, you get at least a little more confidence in refactoring things out. I've worked with and without. I prefer without, but now am working on a project I wish I'd started with it. I still want to use it with babel as there are a few features I want to use that are not yet in the browser.
- herbst 8y agoThe title alone makes a good reason to further ignore typescript. If i should name a single major product that has the most horrible UI/UX it would be PayPal.
- femiagbabiaka 8y agoWhat does UI or UX have to do with language choice?
- 0xFACEFEED 8y agoGood UIs usually undergo rapid and extreme changes over very short periods of time. The choice of language could make it difficult or time consuming.
- danielhlockard 8y agoIt doesn't in this case.
- 0xFACEFEED 8y agoSure it does. We often have designers jumping in and programming UI code themselves. Teaching them all about type systems would be very time consuming.
- chess_buster 8y agoAs consumers of a library? Quick, what kind of object can I use this function with? function computeAge(birthday: Date): int;
- tracker1 8y agoI've seen some great UIs that are cobbled together from bootstrap + several extensions with a bunch of monkey-patched CSS and other jQuery extensions... the code is a hodge-podge mess that I didn't enjoy working with, but the UI itself was quite pretty/useful. I've seen the opposite as well. One does not beget the other. On my current project, I'm often doing a followup pass on the UI/UX for this project.
- russellbeattie 8y agoThis thread is going to quickly devolve into the pro-type safety vs. the pro-flexibility camps. Look, if you looooove declaring types and somehow thinks this reduces bugs, great. If you just want to focus on the logic of your app and don't feel like managing the minutia of how the computer stores a number or string, great. But if you want to declare one is fundamentally or empirically better, then you need to get a grip. We can all like different things, it's allowed. The one core thing I'd like to stress, however, is that TS is not JS. If you use TypeScript, you are not using JavaScript. They are cousins, sure, or maybe uncle and niece, but they are not the same.
- taude 8y agoI'd say the dynamic vs static should really be about team size/makeup and life expectancy of code base. Basically quickly building up things in a small team that might be around until a mature lifecycle (maybe startup-ish, prototype) vs big corp scenario where people working on code base will cycle through and the product is known to have a 5+ year life cycle from the start....
- russellbeattie 8y agoYes, what you said is the 'generally accepted wisdom' and the cudgel with which the type-safety folk like to use to beat on the dynamic type folk, since pretty much all projects could potentially grow at some point, why not just start with type-safe first? I could argue, but won't, that the accepted wisdom isn't correct, and large code base management is more about code discipline and reviews rather than whether your language requires types or not.
- sickcodebruh 8y agoTO BATTLE! Reducing it to "pro type-safety vs pro-flexibility" doesn't tell the whole story. For me, it's "pro-consistency vs pro-inconsistency" or "pro-tooling-that-makes-sure-I-don't-screw-up-something-trivial vs pro-keeping-absolutely-everything-in-my-head-at-all-times." Of course, that's _also_ pretty superficial and unfair -- plenty of amazing work has and will be done without type safety -- but as a bonafide Kool-Aid-drinking TypeScript Cultist, I feel obligated to share that because it's made my life better.
- rococode 8y agoHere's my strongest argument in favor of type safety: if you're building a project that is intended to have a long life and be seen by many people, type safety may be a hassle for you but it'll be a blessing for the hundreds of people who will have to eventually figure out your code.
- maxyme 8y agoMy team has recently focused on adding JSDoc to most of our codebase and I've been thinking, JSDoc provides essentially all the benefits (and more) of typescript from a maintainability aspect and contains none of the headaches (outdated definitely typed definitions, fighting with types...). As long as you use something to validate the JSDoc comments (like the JSDoc eslint plugin) they are extremely helpful in ways very similar to typescript. Language Servers like that in VSCode (tsserver) will inherit types from JSDoc comments and provide useful annotations with both the types and descriptions. They can even be used to show code examples or statically generated into webpages. If your only argument is to use typescript for maintainability reasons doesn't using JSDoc extensively both solve and improve upon that goal?
- alangpierce 8y agoI guess depends on exactly how you use JSDoc, but it sounds like you're talking about relatively informal documentation with some best-effort machine validation. My experience is that you don't get anywhere close to the confidence that you get with a real typechecker. Docs can be overlooked, docs can be misinterpreted, docs can get out of date, docs can be wrong by mistake. And, inevitably, if you have many people working with the same code over the course of years, these issues will be common. Having an actual typechecker avoids all of these problems, at least for documentation of data formats. If you do mean annotating all types with the thoroughness that you'd annotate TypeScript code, then really you're just writing TypeScript in JS, and TypeScript is a much more concise language than JSDoc for that.
- chrischen 8y agoYou can try something like facebook's flow which can be done as comments so no transpiler is needed.
- alangpierce 8y agoNote that it's possible to use both TSLint and ESLint in the same project, and that's what I've been doing for nontrivial projects. ESLint has a big community and a lot of nice rules, but there are a few things that ESLint can't (yet) do and that aren't implemented by TS itself: * The TSLint no-unbound-method rule is really helpful for avoiding the React bug of passing `this.handleClick` at render time without it being a bound method. This is one of the "needs type info" rules that uses the type analysis from the TS compiler, and generally these sorts of rules are much more powerful than what you can normally get in ESLint. * The TSLint ordered-imports rule with autofixing is a much nicer way to force import ordering than anything I've seen in ESLint. (ESLint sort-imports won't reorder your imports, for example.) But as mentioned, the TS team has said that they want ESLint to be the future for TypeScript linting, so hopefully ESLint will get all of that soon enough.
- conover 8y agoWe use both at Twitch, on a codebase approaching 7-digit lines of non-generated code. It’s worked out well for us.
- starefossen 8y agoMy biggest grape with staticly typed languages like TypeScript is that many developers considers type safety a replacement for test - it is not. It is completely at best.
- deleted 8y ago[deleted]
- keymone 8y agoStatic typing doesn’t reduce bug density, this is no news, just a risk compensation principle at work. But there’s another factor: static typing creates a nice puzzle for you to solve instead of solving the actual problem. You solve the puzzle and feel nice, you show the solution to management later and they feel nice to because it’s all neat and hierarchical. Then you write majority of the code that doesn’t neatly fit the puzzle’s constrains, then new feature requests/requirements come in and after a time the puzzle needs to be solved again. And so the wheel turns. What people usually mean when they talk about static typing is a language to specify promises and requirements. To my knowledge that language has not yet been successfully reduced to mostly static and rigid annotations that are useful in dealing with changes to the software itself.
- hitekker 8y agoI found this true for Flow but not as much for TS
- bcherny 8y agoHow so?
- zbentley 8y agoI've heard that argument before, but I've never seen that sort of behavior in practice. If anything, statically typed (or heavily annotated) codebases I've worked on have been much more amenable to change when it comes to adapting to "code that doesn’t neatly fit the puzzle’s constraints" as you say. The refactoring tooling and assurances provided by the type system tended to make people more willing to start rethinking their "puzzle" (type design) earlier in the process, rather than doubling down on a flawed model. I've seen people do similarly great work in highly dynamic languages, too, so this isn't a "static > dynamic types" statement; just an anecdote in contrary to your claim.
- keymone 8y agoThe puzzle is not some inherent problem within the one you’re actually solving, it only arises because of limitations of any type system you choose to work with.