The link to domain driven development wasn't useful. The post should explain more about that and SOLID.
When to Use TypeScript – A Detailed Guide Through Common Scenarios
41–50 of 244 posts
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#42Earlier quoted context omitted.
You don't need to rewrite to add types.
In theory maybe you are right. In practice it never just adding types. E.g. you need to add null checks, rewrite old parts to follow same style (in case there are old parts in the code) and etc.
This usually happens anyway when you figure out how to do something better. Then need to apply it everywhere else.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#43It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.
Yep I feel the same. TypeScript improves my workflow tremendously and I use it for everything now. Going back to regular javascript feels like driving without a seatbelt. Sure you can but why? Type-checking and smarter autocompletion mean I don't make mistakes as often and my productivity is higher. (No longer run the app, see I misspelled a function call, fix and run again, etc.)
I also feel unit-level tests are less necessary with TypeScript. I used to write a lot of JavaScript tests that essentially just confirmed that "this sh*t is all tied together correctly". With TypeScript, if a code change or refactor broke something structural, you know immediately!
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#444 of the most popular language creators here https://www.youtube.com/watch?v=csL8DLXGNlU agree that type systems are useful. I would suggest definitely not using Vanilla JS. There are excellent type systems over JS, TypeScript, Scala.JS, BuckleScript to name a few each with their pros and cons (I don't know what cons BuckleScript has though, maybe relatively smaller lib-ecosystem)
Not that I don't agree with their opinion, but being a language creator mostly like greatly biases you towards over estimating the usefulness of certain features. As such I wouldn't hold language creator's opinions on the value of certain language features over say the opinions of CTOs or VP engineering of large companies, especially as it relates to productivity, maintenance and onboarding.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#45> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.
I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!" This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've ne…
There are so many automated safe refactore and build time safeguards you can do with statically typed language, I’m much more comfortable making major changes and extension with Typescript than vanilla JS.
The problem with overengineering is that you don’t have a good grasp on a generalized architecture until you have two or three use cases. Of course anything dealing with cross cutting concerns like logging and authentication it’s easier to add up front.
I don’t know any modern front end frameworks, but when working within a team, I’m all for opinionated popular frameworks. It’s s lot easier to onboard people and from a completely selfish standpoint, developers who are concerned with their careers want to be able to put a transferable toolset on their resume.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#46Having been reading hacker news since 2009, I’m really tired of these unevidenced clickbait listicles on some persons anecdote.
There is no evidence presidented whatsoever in this article. It also seems that this person hasn’t worked with a numbered and diverse enough set of clients to even warrant listening to him as a practioner.
He’s peddling tired DDD tropes amongst a spattering of meandering well worn blog posty unsciencey ideas he’s read throughout the years.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#47> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.
> This one never ceases to amaze me. Any codebase is small, until it gets big.
do y'all work on the linux kernel or what ? most of the projects I've seen across multiple jobs are less than 5000 loc. And they never will "get bigger" because they are not "products" that get evolved over time.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#48It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.
> It doesn't slow down development
I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#49It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.
> unimaginable I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.
You'll find that the more you work with types, the less this becomes an issue. You begin to think in types as a first class construct.
Types don't slow me down, and I can't imagine working without them.
Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios
#50Isn't anyone worried that TypeScript will go the way of CoffeeScript?
I am not. CoffeeScript was never as popular as Typescript already is. TypeScript is a tool which solves a problem, CoffeScript is a language (IMHO) no one needed.