6 ms·
Yep, 100%. In the process of converting a node/typescript API to rails. I'll never make this mistake again.
by ajsharp 8y ago
Yep, 100%. In the process of converting a node/typescript API to rails. I'll never make this mistake again.
- ericb 8y agoI'm de-Embering here and going to pure Rails. I'm gonna party like it's 2009!
- rohan404 8y agoTo quote the ever popular HTTParty Ruby library: "When you HTTParty, you must party hard!".
- koolba 8y agoYou’re going from TypeScript to Ruby? Having tasted the joys of static type checks combined with a unified front/back data model, IMHO, that’s unthinkable.
- mostlysimilar 8y ago> joys of static type checks combined with a unified front/back data model Would you mind elaborating on the specific benefits?
- Aeolun 8y ago100% accurate autocomplete everywhere? As long as you don’t use ‘any’ anyway.
- koolba 8y agoWith TypeScript you can define a single set of interfaces shared by both your client side and server code. If you change an interface to return a different value or rename a member, you immediately know where it’s used and can update it in tandem. Static type checking let’s you know everywhere that something is used without a battery of tests running through your app. This takes 99% of the fear out of refactoring and expanding APIs which leads to incredible agility in adding features to an existing code base.
- 0xADEADBEE 8y agoI used Typescript from the get-go on a new project recently and it's slowed down both mine and my team's development velocity a lot. Time will tell if it's a smart decision but in terms of prototyping or spiking something, I'm picking Rails every time and I think based on my current experience I'd be apt to retrofit Typescript to an existing project rather than integrate it from the beginning. I don't suppose you could recommend any good resources for better learning Typescript? The docs are OK but if there's a book or anything you'd recommend, I'd certainly appreciate it.
- iguana 8y agoI don't have a book recommendation for you (what helped me was the standard documentation and about a year of daily dev time), but an observation: Your team is likely using an overly restrictive tsconfig.json. No-implicit-any, for example. Make it less restrictive, and you then have typing and no penalty for punting on it until later. If using an IDE, the effort into defining types is immediately rewarded with autocomplete for API/backend AND client code, and we even export the types for use by a Monaco editor inside an internal app.
- DCoder 8y agoOne more thing that IMO gets overlooked too often: TypeScript can typecheck your JSX markup. Compare that to any string-based templating engine, such as Knockout.js templates or jquery.tmpl, where you have to learn its snowflake DSL, you get no autocomplete, no checks for undefined variables or syntax errors… If I never have to explain <!-- ko if: !condition --> vs <!-- ko ifnot: condition --> again, I'll be a happy man.
- koolba 8y agoThis is the type of thing to which I was referring. A server interface is updated to return a different data type or renamed, the client shares the same interface, type checking for TSX (TypeScript JSX) catches the name or type of the property is invalid, and you can immediately fix it. No more grepping an entire codebase to see all the places that something is referenced and praying that you updated all of them. (And praying that you updated them correctly!)
- ajsharp 8y agoStatic typing is nice, but the tradeoff of all the wonderful ruby library support far outweighs the node ecosystem. I found myself fighting with so many poorly-executed, half-abandoned, relatively popular (mongoose). Stuff in ruby land Just Works™. Do I want to be writing type defs for some dying library, or building features? Unfortunately, this is consistently the node ecosystem trade off.