10 ms·
Porting a React Front End to TypeScript
- ludamad 6y agoOne critical thing for TypeScript's success that I wish for the Lua community is that it paved a roadmap for typing a huge chunk of the JS ecosystem. Porting to TypeScript can be entirely incremental, and you usually have a wealth of types coming in from dependencies. The UX here is going to be one of the best as far as ports go, as usually porting feels negative value up front
- LAMike 6y agoThe question is, is it worth it? I'm starting to feel behind the curve and I want to learn new stacks like Next.js, Typescript and GraphQL. Anyone else feeling this way or have already gone through that learning curve?
- cheald 6y agoTypescript is really easy to learn. You can turn it on, throw your existing JS at it, and then gradually increase the strictness level as you add typing information. It's a very painless transition.
- fuzzy2 6y agoI like TypeScript quite a lot, by itself. You should definitely take a look! Whether you use it with Node, React, Angular, Vue – doesn't matter. Whether porting existing projects to TypeScript is worth it is of course a question that cannot be answered universally. Depending on how… creative developers were when creating it, it can be incredibly mind-bending.
- Ozzie_osman 6y agoIn my opinion, totally worth it. First, you can transition gradually, just typing one file at a time if you want. Second, the type-safety you get makes incremental refactoring so much easier and makes you more thoughtful about "interfaces" (ie function parameters, etc). It also catches tiny bugs that would otherwise blow up in production. Yes, sometimes you'll run into weird cases where you have to wrestle the type system, but honestly, in the worst-case you can just ts-ignore those (though you probably want to minimize that).
- serpix 6y agoWorth it, speaking as someone who prefers how Typescript is so flexible and does not get in your way too much.
- intruder 6y agoYes, one often overlooked benefit is the tooling that is enabled by having proper types. IDEs from jetbrain in particular are great at it.
- kilburn 6y agoI have transitioned my entire team (comprising people ranging from fresh-out-of-a-bootcamp to senior 20-years-in-the-web). Next.js and GraphQL are interesting technologies, but I would say they will eventually fade. They do solve some problems, but they introduce new (hard to fix) ones. Typescript is here to stay. The improvement it brings to the development experience cannot be understated. It helps the inexperienced to avoid lots of (minor) bugs and providing much more useful autocompletion/inline docs than any javascript analyzer can. For the experienced people, it is an invaluable tool when the time for largeish refactorings comes. For the first time you can "follow-the-trail-of-errors refactor" in frontend-land.
- shriek 6y agoThis question probably varies on who I'm asking but how long does the transpiling process take for you on a, let's say, fairly large project?
- kilburn 6y agoWe were already using Webpack + babel. Adding transpilation there is fairly inexpensive (done by babel, without type checking). Type checking did roughly double our build time. Even then, we do run type checking during builds because we prefer the added safety even with this extra time. Developers run with an incremental checking watcher. It does add a significant tax, and takes a few seconds after saving in some cases (3-4). We would love that delay to go away, but it is a cost we are more than willing to bear if the alternative is not having type checking at all.
- mattlondon 6y agoI'd personally ignore Next.js and GraphQL, but would certainly (and personally have) invested in TypeScript. I am guessing that Next.js and GraphQL will be long-dead and obsolete "soon" (in the same way that e.g. jQuery & AngularJS were once also red-hot technologies but are now out of favor), but TypeScript really feels like it is here to stay with significant benefits. I guess this is a "learn technologies, not libraries" type thing? I was "forced" to learn TypeScript for Angular 2 (that was the library of choice at where I worked at the time) but now also use it for my personal stuff out of choice. Compared to pure JS it is a bit of a pain to get basic development up and running (since you need a TS -> JS compile step before you load it in the browser, unlike raw JS that you can just code and reload). For that I have created myself simple boiler-plate templates (1) that I use to bootstrap a new project so I can be up and running in a browser in 60 seconds etc (the template will do all the compilation and bundling for you using webpack) 1 - https://github.com/matt1/TsBoilerPlate https://github.com/matt1/TsBoilerPlate
- com2kid 6y agoSince Babel now supports TS out of the box, it is much easier to use. Not as safe of course, but you get 90% of the benefits.
- munchbunny 6y agoIf you've worked with a language before that uses static typing and compile time type checking (Java, C#, and C++ immediately come to mind), TypeScript will be very easy to pick up. It'll just feel like a slightly different JavaScript-friendly syntax slapped onto the same set of core concepts. Coming from a background where I had written both C# and JavaScript before, TypeScript took all of one day reading docs and messing with the toolchain to start adapting it for the React app I was working on at the time If you haven't worked with a statically typed, compile-time type-checked language before, I think you owe it to yourself to learn one, whether or not TypeScript is the one you learn.
- gherkinnn 6y agoNext is dead-easy to learn. It takes very little and you have a solid React setup. No config required. The docs are very, very good. And they have a little tutorial.
- Keats 6y agoI've used TS for 4-5 years now and I have been using Next.js/GraphQL in a work project. I would focus on TS since I don't really think Next.js/GraphQL is worth the hype and I would bet TS will outlive both by a significant margin.
- vorpalhex 6y agoGraphQL is a genuinely different kind of tool in the box, and it is at times useful in that way. Typescript is really just a tool for people who want autocomplete in VSCode for their javascript, or who really still want to be coding in C# and unless you're just dying without those things it's a lot of overhead for not much benefit.
- Blaiz0r 6y agoTypescript has made me pretty sure I don't want to be a frontend dev much longer.
- sli 6y agoTypescript has made me go looking for Elm and Purescript jobs. Not many of the latter, but I've applied for one of the former.
- stgewehr 6y agoIt seems that I fundamentally misunderstand the benefits of TypeScript. I found myself spending hours and hours on reading the type errors stacktraces and adding types for libraries. Writing TS code takes 2x time than simple JS... and it is extremely painful experience. In comparison to many old plain JS projects I did - it simply doesn’t make any sense, the TS solves problems which I haven’t experienced at all.
- jameshush 6y agoIt's helped me immensely, however the projects I work on get millions of hits a day (I’m in publishing/adtech). More eyeballs means more chances for an edge case to pop up. It's been worth it alone to catch undefined errors at compile time. I'm also on a team of 5+ front end engineers, though and use other team’s internal libraries often, which is probably why it's made a difference. If it seems more hassle then it's worth for what you're working on, the rest of your team isn't bothered, and your clients are happy you don't have to worry too much. I still throw in vanilla JS on other smaller projects every once in a while for those reasons.
- Humphrey 6y agoYes - there are some pain points - but my experience is that the 2x is worst case. It gets MUCH closer to 1x with experience, and I'd dare to say it will be closer to 0.75x over the long term.
- karatestomp 6y agoAs soon as a significant portion of the time spent tackling a new feature or addressing a bug becomes reading code (which you may not have written) the types pay off to at least[1] a 0.75x time-multiplier, and I'd say that's very conservative. It also makes it a hell of a lot easier and faster to collaborate on different parts of a feature that interact without exactly overlapping—"here's the interface I expect to implement, code to that, if anything changes TypeScript will tell you without our even having to talk (about that)" [1 EDIT] at most? hahaha.
- mattlondon 6y ago
- joelbluminator 6y agoI'm not saying I never ever run into bugs due to dynamic types such as method/variable typos, I just think it's much more rare than people make it out to be. If that sort of thing happens a lot in a project you basically have very little tests. I'm confident in saying it happens to me maybe once in a few months - and that's working in a super dynamic environment of Rails. The Null error does happen, but that happens in java as well.
- dkempner 6y agoBut how often do you forget what properties are required for the config object that is the third argument to your function?
- joelbluminator 6y agoI'm not saying it never happens, I just really need to think hard on when it last happened. You're talking about a method that requires a certain param but doesn't raise an exception if you leave it out and then behaves in a buggy way. Again, not something happening a lot.
- com2kid 6y agoEverytime I construct that object I'd have to look up what the fields are, either docs (lol yeah right) or by looking at previous calls. Bonus if my previous usage was incorrect and I didn't notice and I end up copying that same mistake again and again! TypeScript saves me probably 15+ minutes a day of just switching back and forth looking up what parameters are needed. It is a one time tax to make everything I do more pleasant.
- joelbluminator 6y agobtw can't you potentially write methods that receive arbitrary number of arguments in java as well? https://docs.oracle.com/javase/1.5.0/docs/guide/language/varargs.html https://docs.oracle.com/javase/1.5.0/docs/guide/language/var...
- scottfr 6y agoYou can get a lot of the benefits of Typescript in VSCode without leaving JavaScript behind by using JSDoc. Typescript will pick up the JSDoc type annotations and use them to type the code. This can be a great option when typing an existing project. Docs: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#supported-jsdoc https://www.typescriptlang.org/docs/handbook/type-checking-j...
- hombre_fatal 6y agoVanilla VSCode also has surprisingly good code inference for Javascript/Typescript. Recently, Typescript was complaining about an implicit `any` even though the VSCode tooltip clearly could infer the actual type (it confusingly was showing both cases in the tooltip). I finally realized that VSCode's built-in inference worked here but Typescript didn't work at all because I forgot I was importing a .js file rather than a .ts file. VSCode for course also downloads @types/* files in the background even in vanilla JS projects which is super helpful because you get effortless intellisense. That it does this kind of stuff out of the box is the sort of reason why I've lost my Vim/Emacs fanaticism over the years.
- DanRosenwasser 6y agoVS Code's JS support is actually still powered by TypeScript. I'm not 100% sure exactly what you were experiencing, but it's intentional that VS and VS Code automatically download types when powering JavaScript contexts because we try to make things "just work" for JS users.
- hombre_fatal 6y agoI don't think you are saying anything in conflict with me. VSCode tries to give you type info in contexts where Typescript wouldn't (e.g. importing Javascript files, in a completely non-TS project) so it makes sense that its inference tooltip can be more helpful. You can easily recreate this by importing a fn from a JS module and then hovering it in VSCode (also configured for Typescript): VSCode knows the fn signature but Typescript won't. Both cases show up in the tooltip (though confusingly). At least, that's my interpretation of this sort of tooltip: https://i.imgur.com/lXS5teK.png https://i.imgur.com/lXS5teK.png And to be clear, your last sentence was my exact praise for VSCode at the end of my own comment.
- Kiro 6y agoI want to start using TS for my Node service but ts-node seems janky and the compability with ndb (which I use all the time) seems bad.
- DanRosenwasser 6y agoAnything specific about ts-node that doesn't work or that stuck out as janky?
- Kiro 6y agoI keep reading people saying you should use tsc + regular Node instead which is enough to make me worried but haven't really evaluated it myself.
- gary_bernhardt 6y ago(I wrote the article.) We don't use ts-node for our dev processes because it adds some annoying startup delay. We keep the TS compiler running at all times on our dev machines, and we run our server/tests/etc. from the TS compiler's build output directory. This hasn't been a big pain point for us so I wouldn't worry about it much. Related, just in case: I definitely wouldn't use ts-node in production. If your deployed code fails to typecheck for some reason, you don't want to learn that by seeing your backend server failing to boot in production. I think you should always compile your app during your deploy process, then have production boot the compiled JS as if TS weren't involved at all.
- sefrost 6y agoI’ve found this React + TypeScript cheat sheet extremely helpful while recently porting a React codebase to TypeScript. (To the point it’s one of only four bookmarks on my browsers bookmark bar.) Perhaps others here will find it useful as well. https://github.com/typescript-cheatsheets/react-typescript-cheatsheet#reacttypescript-cheatsheets https://github.com/typescript-cheatsheets/react-typescript-c...
- DanRosenwasser 6y agoHey all, I work on the TypeScript team. I've been super happy to read some of the posts about the migration on Execute Program. If anyone has any feedback or questions on TS, I can also try to answer them.
- brlewis 6y agoNoticing the time when you posted your comment -- how big is the TypeScript team, and how many time zones does it cross?
- DanRosenwasser 6y agoIn total there's roughly 20 people, more or less split between core compiler/language service and VS editing scenarios for JS & TS. We also work pretty closely with the VS Code team on their integration. > Noticing the time when you posted your comment Uh, I am just kind of a night owl. Most of our team members work out of Redmond, WA, and our distributed members are either on the East or West coast of the US.
- czei002 6y agoRegarding the previous backend related article and code sharing between backend and frontend, how does your project setup look like? For example, does the code get compiled using a bundler like webpack? if yes how do you solve the import '../../../../../shared.ts' problem? Or do you use node modules in a monorepo? Compared to other languages I found these questions surprisingly difficult to answer and solutions often quite cumbersome, e.g. if I want to share one small file in my project I don't want to maintain a public npm module for it...
- prmph 6y agoEver heard of the "rootDirs" [1] option in tsconfig.json? You can use it to aggregate code files in the various folders as if they were in one flat folder (as far as TS is concerned) while editing. Before building with WebPack, you can copy all the code files into a temporary build folder and then run WebPack on it. 1. https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...
- gary_bernhardt 6y ago(I wrote the article.) We use a single git repo with no npm packages defined, other than the package.json in the root because we have to put dependencies etc. in there. The directory structure for our source code is dead simple: src/server src/client src/common For example, the API endpoint definitions are common code, so you'll see stuff like this in client code that uses the API: import * as quizApi from "../../common/api/pages/quiz" The ".."s are annoying, but working around them isn't worth the effort. Even when we heavily reorganize the file organization, it only ends up taking a few minutes to mechanically update these imports with a vim macro, or even with sed if it's a perfectly mechanical change. We run two copies of tsc: one for the client and one for the server, building to build/server and build/client. That results in a weird build directory structure: src/server/db.js src/client/app.tsx src/common/endpoints.ts build/server/server/db.js build/server/common/endpoints.ts build/client/client/app.tsx build/client/common/endpoints.ts If you need separate build settings for client and server, this weirdness is going to show up one way or another. However, we only introduced this build separation in the last month or so. For the first 1.5 years of the project, we got away with a single tsc process and tsconfig.json, with no build separation at all between client and server. If anyone who's newer to TS reads this, I'd encourage looking for simple solutions like that; you can get to the weirder stuff down the road if you need it (and you may never need it!)
- conmigo 6y agoI've never increased my productivity by using Typescript, although I really tried very hard to like it. It just keeps bugging me. It's a constant stream of interruptions that force me to please the TS compiler, compared to having a rare type issue a once in a while in plain JS. Besides that, I've never been a Microsoft fanboy(to say the least) and it's worrying me that almost the entire JS eco system falls in the hands of that company; Github, VSCode, Typescript, NPM, etc.. Am I alone in this? There is so much good stuff in the JS world, but we seem to adhere to a few companies and a few systems more and more. Being a 'Javascript' developer today only has very little to do with Javascript. It's about React, Redux, Hooks, ESLint, Prettier, Typescript, etc.. Oh, and don't forget to do it Agile, another joy and productivity killer. And when you don't agree with this stack you're either not so smart or still need to learn to 'understand' it.
- Blaiz0r 6y agoI feel very similarly to you regarding the position that JS is moving in. I can only surmise that things are moving in this direction to lower the barrier to entry. As more developers are working with JavaScript it's easier to subscribe to tools to manage consistency than it is to educate and rely on developers' standards to create working efficient code. Thinking back I've worked on some massive 'Web app' projects over the last 20 years, and the biggest I worked on didn't use much in the way of frameworks or libraries, and standards were maintained by peer review and documentation. Typescript I suppose automates a lot of this, but I don't think that makes it better.
- adreamingsoul 6y agoI tend to agree with you. I've been working on the front-end side of web applications for a couple decades now. We have so many tools available to us now then ever before. It's interesting to observe how a select few end up as the go-to choices for so many projects and organizations. At the end of the day, they are just tools and how we use them is what really matters.
- chrstphrhrt 6y agoSame. I have tried using it and enjoyed the IDE powers a bit more, but already knowing JS quite well, it wasn't a game changer. Lately I have started using FastAPI in Python, which uses Pydantic to enforce type hints at runtime. This saves a lot of manual checking code (e.g. "if input_data["mykey"] == "unhappy path": raise ValidationError"). This was the same annoyance in Node.js because the types are so flimsy and manually checking is really boring. Tests are great but if you can have correctness while rapidly prototyping that would seem to be a win. Is there a great TS lib to do runtime type reflection like Pydantic?
- prmph 6y agoI love TypeScript, but have encountered a situation where I simply could not compile my code anymore because it started causing an internal error in the compiler itself. Fortunately, I work as a team lead, and this was on an experimental branch, so I was able to hand off bits of code relating to architectural patterns I was evaluating to my team to continue work on those. But I simply could not proceed with my code as is, a very frustrating experience to say the least. How is this even possible?
- mayank 6y ago> But I simply could not proceed with my code as is, a very frustrating experience to say the least. How is this even possible? As a team lead, I'm sure you know...bugs happen. What sort of internal error was it causing? Something specific and spelled out, or a generic uncaught exception?
- prmph 6y ago.../node_modules/typescript/lib/tsc.js:78602 throw e; ^ Error: Debug Failure. at Object.assertDefined (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:1690:24) at /media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:13175:89 at String.replace (<anonymous>) at formatStringFromArgs (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:13175:21) at Object.createFileDiagnostic (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:13191:20) at createDiagnosticForNodeInSourceFile (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:7770:19) at Object.createDiagnosticForNode (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:7760:16) at handleSymbolAccessibilityError (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:71556:50) at checkEntityNameVisibility (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:71929:13) at visitDeclarationSubtree (/media/psf/Code/Hypothesize/node_modules/typescript/lib/tsc.js:72066:29)
- mayank 6y agoOuch. That's bad alright.