4 ms·
Type hype is real. It almost seems like job-creation propaganda at this stage. When I judge things, I look at practical outcomes; and the fact is that I produc
by jondubois 6y ago
Type hype is real. It almost seems like job-creation propaganda at this stage.
When I judge things, I look at practical outcomes; and the fact is that I produce better software with more features within the same timeframe if I use JavaScript rather than TypeScript and the product in both cases is equally robust. This has been true for me both independently and as part of a team.
With JS, I can write more code and more tests within the same amount of time and there is no drop in quality.
I'm very surprised that nobody else seems to be experiencing the same thing. I've been back and forth many times between the two paradigms and for me it's clear as day.
- rswail 6y agoSorry anecdata isn't data. You might be able to write more code in terms of LOC but you're also writing tests that a strongly typed system wouldn't need. You don't know that your code is "equally robust". You don't know what sort of "drop in quality" you have because you're not using strong types. You are making a judgement that isn't backed by anything other than intuition.
- valuearb 6y agoI switched my Javascript code base to Typescript a few months ago. There is a productivity cost that is declining over time as I get more used to Typescript. But the conversion also flushed out some significant bugs in the JavaScript base. And I only get to work on this code once a week. So when I come back to it I’ve found it’s much clearer how it works and I get productive much faster. I will bet any coworkers who have to work on your code wish it was in Typescript.
- noema 6y agoThis doesn't conform with any of my experiences in non-trivial JS codebases. Migrating to TS tends to reveal previously overlooked implicit typing issues. Also, I find the "upfront productivity loss" of TS to be overstated: adding in annotations here and there doesn't take much time at all, and pays dividends quickly. Many hours have been lost tracking down some elusive runtime bug stemming from a typo in a vanilla JS property access.
- jondubois 6y agoIn my career (which spans 15 years at over a dozen companies), I've built many complex front ends, complex backends with different database systems, a popular open source pub/sub server which auto-scales on Kubernetes across a cluster of machines, a P2P networking library with selective message routing/propagation (in a scalable partial mesh configuration), a scalable chat system, a decentralized cryptocurrency exchange (federated 2-way peg), a modular multi-process blockchain framework (which scales both horizontally and vertically) and many other complex projects; all of these written with plain JavaScript/Node.js, in record time and essentially bug-free (no major bugs reported so far on any of my projects since they were shipped). So I'm quite confident when I say that there is nothing wrong with JavaScript and dynamic typing. I've programmed in many different languages too; ActionScript, Delphi, C/C++, Java, Python, PHP, C#, AVR Assembly (ATMEGA8-16PU microcontroller)... I've also programmed a JavaScript UI front end for a TV set top box which had a custom JS engine. From my perspective, many among the TypeScript crowd are arrogant junior developers who regurgitate what they were taught by a bunch of academic bureaucrats who never actually built a single fully working system in their lives but who believe that their PhD qualifies them to tell everyone else about the many theoretical (but in fact, imaginary) benefits of functional programming and static typing... Benefits that not a single human soul has actually experienced themselves on a real large complex project. I've seen real-world complex FP projects; in all cases, the code was spaghetti; it's almost impossible to follow the logic because it jumps around too many modules and files; because all the state is kept in a single centralized place, instances end up getting passed around all over the place; traversing many intermediate modules to reach the target module; buried deep in the code... And there is no clear separation of concerns; it's hard to separate concerns when you fully decouple state from logic.